vc-plan-discovery
vc-plan-discovery discovers all plans related to the current task by scanning same-feature folders at full depth (active, backlog, completed) while reading only active plans from other feature folders and always including general-plans. Use this skill before beginning work to surface the complete plan context, including in-progress efforts, deferred items, completed work, reports, and references relevant to the task domain.
git clone --depth 1 https://github.com/withkynam/vibecode-pro-max-kit /tmp/vc-plan-discovery && cp -r /tmp/vc-plan-discovery/.claude/skills/vc-plan-discovery ~/.claude/skills/vc-plan-discoverySKILL.md
# vc-plan-discovery
> **Output style:** Follow `process/development-protocols/communication-standards.md` — answer-first, plain language, no unexplained jargon, TL;DR on long responses.
## Invocation
**Primary method** — run the auto-discovery script. It applies the Scope Rules below
(same-feature full depth; other features active-only; general-plans active always) and
extracts ONLY the leading YAML frontmatter block of each `.md` file (no whole-file reads):
```bash
node .claude/skills/vc-plan-discovery/scripts/discover-plans.mjs [--feature <name>] [--json]
```
It groups output into Active Plans / Backlog / Completed / Reports / References (each line:
`- [name]: description (path)`) and prints a trailing `Found N active, N backlog, N
completed, N reports, N references` line. It never throws on a missing root and exits 0
unless given a bad flag. Use `--json` for a machine-readable object. Prefer this over the
manual scan below — it is deterministic and avoids loading huge files into context.
Per **task-folder artefact colocation**, the script scans one level into each
`{slug}_{date}/` task folder and surfaces co-located `_PLAN_`/`_REPORT_`/`_REF_` artefacts;
the sibling `reports/`/`references/` dirs are deprecated and only hold legacy artefacts.
The manual scan in **Scope Rules** below is the FALLBACK for when the script fails.
## Purpose
Surface all plans relevant to the current task so agents have full plan context — what was tried, what is in progress, what is deferred, and what reports and references exist — before doing any phase work.
## Scope Rules
- **Same feature folder** (from task context or argument): read ALL of `active/`, `backlog/`, `completed/`, plus any legacy sibling `reports/`, `references/` — surface every file with frontmatter
- **Other feature folders**: read `active/` only — surface plans whose frontmatter `description` or `feature` field matches the task domain
- **`general-plans/active/`**: always scan
- **`general-plans/completed/`, legacy `reports/`, `references/`**: scan only when same-feature folder is not identified
Per **task-folder artefact colocation**, expect every current artefact (plan, spec, reports, references) INSIDE its `{slug}_{date}/` task folder — scan one level into each task folder. The sibling `reports/`/`references/` dirs are deprecated and only hold legacy artefacts.
## Frontmatter Reading
Read frontmatter fields: `name`, `description`, `type`, `feature`, `phase`
Route by `description` field for relevance matching (same approach as vc-context-discovery).
Skip files without frontmatter or with incomplete frontmatter — log as "no frontmatter, skipped".
Output: grouped list by folder — Active Plans / Backlog / Completed / Reports / References — with name + description per file.
## When To Invoke
- First action alongside `vc-context-discovery` at the start of every loop step (research / validate / execute / update-process)
- Any time an agent needs to know: what plans exist for this feature, what was tried before, what is deferred, what references exist
## Output Format
```
### Active Plans
- [name]: description (path)
### Backlog
- [name]: description (path)
### Completed
- [name]: description (path)
### Reports
- [name]: description (path)
### References
- [name]: description (path)
Found N active, N backlog, N completed, N reports, N references
```Comprehensive code review with scout-based edge case detection. Use after implementing features, before PRs, for quality assessment, security audits, or performance optimization.
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
Use this agent when you need to investigate issues, analyze system behavior, diagnose performance problems, examine database structures, collect and analyze logs from servers or CI/CD pipelines, run tests for debugging purposes, or optimize system performance. This includes troubleshooting errors, identifying bottlenecks, analyzing failed deployments, investigating test failures, and creating diagnostic reports. Examples:\n\n<example>\nContext: The user needs to investigate why an API endpoint is returning 500 errors.\nuser: "The /api/users endpoint is throwing 500 errors"\nassistant: "I''ll use the debugger agent to investigate this issue"\n<commentary>\nSince this involves investigating an issue, use the Task tool to launch the debugger agent.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to analyze why the CI/CD pipeline is failing.\nuser: "The GitHub Actions workflow keeps failing on the test step"\nassistant: "Let me use the debugger agent to analyze the CI/CD pipeline logs and identify the issue"\n<commentary>\nThis requires analyzing CI/CD logs and test failures, so use the debugger agent.\n</commentary>\n</example>\n\n<example>\nContext: The user notices performance degradation in the application.\nuser: "The application response times have increased by 300% since yesterday"\nassistant: "I''ll launch the debugger agent to analyze system behavior and identify performance bottlenecks"\n<commentary>\nPerformance analysis and bottleneck identification requires the debugger agent.\n</commentary>\n</example>
EXECUTE MODE - Implementing EXACTLY what was planned. Full tool access. Can only be invoked after explicit user confirmation. Use after plan is approved.
FAST MODE - Execute compressed RIPER-5 workflow (RESEARCH + INNOVATE + PLAN) in one session, then pause for EXECUTE confirmation. Use when you want quick end-to-end solution.
Stage, commit, and push code changes with conventional commits. Use when user says "commit", "push", or finishes a feature/fix.
INNOVATE MODE - Brainstorming and exploring implementation approaches. Discusses possibilities without making decisions. Use after research is complete.
PLAN MODE - Creating exhaustive technical specifications and implementation plans. Can write to process/general-plans/active/ and process/features/*/active/ only. Use after approach is decided.