Menu
Structured technical feature plan with bullet-point format, file/line references, phased implementation checklists, and per-phase test verification
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Android/Kotlin/Compose coding rules โ modular architecture, ViewModel scope, Material 3, Compose pitfalls, strings, navigation, network safety, and build hygiene. Extends `coding` + `coding-agent-guardrails`.
Universal code quality guardrails โ file size limits, code structure, VCS discipline, and build behavior for any project
Universal coding rules for any project type โ error handling, testing, API design, dependency hygiene, config/secrets, logging. Extends `coding-agent-guardrails`.
Product requirements document for larger features โ user-facing behavior, options, decisions, screen layouts, and open questions. Precedes the technical plan.
One-shot investigation โ findings document. No state, no checklist, no phases โ investigate, write the answer, stop.
Orchestrates the full agentic SDLC โ PRD โ Plan โ Review โ Implement โ Verify โ Review โ with pluggable reviewer model, feature/sub-feature decomposition, and resumable state.
| name | planning |
| description | Structured technical feature plan with bullet-point format, file/line references, phased implementation checklists, and per-phase test verification |
| version | 0.2.0 |
| triggers | ["plan a feature","write a feature plan","write a technical plan","/plan"] |
| globs | [".vibekit/feature-plans/**"] |
Use this skill whenever you are about to start non-trivial implementation work and want to align on the approach before writing code.
For larger features (new user-facing flows, multi-screen changes, data model changes):
/prd) โ captures what and why, options, decisions, screen layoutsPRD: frontmatter fieldFor smaller work (bug fixes, refactors, single-screen changes), skip the PRD and start here.
.vibekit/feature-plans/pending/<feature>/ (primary โ directory mode)
.vibekit/feature-plans/pending/<feature>/plan-<feature>.md.vibekit/feature-plans/pending/<feature>/NN-<sub>/plan-<NN>-<feature>-<sub>.md.vibekit/feature-plans/pending/<slug>.md file still works โ see Detection rule belowFORMAT.md โ read this before writing or implementing:
N.T1, N.T2 โฆ)SECTIONS.md โ what each section of the plan contains, diagram-type tablewip/ when work begins, done/ when complete_template_plan.md โ the default. Carries the implementation checklist.
Use it for any work you will actually execute, however large.
It may spawn sub-plans (bug bundles, follow-ups) and still keeps its own checklist.
_template_arch.md โ only when a feature needs system-level decomposition
before anything is executable. No implementation phases; its output is parts,
each of which is a plan.
If unsure: use plan
Most features never need an arch
| Doc | Pattern | Example |
|---|---|---|
| Master PRD | prd-<feature>.md | prd-auth-flow.md |
| Master plan | plan-<feature>.md | plan-auth-flow.md |
| Master arch (rare) | arch-<feature>.md | arch-auth-flow.md |
| Sub-feature PRD | prd-<NN>-<feature>-<subfeature>.md | prd-02-auth-flow-api.md |
| Sub-feature plan | plan-<NN>-<feature>-<subfeature>.md | plan-02-auth-flow-api.md |
NN in every sub-feature filename โ execution order is visible in flat search results and editor tabs, where the parent directory isn't shownNN is assigned once and never renumbered โ new sub-features always append; a bug bundle found after 03 becomes 04, never 02.5given <name> under pending|wip|done:
<name>/ is a directory โ directory mode; read <name>/.sdlc-state.yaml if present
<name>.md is a file โ flat mode; no state file, no sub-features
both exist โ prefer directory; warn about the stray flat file
./scaffold.sh /path/to/project
This creates .vibekit/feature-plans/{pending,wip,done}/ and copies the template + agent guide into the target project.