nixos-config/AI/commands/srid-plan.md

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.