Skill: /plan-task

Trigger

/plan-task "task description"

Without a description, ask before continuing.

Response guidelines

Be comprehensive but concise. Prefer tables and lists over paragraphs. Omit obvious explanations. No flowcharts.

Reading project context

Read if they exist:

• .claude/project.md — stack, environments, modules
• .claude/conventions.md — team standards
• .claude/architecture.md — technical decisions
• .claude/known-issues.md — known pitfalls

If they don't exist, inform and continue with generic context.

Stage 0: Clarification

Before producing the plan, check if the description is sufficient.

Ask up to 3 targeted questions if any of the following are true:

• The task type cannot be determined (feature / bug / refactor / infra)
• The affected module or service is not identifiable from the description or .claude/architecture.md
• The scope boundary is ambiguous (e.g., "improve performance" with no target component named)

Do not ask about implementation preferences — only ask for facts needed to scope the plan correctly.

After asking, wait for the user's reply before proceeding to Stage 1. If the description is clear enough, skip Stage 0 silently and proceed.

Stage execution

By default, all stages run sequentially in one response.

The user can say "do only Stage 1", "stop after Stage 3", "skip to Stage 5". Respect this literally.

If a mid-stage ambiguity requires input, emit the completed portion of the current stage, then write:

Paused at Stage N. [Question]. Reply to continue.

Stage 1: Task understanding

Rephrase in 2–3 lines. List assumed premises as a table if there's ambiguity.

Premise	Assumed value
Task type	feature / bug / refactor / infra
Target module	identified name or "unknown"

If after rephrasing you identify a fundamental ambiguity that would make the remaining stages unreliable, pause here and ask the user to confirm before continuing.

Stage 2: Files and modules involved

File / Folder	Action	Reason
path/to/file	Create / Modify / Delete	Short reason

Stage 3: Dependencies and prerequisites

Item	Type	Required before
Migration X	DB	Step 2
Service Y running	Infra	Step 1
Feature flag Z	Config	Step 3

If no dependencies exist, write: No external dependencies identified.

Stage 4: Implementation checklist

[ ] Step 1 — clear description
[ ] Step 2 — clear description
...

Each item should be small enough to be done and tested independently.

Stage 5: Edge cases and risks

Scenario	Impact	Mitigation
Short description	High / Medium / Low	Short mitigation

Stage 6: Acceptance criteria

Criterion	How to verify
Feature works end-to-end	Manual test or automated test description
No regressions	Existing test suite passes

Final output: Ready-to-use prompt

After completing all stages, generate the following block verbatim, filled in with the collected context. This prompt is ready to be copied and triggered:

---

You are [senior dev role inferred from the stack]. Your job is to implement the task described below. You are helping [user type: solo dev / team / backend eng / etc.] in [environment inferred from .claude/project.md or generic].

Use this tone: precise, direct, no filler.

Reference this material when answering:
<context>
[Paste here: task summary from Stage 1, files from Stage 2, dependencies from Stage 3, risks from Stage 5]
</context>

Rules:
- Follow the conventions in .claude/conventions.md if it exists
- Touch only the files listed in Stage 2 unless a deviation is explicitly justified
- Each implementation step must be independently testable before moving to the next
- If unsure about scope, ask before implementing — do not assume

Examples:
<example>
User: implement step 1
Assistant: [concrete code or action for step 1, scoped to the files listed]
</example>

Conversation history:
<history>
{{HISTORY}}
</history>

Current request:
<request>
{{REQUEST}}
</request>

Reason carefully before answering. Do not reveal private reasoning. Return only the final answer.

Output format:
<response>
[FINAL ANSWER]
</response>

---

Prompt ready. Copy and trigger when you want to start implementation.

Behavior with description

Use the description to:

• Identify type (feature / bug / refactor / infra)
• Adjust level of detail
• Detect modules by name and cross-reference with .claude/architecture.md