From vgv-wingspan
Executes implementation plans from docs/plan/: implements tasks with code and tests, runs parallel quality reviews, validates, and ships pull requests.
npx claudepluginhub verygoodopensource/very_good_claude_code_marketplace --plugin vgv-wingspanThis skill is limited to using the following tools:
Take a plan from `docs/plan/` and turn it into shipped code: implement features, write tests, and validate quality.
Executes written implementation plans using fresh subagents per task with TDD cycles, mandatory code reviews, and quality gates before proceeding.
Executes a development plan step-by-step: loads plan, breaks into atomic verifiable steps, implements with per-step verification (build/test), checkpoints progress, final full check.
Executes tech plans via dependency-aware task batching, TDD, incremental commits, section code reviews, and PR creation. Use after planning phases.
Share bugs, ideas, or general feedback.
Take a plan from docs/plan/ and turn it into shipped code: implement features, write tests, and validate quality.
Copy this checklist and track your progress:
Build Progress:
- [ ] Phase 0: Load plan and confirm scope
- [ ] Phase 1: Read context files
- [ ] Phase 2: Implement and test each task
- [ ] Phase 3: Run review agents (5 in parallel)
- [ ] Phase 4: Final validation, cleanup, and ship
<plan_path>$ARGUMENTS</plan_path>
ls docs/plan/
| Plan path | Plans in docs/plan/ | Action |
|---|---|---|
| Provided | — | Read the file. If missing, suggest running /plan |
| Empty | One | Read it, announce "Found plan: [title]", proceed |
| Empty | Multiple | AskUserQuestion: list each with summary, ask which to use |
| Empty | None | Tell user to run /plan first |
Do not proceed without a plan.
After loading the plan: parse title, type, acceptance criteria, tasks, and file paths. Summarize scope to the user, then use AskUserQuestion to confirm:
Do not proceed until the user selects "Start building."
Do not run codebase-review-agent here. The plan was already informed by codebase context from /brainstorm and /plan.
Instead, use the plan itself as your guide:
Work through each task/phase in the plan, in order. For each task:
Write code following VGV conventions. Build layers in dependency order (Data → Domain → Presentation). Use the project's state management tool, naming patterns, linter, and formatter. Respect layer boundaries — presentation never imports data directly.
Tests are non-negotiable. Write them alongside each implementation unit:
Every new state management unit, repository, UI component, and data model must have a test file.
After implementing each task, follow the validation and fix procedure.
After each logical unit of work:
After all implementation tasks are complete, run 5 review agents in parallel.
Each agent prompt must include the review agent instructions with REPORT_DIR set to docs/reviews/.
The 5 agents and their report filenames:
| Agent | Report file |
|---|---|
| @vgv-review-agent | docs/reviews/vgv-review.md |
| @code-simplicity-review-agent | docs/reviews/code-simplicity-review.md |
| @test-quality-review-agent | docs/reviews/test-quality-review.md |
| @architecture-review-agent | docs/reviews/architecture-review.md |
| @pr-readiness-review-agent | docs/reviews/pr-readiness-review.md |
Follow the review consolidation procedure: categorize findings, auto-fix minor issues, fix critical issues, present important issues to the user, and record suggestions.
Run the full suite one last time — detect and use the project's formatter, linter, and test runner.
If anything fails, fix it before proceeding.
Remove the review reports — their findings have already been addressed or recorded:
rm -rf docs/reviews/
Stage all implementation and fix changes. Use this commit format:
<type>: <concise description of what was built>
Implements <plan title or summary>.
Where <type> matches the plan's type (feat, fix, refactor, etc.).
Call /create-pr skip-checks to push and open a PR. Validation already ran above. The PR body uses the PR template.
Use AskUserQuestion to present options:
docs/reviews/ and deleted after Phase 4. If the build is interrupted, stale reports may remain — delete them manually before the next run.