القائمة
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)