菜单
Use when turning a feature spec into a step-by-step implementation plan - file-level changes, order, checkpoints, and risks
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the meta-builder routes to kind=discipline. Generates a discipline spell with the rule, excuses table, warning signs, and hard gates.
Use when the user wants to capture a repeatable task as a reusable spell, or asks "how do I build a workflow / skill / framework for X"
Use when the meta-builder routes to kind=subagent. Generates a spell that dispatches one or more subagents to do work in parallel or in isolation.
Use when the meta-builder routes to kind=workflow. Generates a workflow spell with explicit stages, checkpoints, and loop-back conditions.
Use when composing multiple spells into a chain that runs end-to-end (e.g. brainstorm -> plan -> execute -> verify).
Use when browsing what spells are available - bundled seeds, your personal library, or both. Filter by kind, audience, or update status.
| name | writing-an-implementation-plan |
| description | Use when turning a feature spec into a step-by-step implementation plan - file-level changes, order, checkpoints, and risks |
| kind | workflow |
| audience | dev |
| ai-tools | any |
| complexity | guided |
| time | 30-90 min |
| version | 1.0.0 |
| source | bundled |
Turns a feature spec (output of brainstorming-a-feature, or a written PRD) into an executable implementation plan: file-level changes, ordering, checkpoints, risks, and rollback. Designed so a different person — or future-you in a different session — could execute it without asking clarifying questions.
A plan document with: scope, file-level changes (paths + what changes), ordering with dependencies, per-step verification, risks and rollback, and the acceptance criteria.
This is a workflow.
In one paragraph, restate what's being built and what's explicitly out of scope. Out-of-scope is critical — it prevents drift mid-implementation.
Walk the codebase and list every file that needs to change. For each: full path + 1-3 line description of what changes there.
If you're adding new files, list them too.
If you're not sure which files need to change for a given concern, that's a discovery task — note it explicitly.
Order is important. Rules of thumb:
For each step: how will you know it worked? Examples:
If a step has no verification, it's not done — split it into substeps that do.
What could go wrong? For each risk: likelihood, impact, and mitigation or rollback.
Common risks:
How does the user / reviewer / customer know this feature is complete? List 3-7 specific, testable conditions.
For each step: rough hours. For the whole plan: total + buffer (typical: 30%).
Input: Approach from brainstorm — add SSO via Auth0 SAML.
Output (plan excerpt):
backend/auth/saml.ts (new) — SAML response handlingbackend/auth/middleware.ts — add SAML branchbackend/db/migrations/2026_04_19_sso.sql — add sso_provider, sso_external_id columnsfrontend/login/SSOButton.tsx (new) — entry buttondocs/admin/sso-setup.md (new)