mirror of
https://github.com/srid/nixos-config.git
synced 2026-05-08 07:06:09 +08:00
66 lines
3.3 KiB
Markdown
66 lines
3.3 KiB
Markdown
---
|
|
description: Plan a task factually — research first, ask when unsure, keep it simple
|
|
---
|
|
|
|
# srid-plan Command
|
|
|
|
Respond to the user's prompt using Plan mode, grounded in thorough research rather than assumptions.
|
|
|
|
## Usage
|
|
|
|
```
|
|
/srid-plan <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.
|
|
- **Include an Architecture section** in the plan that covers:
|
|
- What modules/components are affected and how they relate
|
|
- Architectural-level changes, impact, and considerations
|
|
- Any new abstractions, interfaces, or boundaries being introduced or modified
|
|
- Potential ripple effects on the rest of the system
|
|
|
|
### 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.
|
|
- **Each phase must be functionally self-sufficient**: after completing any phase, the system should work end-to-end. Don't split by layer (e.g., client/server/tests separately) — instead split by feature slice so each phase delivers a working whole.
|
|
- 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.
|