菜单
Creates implementation-ready plans through discovery interviews, external research, and codebase analysis. Covers requirements, competitor research, architecture decisions, and change sequencing. Use when planning features, roadmaps, specs, or any work that needs discovery before coding
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | planning |
| description | Creates implementation-ready plans through discovery interviews, external research, and codebase analysis. Covers requirements, competitor research, architecture decisions, and change sequencing. Use when planning features, roadmaps, specs, or any work that needs discovery before coding |
Create concrete, implementation-ready plans for features and complex changes.
DO NOT write code during planning. Only explore, research, analyze, and document. Be thorough.
| File | Read When |
|---|---|
references/discovery-interview.md | Starting the discovery phase or need guidance on what questions to ask |
references/research-strategy.md | Planning external research or launching sub-agents for competitor/pattern research |
references/plan-templates.md | Constructing the plan or reviewing plan quality — contains worked examples |
Before deep planning, gauge the scope:
For light planning, skip directly to a short outline: what file, what change, why.
Conduct a thorough interview to surface requirements, constraints, and context the user may not have considered yet.
How to interview:
What makes a good question:
What makes a bad question:
package.json, the codebase, or the project's AGENTS/CLAUDE.mdIf you can determine something from context, state your assumption and move on. Don't ask — inform.
Question domains (not exhaustive — use judgment):
Read references/discovery-interview.md for detailed question categories and examples of strong vs weak questions.
Go beyond the codebase. Not every plan needs this — skip when the feature is purely internal, the approach is well-established, or the user has provided sufficient context.
When to research:
What to research:
How to research:
Read references/research-strategy.md for guidance on structuring research queries and synthesizing findings.
Explore the codebase systematically. Use sub-agents for parallel exploration when the codebase is large or the feature touches multiple systems.
What to map:
Document findings as:
path/to/file.ext — what it does, how it's relevantSynthesize discovery, research, and analysis into an implementation-ready plan.
Describe outcomes, not mechanical steps. "Make the auth middleware reject expired tokens and return 401" beats "Add an if-statement checking token.exp against Date.now()." Specify what the change should achieve — let the implementer choose the approach.
For each change, specify:
Structuring the plan:
Plan output format (flat list):
## Goal
[One sentence: what we're building and why]
## Research Insights
[Key findings from external research that informed the plan]
[Skip this section if no external research was done]
## Changes
### 1. [Description]
- **File**: `path/to/file.ext`
- **Target**: `functionName()` / `ComponentName` / relevant section
- **Action**: What specifically to add, modify, or remove
- **Reasoning**: Why this change is needed
- **Depends on**: What must happen first, or "Nothing"
- **Verify**: How to confirm this change works — specific, observable behavior
### 2. [Description]
...
## Edge Cases & Risks
- [Specific scenario and how the plan addresses it]
- [Risk and mitigation strategy]
## Validation
- [ ] Specific, testable acceptance criterion
- [ ] Another criterion
- [ ] Edge case X is handled
Plan output format (phased grouping):
## Goal
[One sentence: what we're building and why]
## Research Insights
[Key findings from external research that informed the plan]
[Skip this section if no external research was done]
## Phase 1: [Phase Name, e.g. "Data Model"]
### 1. [Description]
- **File**: `path/to/file.ext`
- **Target**: `functionName()` / `ComponentName` / relevant section
- **Action**: What specifically to add, modify, or remove
- **Reasoning**: Why this change is needed
- **Depends on**: What must happen first, or "Nothing"
- **Verify**: How to confirm this change works — specific, observable behavior
### 2. [Description]
...
**Checkpoint**: [How to verify this phase works before moving on]
## Phase 2: [Phase Name, e.g. "API Layer"]
### 3. [Description]
...
**Checkpoint**: [How to verify this phase works before moving on]
## Phase 3: [Phase Name, e.g. "UI"]
### 4. [Description]
...
**Checkpoint**: [How to verify this phase works before moving on]
## Edge Cases & Risks
- [Specific scenario and how the plan addresses it]
- [Risk and mitigation strategy]
## Validation
- [ ] Specific, testable acceptance criterion
- [ ] Another criterion
- [ ] Edge case X is handled
For complex features, include test descriptions in the Validation section: what test file, what test case name, and what it asserts.
For multi-session features, optionally add these sections to the plan:
Keep the plan file updated as implementation proceeds — it becomes the source of truth.
If the user confirmed the plan will be executed via a loop (always ask about loop execution in Phase 1 — phrase it as an option: "Will you implement this via an autonomous loop?"):
IMPLEMENTATION_PLAN.md — always use this exact filename. Place it in the project root by default, or in the project's established plan directory (e.g., docs/plans/IMPLEMENTATION_PLAN.md) if one exists. Never use a custom or descriptive filename — the loop script searches for this exact name- [ ] [Description] — [file path] — [brief approach]## Notes section). There is no separate plan document to point at — IMPLEMENTATION_PLAN.md must be fully self-containedALL_TASKS_COMPLETE at the start of the file. Include a comment at the top of the generated plan: <!-- When all tasks are done, the loop agent prepends ALL_TASKS_COMPLETE above this line -->There is only ever one plan file: IMPLEMENTATION_PLAN.md. It holds both the context and the executable task list. Never split the rich context into a second document (e.g. docs/plans/<feature>.md) and have the task list reference it — that produces two plan files, which is exactly what to avoid.
Agent capabilities: Do not assume art or asset tasks are human-only. Agents may have skills for sprite creation, image generation, or other asset work. Plan these as normal tasks — the implementing agent will check its available skills and attempt them. Only mark a task as requiring human input when it genuinely cannot be automated (e.g., subjective creative direction, licensing decisions).
Writing good Verify fields: Use type-appropriate checks so the implementing agent knows what to confirm beyond "does it build?" Common patterns:
Tasks that produce temporary placeholders should be marked Done (placeholder) with a follow-up task created immediately.
Write the completed plan to a single markdown file so it survives beyond this session.
Produce exactly one plan file, always named IMPLEMENTATION_PLAN.md. Never create a second plan document — no docs/plans/<feature>.md, no companion "full context" file, no descriptive filename like auth-refactor-plan.md or feature-roadmap.md. All context, structure, and tasks live in the one IMPLEMENTATION_PLAN.md. This exact filename is what the loop script and other tooling searches for, and keeping everything in one file is what keeps the plan clear.
IMPLEMENTATION_PLAN.md in the project root by defaultdocs/plans/), place it there instead — but the filename must still be exactly IMPLEMENTATION_PLAN.md, and it remains the only plan fileThis file is temporary. Once the work is fully implemented and audited, the user deletes IMPLEMENTATION_PLAN.md. So nothing in it is a long-term record. Any decision, constraint, rationale, or "why" that must outlive implementation has to be captured where it persists — concise but clear code comments and front matter at the point it's relevant — not left only in the plan. When writing the plan, flag durable knowledge (non-obvious rationale, business logic, gotchas, invariants) so the implementing agent knows to encode it in the code itself before the plan is discarded.
If an IMPLEMENTATION_PLAN.md already exists, do not overwrite or append to it without checking. Read it first. If it is already complete (all tasks done / superseded), it's safe to replace. But if it contains an unfinished plan — open tasks, partial progress — stop and ask the user how to proceed. Offer to write the new plan to a separate, distinctly-named file instead, e.g. [CUSTOM_NAME]_IMPLEMENTATION_PLAN.md (with a descriptive CUSTOM_NAME), so the in-progress plan is preserved. Note that loop tooling searches for the exact name IMPLEMENTATION_PLAN.md, so a custom-named file won't be picked up by the loop until renamed — surface this tradeoff when offering the option.
After constructing the plan, stress-test it with fresh perspectives. This catches blind spots, underspecified areas, and risks that confirmation bias hides.
Process (3 rounds):
For each round, spawn a Task subagent (subagent_type: "general-purpose") with:
After each round:
When to skip:
Key constraint: Each subagent must receive ONLY the plan document, not the conversation history. The value comes from fresh eyes with zero context about the decisions that led to the plan.
Before delivering the plan, verify:
| Avoid | Do Instead |
|---|---|
| "Update the authentication system" | "Modify auth/middleware.ts — add validateSession() that checks token expiry" |
| "Add error handling" | "Wrap the API call in auth/api.ts with try/catch, show toast on error" |
| "Use the standard pattern" | "Follow the existing pattern from user/dao.ts (class-based with explicit types)" |
| "Make sure it works" | "Verify: (1) form submits on Enter, (2) inline errors display, (3) submit disabled during request" |
| Asking "What framework do you use?" | Read package.json and state: "I see you're using Next.js with App Router" |
| Specifying line numbers | Reference file path + function/component name |
| Skipping research for novel features | Launch sub-agents to research competitor patterns and technical approaches |
| Asking one question then moving on | Continue the interview until all meaningful questions are covered |
Generates an autonomous implementation loop that executes tasks from a plan across Claude sessions, with periodic audit passes that inject follow-up tasks. Covers loop script, prompt design, and audit cadence. Use when setting up autonomous task execution or Ralph-style iterative workflows
Generates an autonomous game design loop that iteratively expands a game concept into a comprehensive vision and implementation plan across multiple sessions. Covers mechanic exploration, system design, competitor research, and plan generation. Use when developing a game idea from seed concept to full implementation plan
Guides creation of high-quality frontend interfaces using proven design principles for color, typography, spacing, layout, depth, animation, and UX. Covers both building new UIs and auditing existing ones. Use when creating web components, pages, or applications, or when reviewing frontend code for design quality
Guides creation of agent skills following best practices and the open format specification. Covers pattern selection, frontmatter, directory structure, reference files, validation, and iteration. Use when creating a new skill, updating SKILL.md, or asking "how to write a skill"
Runs an adversarial code review loop that spawns independent reviewer and fixer subagents, iterating until only nitpicks remain. Scores findings by confidence, fixes real issues, and re-reviews with fresh eyes — all internal, no GitHub comments. Use when asked to review code, self-review, adversarial review, or polish code before pushing
Blocks all file writes and edits outside a specified directory for the rest of the session. Use when debugging, investigating, or doing exploratory work where you want to prevent accidental modifications to unrelated code. Pass the allowed directory as an argument, e.g. /freezing-edits src/components