Add /factually command (#108)

* Add /factually command for research-driven planning

* Fix tool names and add parallel research in /factually

* Add phase splitting for non-trivial plans in /factually

AI/commands/factually.md

@@ -0,0 +1,60 @@
+---
+description: Plan a task factually — research first, ask when unsure, keep it simple
+---
+
+# Factually Command
+
+Respond to the user's prompt using Plan mode, grounded in thorough research rather than assumptions.
+
+## Usage
+
+```
+/factually <prompt>
+```
+
+## Workflow
+
+### 1. **Enter Plan Mode**
+
+   - Use the `EnterPlanMode` tool to enter planning mode before doing anything else.
+
+### 2. **Research Thoroughly**
+
+   - Before forming any plan, investigate the codebase, docs, and relevant context deeply.
+   - Use Explore subagents, Grep, Glob, Read — whatever it takes to ground your understanding in facts.
+   - **Parallelize**: When multiple independent things need researching, launch parallel subagents (via the `Agent` tool) to investigate them concurrently. Don't serialize what can be done simultaneously.
+   - **Never assume** how something works. Read the code. Check the config. Verify the dependency.
+   - If the prompt involves external tools/libraries, use WebSearch/WebFetch to get current info.
+
+### 3. **Clarify Ambiguities**
+
+   - If anything in the user's prompt is ambiguous or could be interpreted multiple ways, **ask immediately** using the `AskUserQuestion` tool.
+   - Don't guess intent. Don't pick a default interpretation silently.
+   - Be liberal with questions — better to ask 3 questions upfront than to plan around a wrong assumption.
+
+### 4. **Draft a High-Level Plan**
+
+   - Keep the plan at a **high level**: what to do and why, not how to implement each step.
+   - No code snippets, no line-by-line changes, no implementation minutiae.
+   - Focus on **architecture and approach** — the "shape" of the solution.
+   - **Prefer simplicity**: if two approaches exist and one is simpler, choose it. Justify complexity only when necessary.
+   - Call out trade-offs and alternatives considered, briefly.
+
+### 5. **Split Non-Trivial Plans into Phases**
+
+   - If the plan is non-trivial, break it into small, sequential phases.
+   - **MVP first**: Phase 1 should deliver the minimum viable version. Later phases layer on.
+   - Each phase should be small enough for the human to review every line of code.
+   - One phase = one focused concern. Don't mix unrelated changes.
+
+### 6. **Present Plan for Feedback**
+
+   - Use the `ExitPlanMode` tool to present the plan and solicit user feedback.
+   - Iterate based on feedback before exiting plan mode.
+
+## Principles
+
+- **Facts over assumptions**: Every claim in the plan should be backed by something you read or verified.
+- **Ask over guess**: When in doubt, ask the user. Silence is not consent to assume.
+- **Simple over clever**: Prefer the boring, obvious solution. Complexity must earn its place.
+- **High-level over detailed**: The plan is a map, not turn-by-turn directions.