메뉴
Create implementation plans from a reviewed RFC. Uses the RFC as the approved design baseline, decomposes it into executable sub-plans, and runs RFC-specific plan review.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | planning-project-features-from-rfc |
| description | Create implementation plans from a reviewed RFC. Uses the RFC as the approved design baseline, decomposes it into executable sub-plans, and runs RFC-specific plan review. |
Create actionable implementation plans for features within a single project from a reviewed RFC. The RFC owns requirements, design decisions, constraints, goals, non-goals, risks, tradeoffs, and contracts. This skill turns that approved design into executable sub-plans.
This file is the RFC-backed planning spine. Load referenced files only when their trigger applies.
Before doing any work, determine the active runtime from the system prompt and environment banner, then read exactly one adapter:
If the runtime signal is ambiguous, ask the user rather than guessing. Do not load or mix other runtime adapters in the same turn. If a runtime adapter conflicts with this file, this file is authoritative.
Use runtime-native names when reading or writing concrete artifacts: worker agent definitions, dispatch recipes, custom subagents, reviewer bindings, or equivalent runtime bindings.
plan-rfc-fidelity-reviewer and plan-executability-reviewer. Do not run direct-planning design reviewers unless the user explicitly exits RFC-backed planning.| Trigger | Load |
|---|---|
| Validating the RFC, reading anchors, or exploring planning mechanics | references/rfc-baseline-exploration.md |
| Decomposing RFC scope into sub-plans or defining cross-boundary contracts | references/decomposition.md |
| Determining whether independent sub-plans may execute in parallel | references/concurrency-policy.md |
| Creating plan files, assigning models, or establishing execution bindings | references/plan-creation-and-bindings.md |
| Running plan review, presenting for approval, or handling feedback | references/review-and-approval.md |
| Planning documentation updates | references/documentation-sub-plan.md |
| Writing plan files | assets/master-plan-template.md, assets/sub-plan-template.md |
Use this workflow only after planning-project-features routed here because a reviewed RFC exists and the user wants RFC-backed planning.
Read the RFC and verify that required RFC reviews have no blocking status. Read an active feature anchor when one exists, but treat it as supporting handoff context only. If anchor content conflicts with the RFC or exposes unresolved decomposition, scope, acceptance-criteria, or contract questions, stop and ask.
Use rfc-baseline-exploration.md for validation details. If validation fails, return to planning-project-features routing instead of continuing.
Read existing documentation first, then inspect code only for planning mechanics the RFC or docs do not cover.
Confirm:
Do not use exploration to redesign the RFC. If exploration contradicts the RFC or implementation planning depends on behavior the RFC does not define, stop and ask whether to revise the RFC or approve a plan deviation.
Use rfc-baseline-exploration.md for exploration mechanics and gap handling.
Break the RFC into the smallest self-contained sub-plans that form a valid dependency DAG.
Apply concurrency-policy.md before assigning sub-plans to the same execution group. A restricted build ecosystem still gets multiple focused sub-plans, but the DAG must be linear.
Each sub-plan must include the RFC context, constraints, contracts, prerequisites, acceptance criteria, primary files, required skills, and execution model needed for independent execution. Preserve RFC non-goals and translate RFC risks into plan mechanics.
Use decomposition.md for boundary selection, DAG rules, embedded context, integration contracts, data-flow integrity, and documentation sub-plan triggers.
Present the proposed decomposition to the user before writing plan files when findings affect scope, sequencing, boundaries, or parallelism.
Only after baseline validation, exploration, and decomposition are complete:
00-master.md and numbered sub-plan files from the templates, including the master plan's concurrency policy.test-driven-development when available and appropriate.Use plan-creation-and-bindings.md for plan paths, model selection, binding rules, and master-plan execution mechanics.
Run the RFC-backed review loop before showing the plan to the user:
plan-rfc-fidelity-reviewerplan-executability-reviewerPass each reviewer the plan directory, RFC path, requested review output path, and review task. Store review artifacts in the plan's reviews/ directory. Incorporate findings and re-run only affected reviewers until no blocking findings remain.
If a finding requires changing the RFC design, stop and ask whether to revise the RFC or approve an explicit plan deviation.
Use review-and-approval.md for review artifact handling, reviewer exclusions, final consistency checks, and feedback classification.
Before presenting, run the final consistency check in review-and-approval.md. Fix inconsistencies first.
Present the reviewed plan with:
NoneRemind the user that the plan intentionally omits implementation details. They review architecture and constraints now; they review actual code after execution.
When the user requests changes, incorporate them and use review-and-approval.md to decide whether re-review is required.
If the project has component documentation, record that component-docs-reviewer should run after all sub-plans complete to catch implementation-vs-plan drift in component docs.
Read these templates when writing plan files:
plan-rfc-fidelity-reviewer and plan-executability-reviewer before presenting the plan.Use whenever executing, continuing, resuming, or finishing an implementation plan or plan directory. Orchestrates assigned worker dispatch, integrated test-first discipline, progress checkpointing, isolated workspaces, checkpoint integration, and blocker batching.
Create implementation plans directly from user requirements when no reviewed RFC is available or the user explicitly declines RFC-first planning. Decomposes work into self-contained sub-plans with full iterative multi-agent plan review.
Use whenever implementing or fixing production code, writing or changing tests, reviewing test quality, applying TDD, or diagnosing tests that pass without proving behavior. Ensures tests are requirement-grounded and reach behavioral RED before implementation.
Use when turning a settled design direction, brainstorming outcome, context anchor, or architecture discussion into a codebase-grounded RFC. Produces self-contained RFC documents with verified current architecture, chosen design, tradeoffs, risks, stable references, and planning handoff context without creating implementation plans.
Create project-specific plan reviewer agents that integrate with the planning-project-features workflow. Use when a project needs domain-specialized reviewers for sub-plans (e.g., Go code reviewer, API layer reviewer, database reviewer) or when the planner warns that no suitable local reviewer exists for a sub-plan's domain.
Decompose large efforts directly from user requirements when no reviewed RFC is available or the user explicitly declines RFC-first epic planning. Produces a persistent epic plan with rich feature descriptions that feed into planning-project-features separately.