vc-generate-plan

name	vc-generate-plan
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
layer	contract
metadata	{"author":"vibecode-pro-max-kit","version":"1.0.0"}

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

1. Read references/generate-plan.md for the full plan contract.
2. Run date +%d-%m-%y before choosing the filename.
3. If complexity is not obvious, ask whether the plan is SIMPLE or COMPLEX.
4. Save the plan inside a task folder: process/general-plans/active/{slug}_{date}/{slug}_PLAN_{date}.md (or process/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 sibling reports/ or references/ dirs.
5. Read process/context/all-context.md when present to choose relevant context docs.
6. For complex plans, read .claude/skills/vc-generate-plan/references/example-complex-prd.md before writing.
7. Include automated and manual verification gates from process/context/tests/all-tests.md.
8. For new or newly touched direct *_PLAN_*.md plans, include explicit sections for Touchpoints, Public Contracts, Blast Radius, Verification Evidence, Test Infra Improvement Notes, and Resume and Execution Handoff.
9. Keep resume/dependency notes Markdown-structured for now; do not invent a second machine-only schema.
10. 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

11. 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, not VERIFIED.
• 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 read
• Public Contracts — interfaces, APIs, schemas, or behaviors visible to other packages or callers
• Blast Radius — the scope of change: how many files, which packages, and what risk class
• Verification 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 EVL
• Resume and Execution Handoff — required sub-fields:
  1. selected plan file path
  2. last completed phase or step
  3. validate-contract status (written / skipped with reason / pending)
  4. supporting context files loaded
  5. 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.