From v-model
NASA V-Model systems engineering for building and verifying code. Use when implementing a non-trivial feature, building a system, or when asked to apply the "V-model", "systems engineering", "traceability", or rigorous "verify and validate" approach. Drives a task down the left side (define each level plus its paired verification plan), implements at the bottom, then climbs the right side verifying bottom-up and validating against the original intent.
How this skill is triggered — by the user, by Claude, or both
Slash command
/v-model:v-modelThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The NASA V-Model adds three things generic planning modes lack: **leveled
The NASA V-Model adds three things generic planning modes lack: leveled altitude, paired verification defined on the way down, and a traceability matrix that is the spine of the work. Use those three, or this is just planning.
This is a rigid workflow. Follow the phases in order. The tailoring gate (Phase 0) is what keeps it from becoming ceremony on small tasks — do not skip it.
Classify the task, state the classification to the user, and let them override before proceeding:
| Tier | Trigger | What you run |
|---|---|---|
| trivial | one-liner, isolated bugfix, config change | Skip the middle levels. Write a single traceability.md: one-line intent, one row, one verification (a test). Implement. Verify. Done. |
| feature | a single coherent capability / one subsystem | Full single V (below). |
| system | multiple interacting subsystems | Decompose into sub-Vs — run a feature-tier V per subsystem — under one system-level V (one ConOps, one system-level validation). |
Announce: V-Model tailoring: <tier> — <one-line reason>. Override if wrong.
At each level you define what, and in the same step write that level's verification plan. Never descend before the paired verification exists.
conops.md: why this exists, for whom, and what success
looks like in the user's world. Paired: a System Validation Plan — concrete
acceptance scenarios phrased in user terms ("when the user does X, they see Y").requirements.md: observable behaviors and
constraints, each tagged with a stable REQ-id (REQ-1, REQ-2, …). Paired:
a System Verification Plan — how each REQ will be checked at the system boundary.design.md (design section): the
modules/components and their interfaces; allocate every REQ to a subsystem.
Paired: a Subsystem Verification Plan — the integration checks per interface.design.md: per-component behavior,
signatures, and edge cases. Paired: a Component Verification Procedure — the
exact unit tests (names + what each asserts), written before any implementation.Then build the Traceability Matrix in traceability.md:
| REQ | Subsystem | Component | Verification ID | Status |
|---|---|---|---|---|
| REQ-1 | … | … | V-1 (unit) | ☐ |
Every REQ must appear. Every row must name the verification that will prove it.
Write the code and the tests already specified in the L4 Component Verification Procedures. Because the test specs already exist, this is naturally test-first.
Verify bottom-up against the plans you wrote on the descent, then validate:
REQ must
show PASS with evidence (command + result). "Did we build it right?"Done is decided by your project's real tools, not by self-report and not by a bespoke checker. Three parts:
REQ states how it is verified — a concrete test, or a type-check, lint,
build, or explicit human review. If you can't name how a REQ is verified, it
isn't granular enough — split it. (This is the matrix's verification column.)REQ's named test
is one that command actually runs. Determinism comes from the runner, never from
prose — only mark a row ☑ against a test you watched the runner pass.Guard against tests that pass without proving anything — not with more checking code, but with discipline the test framework already gives you:
Trust nothing self-reported. The proof is strongest when something other than the implementer (a separate review pass, or the human) runs the command and reads the result; a self-reported "done" is a claim, not evidence.
Untraced code is either dead work (remove it) or a missing requirement (add the
REQ and its verification). Untested code does not ship.
REQ it traces to.REQ without a verification.Write everything under docs/v-model/<slug>/:
conops.md — intent + validation scenarios (L1)requirements.md — REQ-ids + system verification plan (L2)design.md — subsystem + component design + their verification plans (L3, L4)traceability.md — the live matrix; update Status as you climb the right sideTrivial tier writes only traceability.md.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub omar-a-hassan/vee --plugin v-model