From codex-next
Creates explicit validation plans linking requirements to checks, evidence, gaps, risks, and release gates. Use before implementation or release to define how correctness will be proven.
How this skill is triggered — by the user, by Claude, or both
Slash command
/codex-next:sdlc-validation-plan-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this workflow to define how a change will be proven correct before implementation, review, or release.
Use this workflow to define how a change will be proven correct before implementation, review, or release.
This is not a missing testing capability. It is an SDLC-manager artifact that makes the validation contract explicit:
Validation Plan defines how correctness will be proven.
dev executes, extends, or reports against that plan.
dev_test_runner or the relevant dev agent.dev-test-strategy.dev-release-check when release execution is the main work.Absence of a formal validation plan is not an automatic stop condition for clear direct-dev tasks.
For lane, ADS, lightweight ID, local/sdlc, delivery card, and midstream intake vocabulary, follow ../sdlc-router/references/sdlc-operating-model.md.
Use the best available sources. Do not require every artifact family.
If inputs are weak, produce a validation seed and mark assumptions instead of inventing requirements.
Choose the smallest sufficient validation depth.
| Depth | Use when | Output |
|---|---|---|
seed | direct-dev or bugfix with clear evidence | source -> expected behavior -> smallest check |
feature | contained feature or behavior change | acceptance matrix, test levels, smoke path |
behavior-baseline | refactor where external behavior should stay stable | characterization checks, smoke paths, regression guard |
architecture | HLD/LLD/ADR/domain/SPEC constraints matter | architecture/domain validation matrix |
system | multi-module, migration, API/data/permission/NFR risk | full validation plan and regression scope |
release | release-bound, compliance, launch, rollback, or operations risk | release validation notes and evidence gate |
Do not force system-level validation on every change.
Answer the questions that apply:
Create rows from requirements, issues, SPEC items, or task cards.
| ID | Source | Expected outcome | Validation method | Evidence required | Owner | Status |
|---|---|---|---|---|---|---|
Recommended ID prefixes:
VAL-AC-001
VAL-NFR-001
VAL-SMOKE-001
VAL-REG-001
VAL-ARCH-001
Status values:
planned
ready
blocked
passed
failed
not-run
accepted-gap
Do not mark passed without execution evidence.
For each material NFR, define:
| NFR | Target or threshold | Method | Tool or evidence | Required before |
|---|
Examples:
If an NFR cannot be measured now, record the accepted gap and owner.
When HLD, LLD, ADR, Domain Boundary Map, modular-monolith rules, or Directory SPEC exist, include:
| Constraint | Source | What must hold | Validation method | Evidence |
|---|
Check for:
This prevents dev from proving only behavior while breaking structure or ownership.
List:
Manual smoke paths:
Automated checks:
Regression areas:
Out-of-scope checks:
Release evidence:
Tie each check to a source requirement, issue, SPEC, task, or accepted risk.
For the 重构 lane, define how unchanged external behavior will be proven before dev changes structure:
Behavior to preserve:
Representative paths:
Existing tests or smoke commands:
Characterization checks to add or run:
Known accepted gaps:
Stop condition:
Do not ask for BRD/PRD just because the work is large. For pure refactor, the product target is usually unchanged behavior plus safer structure.
Specify what dev should report:
Evidence expectations should be precise enough for review, but not so heavy that small changes become process-bound.
When formal SDLC materials are absent but the task is clear, produce a small validation seed:
# Validation Seed: <Change Name>
| Source | Expected behavior | Smallest relevant check | Evidence expected | Risk |
|---|---|---|---|---|
State why direct-dev may continue:
Proceed path: direct-dev
Reason: clear issue / reproduction / target behavior / validation command
Risk:
Required safeguard:
Return or write one of these artifacts.
# Behavior Baseline: <Change Name>
## 1. Preserved Behavior
## 2. Representative Paths
## 3. Existing Checks
## 4. Characterization Checks
## 5. Regression Scope
## 6. Accepted Gaps
## 7. Stop Conditions
# Validation Plan: <Change Name>
## 1. Scope
## 2. Source Artifacts
## 3. Validation Depth
## 4. Acceptance Test Matrix
## 5. NFR Validation Matrix
## 6. Architecture and Domain Validation
## 7. Smoke Checklist
## 8. Regression Scope
## 9. Evidence Expectations
## 10. Gaps and Risks
## 11. Handoff Notes
# Acceptance Test Matrix: <Change Name>
| ID | Source | Expected outcome | Validation method | Evidence required | Owner | Status |
|---|---|---|---|---|---|---|
# Validation Seed: <Change Name>
| Source | Expected behavior | Smallest relevant check | Evidence expected | Risk |
|---|---|---|---|---|
Before returning the plan, check:
dev-test-strategy.dev_test_runner.dev-release-check.Route downstream:
| Need | Next step |
|---|---|
| dev execution | sdlc-dev-handoff-planning or dev-spec-driven-implementation |
| repo-specific test strategy | dev-test-strategy |
| test execution or failure diagnosis | dev_test_runner |
| traceability update | sdlc-requirements-traceability |
| readiness decision | sdlc-readiness-review |
| release validation execution | dev-release-check |
| missing SRS/NFR/SPEC/HLD/LLD/ADR/domain source | relevant sdlc-manager authoring skill |
npx claudepluginhub blueskyxn/codex-is-all-you-need --plugin codex-nextValidates implementation against spec using 6 gates (coverage, proof artifacts, credential safety) and generates a coverage matrix report.
Transforms ambiguous or high-impact product/engineering changes into scoped, verifiable acceptance criteria before or alongside implementation. Use to de-risk features, migrations, security changes, or agent handoffs.
Guides formal validation across unit, integration, e2e, manual/automated regression testing layers with evidence recording and vetoing. For stable branches, high-risk changes, release readiness QA.