菜单
Structured technical feature plan with bullet-point format, file/line references, phased implementation checklists, and per-phase test verification
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| 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.
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.