vc-generate-plan
GitHub用于将想法或PRD转化为仓库中的标准实施计划文档。支持简单与复杂格式,自动管理文件路径、上下文读取及验证脚本,确保产出符合项目规范的权威计划工件集。
Trigger Scenarios
Install
npx skills add withkynam/vibecode-pro-max-kit --skill vc-generate-plan -g -y
SKILL.md
Frontmatter
{
"name": "vc-generate-plan",
"layer": "contract",
"metadata": {
"author": "vibecode-pro-max-kit",
"version": "1.0.0"
},
"description": "Create or update implementation plans in the repo's SIMPLE or COMPLEX format. Use when turning an idea, PRD, or approved direction into a saved plan artifact.",
"trigger_keywords": "plan, create plan, write plan, generate spec, plan artifact"
}
Generate Plan
Output style: write the plan answer-first with tables/bullets and a one-line TL;DR per the canonical rule —
process/development-protocols/communication-standards.md.
Use this skill to produce the authoritative implementation plan artifact set for the project's work.
This skill is the canonical planning contract for the repo. Planning discipline previously spread across vc-plan now belongs here plus the plan-agent prompt.
Normal output is one plan file.
For large multi-phase programs, this skill instead defines how to create an umbrella plan plus
phase-plan set under one feature folder. See process/development-protocols/phase-programs.md.
Optional input: a feature idea plus simple or complex when the user already knows the intended depth.
Workflow
- Read
references/generate-plan.mdfor the full plan contract. - Run
date +%d-%m-%ybefore choosing the filename. - If complexity is not obvious, ask whether the plan is
SIMPLEorCOMPLEX. - Save the plan inside a task folder:
process/general-plans/active/{slug}_{date}/{slug}_PLAN_{date}.md(orprocess/features/{feature}/active/{slug}_{date}/{slug}_PLAN_{date}.md). Create the{slug}_{date}/subfolder first. Per task-folder artefact colocation, every artefact this plan produces — the plan, any{slug}_SPEC_{date}.md, reports, and references — lives INSIDE this same task folder; never write to the deprecated siblingreports/orreferences/dirs. - Read
process/context/all-context.mdwhen present to choose relevant context docs. - For complex plans, read
.claude/skills/vc-generate-plan/references/example-complex-prd.mdbefore writing. - Include automated and manual verification gates from
process/context/tests/all-tests.md. - For new or newly touched direct
*_PLAN_*.mdplans, include explicit sections forTouchpoints,Public Contracts,Blast Radius,Verification Evidence,Test Infra Improvement Notes, andResume and Execution Handoff. - Keep resume/dependency notes Markdown-structured for now; do not invent a second machine-only schema.
- If the work is a large multi-phase program, create or update a feature folder plan set:
- one umbrella/orchestration plan
- one direct plan file per phase
- one durable report destination per phase
- Validate the generated artifact:
node .claude/skills/vc-generate-plan/scripts/validate-plan-artifact.mjs <plan-path>
Important Rules
- For standard work, create exactly one plan file.
- For a phase program, create one umbrella plan plus one direct plan file per phase.
- Prefer
process/features/{feature}/active/{slug}_{date}/task folder when the topic maps to an existing feature folder. - Keep phase status honest: code-only completion is
CODE DONE, notVERIFIED. - Make execution trust explicit inside the plan: what code or data can change, what contracts are exposed, what proof is required, and how EXECUTE should resume after compaction.
- End with the next instruction for RIPER-5 or Cursor Plan mode.
- Treat validation failures as blockers before presenting the plan as ready.
- Fold red-team questions, dependency mapping, verification gates, and ambiguity checks into the generated plan itself instead of relying on a parallel plan-owner workflow.
- Do not hide a large program inside one giant plan if execution will actually happen phase by phase.
- Preserve the older complex-plan behavior by keeping pre-phase research and proof gates inside each phase plan; the new protocol changes the artifact shape, not the rigor.
Required Plan Sections
For new or newly touched direct *_PLAN_*.md files, include all of the following sections:
Touchpoints— files, packages, or services that will be changed or readPublic Contracts— interfaces, APIs, schemas, or behaviors visible to other packages or callersBlast Radius— the scope of change: how many files, which packages, and what risk classVerification Evidence— table with columns| Gate / Scenario | Strategy | Proves SPEC criterion |; each row maps a test gate to the SPEC acceptance criterion it proves and the strategy (Fully-Automated / Hybrid / Agent-Probe)Test Infra Improvement Notes— placeholder at plan-write time ("(none identified yet)"); updated with test infrastructure gaps found during vc-test-coverage-plan and EVLResume and Execution Handoff— required sub-fields:- selected plan file path
- last completed phase or step
- validate-contract status (written / skipped with reason / pending)
- supporting context files loaded
- next step for a fresh agent picking up mid-execution
Validate Contract— written by vc-validate-agent after VALIDATE runs; leave a placeholder heading during PLAN (## Validate Contract\n\n(placeholder — vc-validate-agent writes this section before EXECUTE))
Use Markdown-structured sections, not a second machine-only schema. Markdown sections are stable across all agents (Claude, Codex, future systems) without requiring a parser.
Version History
- 3bcb2f9 Current 2026-07-05 14:35


