From amplify
Creates structured PLAN.md for software engineering tasks by interviewing user for intent, scanning project context, and outlining scope, success criteria, sequenced checklist. Use before implementation.
npx claudepluginhub wunki/amplify --plugin ask-questions-if-underspecifiedThis skill uses the workspace's default tool permissions.
Turns a user's engineering goal into a single, actionable plan document.
Generates executable Markdown implementation plans for multi-step tasks from context briefs, resolving ambiguities, ordering dependencies, and enabling parallel worker execution.
Creates detailed, phased implementation plans with sprints and atomic tasks for bugs, features, or tasks. Triggers on planning requests like 'make a plan' or /planner command.
Creates structured plans for multi-step tasks including software features, implementations, research, or projects. Deepens plans via interactive sub-agent reviews.
Share bugs, ideas, or general feedback.
Turns a user's engineering goal into a single, actionable plan document.
Operate as a senior engineer who interviews stakeholders, thinks deeply about problems, and produces clear, executable plans. Do not rush to output. Ask questions, verify understanding, and only then commit to a plan.
PLAN.md in project rootRead available project files to understand the landscape. Skip any that do not exist.
SPEC.md — if present, use as primary input; note which feature it describesREADME.md, docs/, CONTRIBUTING.md, ARCHITECTURE.mdIf none of these files exist (empty or unfamiliar repo), skip silently and proceed to the interview with no pre-loaded context.
If SPEC.md exists but describes a different feature than the user is planning, note the mismatch during the interview rather than treating it as primary input.
Do not output anything during the context scan.
For complex features: If no SPEC.md exists and the feature needs deep requirements gathering, suggest using the interview skill first to create one.
If the user provides zero context (just says "create a plan" with no subject), open the interview immediately by asking what they are building or changing.
Before planning, understand what the user actually wants — not just what they asked for.
Keep interviewing until understood:
| What to learn | Example questions |
|---|---|
| The real goal | "What problem does this solve? What does success look like?" |
| Context | "Why now? What triggered this?" |
| Constraints | "Any deadlines, dependencies, or things that can't change?" |
| Failed attempts | "Anything you've tried or ruled out?" |
| Concerns | "What are you most uncertain about? What would you regret in 6 months?" |
Interview style:
1a 2bExit when: Goal, success criteria, context, constraints, and concerns are clear. This may take zero questions (user was thorough) or several (complex request).
If user skips the interview: Proceed to Step 3 immediately. Capture all unresolved gaps as Assumptions in the plan.
If user rejects the escape hatch (see below) and still wants a plan: proceed to Step 3 and write the plan without further pushback.
Challenge the premise early: If the goal seems misguided or solvable by deleting code or using existing primitives, say so. Better to challenge before planning than to plan something that should not be built.
Escape hatch: If the task is clearly trivial — single-file change, well-understood fix, no coordination needed, no risk of wrong direction — say so and offer to just do it instead. Not everything needs a PLAN.md.
Once what and why are understood, resolve how. Use closed questions with concrete options:
"Critical" means: an unknown that would force a different architecture, a different file structure, or a different sequence of tasks. Unknown-but-guessable details (exact variable names, minor config values) are not critical — capture them as Assumptions.
If critical unknowns remain, ask before proceeding to Step 4. If only minor unknowns remain, proceed with clear Assumptions captured in the plan.
Before writing the plan, work through these stages internally:
A. Design the approach
B. Decompose into atomic tasks
C. Validate each task
For each task, ask:
D. Stress test the whole
Plan quality depends on completing this thinking before writing.
If gaps are discovered: Return to earlier steps. If decomposition reveals missing understanding, go back and ask. If validation shows the approach is wrong, redesign. Planning is iterative, but cap retries at two rounds before proceeding with documented assumptions.
Determine output location:
PLAN.md in project rootPhase advancement: If the user is advancing to the next phase of an existing plan (e.g., "phase 1 is done, plan phase 2"), re-run Steps 1-4 for the next phase, then overwrite the Action Items section in PLAN.md with the new phase tasks. Update the phase header. Preserve the Scope, Success Criteria, and Assumptions sections unless they changed. No overwrite confirmation needed for phase advancement — the user explicitly requested it.
Write the plan using the template below. Write only the plan — no meta explanations, preamble, or commentary.
For optional sections: Omit Assumptions if no assumptions were made. Omit Clarifications if no questions were asked during the interview.
For large work, split into phases:
PLAN.md (current work)Phase advancement is user-triggered. When the user says the current phase is complete or asks to plan the next phase, follow the Phase advancement instruction in Step 5. Keep long-term context in SPEC.md.
# Plan: [short descriptive title]
[1-3 sentences: what we're doing, why, and the high-level approach.]
## Scope
**In:** [what's included]
**Out:** [what's explicitly excluded]
## Success Criteria
- [What "done" means in observable terms]
## Assumptions
- [Assumption 1]
- [Assumption 2]
## Action Items
- [ ] [Step 1]
- [ ] [Step 2]
- [ ] [Step 3]
## Clarifications
> **Q:** [Question asked during planning]
> **A:** [Answer received]
Good action items:
src/auth/, app/api/npm test", "Verify OAuth flow in browser"Avoid:
Always include:
Before finishing, verify: