From codex-next
Creates, updates, or inspects requirements traceability matrices linking requirements, design, tasks, tests, PRs, commits, releases, and evidence gaps across SDLC artifacts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/codex-next:sdlc-requirements-traceabilityThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this workflow to create, update, or inspect a requirements traceability matrix.
Use this workflow to create, update, or inspect a requirements traceability matrix.
Traceability connects intent to execution:
Business / User / Product / Software Requirement
-> HLD / LLD / ADR / Domain Boundary / SPEC / Validation Plan / Handoff / Task
-> Test / Review / PR / Release
Traceability is strongest when SDLC materials exist. When no SDLC materials exist, traceability can still start from an issue, bug report, task ID, test failure, or direct-dev handoff. Do not block small development work solely because a full RTM is absent; create a traceability seed and mark the evidence level.
For lightweight SDLC-ADS work, use the operating-model contract as the default:
REQ -> TASK -> VAL
ARCH / DOM / DEC -> TASK
ITEM -> TASK / VAL / Q
Do not require BRD/URS/PRD/SRS prefixes before a clear direct-dev, handoff-lite, or refactor task can proceed.
sdlc-readiness-review or dev-release-check as appropriate.Use what exists. Do not require all artifact families.
When SDLC artifacts are absent, trace from:
Use the depth that matches the lane and risk.
| Depth | Use when | Matrix shape |
|---|---|---|
seed | direct-dev, issue-backed, bugfix, early draft | Source -> TASK -> VAL |
standard | contained feature delivery | REQ -> TASK -> VAL -> Test |
architecture | architecture/domain-sensitive delivery | REQ + ARCH/DOM/DEC -> TASK -> VAL -> Test |
extended | system, rebuild, multi-wave, or release-bound delivery | REQ + ARCH/DOM/DEC -> TASK -> VAL -> Test -> PR -> Release |
audit | baseline, compliance, high-risk, or release-bound evidence | Same chain plus owner, status, evidence, change record |
Do not force extended or audit depth on every change.
Collect stable IDs from available artifacts.
Use these prefixes:
| Prefix | Meaning |
|---|---|
REQ | Requirement from requirements package or scope decision table |
DEC | Durable decision |
ARCH | Architecture constraint |
DOM | Domain, ownership, data, or dependency constraint |
TASK | Dev task |
VAL | Validation item |
Q | Open question or blocker |
ITEM | Midstream intake item |
If an input has no ID, create a lightweight local ID and mark it as generated. Use only the prefixes above.
Each row should represent one traceable item or one traceable chain.
Base columns:
| Trace ID | Source | Requirement | Type | Priority | Downstream | Task | Validation | Status |
|---|---|---|---|---|---|---|---|---|
Extended columns:
| Trace ID | Source | REQ | ARCH/DOM/DEC | TASK | VAL | Test | PR/Commit | Release | Owner | Status | Evidence | Change |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Use compact rows. A traceability matrix should help dev and review, not become an unreadable archive.
Map source materials to REQ, TASK, and VAL.
Examples:
REQ-001 -> TASK-001 -> VAL-001
ARCH-001 -> TASK-002
DOM-001 -> TASK-003
Issue-123 -> TASK-001
Bug-456 -> TEST-REG-001
Rules:
For each REQ or task item, identify needed architecture/domain and specification evidence:
| Requirement | Needed architecture/domain constraint | Needed specification detail | Status |
|---|---|---|---|
REQ-001 | ARCH-001, DOM-001, DEC-001 | 20-规格.md API section | present / missing / not applicable |
If no specification detail is required, state why. If no HLD, LLD, ADR, or Domain Boundary Map is required, state why when the work is architecture-sensitive.
Each implementation task should have a validation path. When a Validation Plan or acceptance matrix exists, link tasks to the relevant validation IDs before linking to executed test evidence.
| Task | Validation Plan item | Test or check | Type | Status |
|---|---|---|---|---|
TASK-001 | VAL-001 | pytest path/test_name | unit / integration / e2e / manual / smoke / NFR | planned / passed / failed / not run |
Do not mark validation as passed unless evidence exists.
When dev has started or finished, add:
If execution evidence is not yet available, leave it blank or mark pending.
Report gaps by type:
| Gap | Meaning |
|---|---|
| orphan source | requirement has no downstream SRS/task |
| orphan task | task has no source or issue link |
| missing validation | task or requirement has no test/validation |
| missing validation plan | feature, system, release, NFR, architecture, or domain-sensitive work lacks explicit proof-of-correctness plan |
| missing SPEC | requirement needs UI/API/Data/etc. spec but none exists |
| missing architecture artifact | requirement needs HLD, LLD, ADR, Domain Boundary Map, or Directory SPEC but none exists |
| boundary conflict | task or SPEC appears to violate ownership, dependency, or forbidden access rules |
| stale link | target artifact is superseded |
| unapproved change | task implements changed scope without change record |
| direct-dev risk | implementation proceeds from issue/task without formal SDLC materials |
Not every gap blocks dev. Classify severity:
blocker
important
watch
accepted
For a direct-dev task, produce a seed matrix:
| Trace ID | Source | Task | Validation | Risk | Status |
|---|---|---|---|---|---|
| TRACE-001 | Issue-123 | TASK-001 | pytest path/test_name | low | planned |
This preserves evidence without pretending a full SDLC chain exists.
Return or write one of these outputs.
# Traceability Seed: <Change Name>
| Trace ID | Source | Task | Validation | Risk | Status |
|---|---|---|---|---|---|
# Requirements Traceability Matrix: <Feature / System>
## 1. Scope
## 2. Artifact Sources
## 3. Traceability Matrix
## 4. Gap Report
## 5. Execution Evidence
## 6. Change Notes
# Traceability Gap Report
## Blocking gaps
## Important gaps
## Accepted gaps
## Recommended next action
Before declaring traceability ready, check:
sdlc-change-control records when baseline is affected.sdlc-dev-handoff-planning.Route findings:
| Finding | Next step |
|---|---|
| source not ready | sdlc-requirements-workflow, sdlc-prd-workflow, or sdlc-srs-workflow |
| HLD missing | sdlc-hld-workflow |
| LLD missing | sdlc-lld-workflow |
| ADR missing | sdlc-architecture-decision-record |
| domain boundary missing | sdlc-domain-boundary-modeling |
| SPEC missing | sdlc-spec-slice-writer |
| validation plan missing | sdlc-validation-plan-workflow |
| handoff missing | sdlc-dev-handoff-planning |
| baseline changed | sdlc-change-control |
| readiness uncertain | sdlc-readiness-review |
| implementation ready | dev skill such as dev-spec-driven-implementation, dev-bugfix, or dev-test-strategy |
| direct-dev safe but untracked | create traceability seed and proceed to dev |
npx claudepluginhub blueskyxn/codex-is-all-you-need --plugin codex-nextDrives planning, implementation, and validation from approved requirements with traceability matrices, execution plans, and HITL gates for ambiguities, conflicts, or tradeoffs.
Verifies bidirectional traceability from requirements to code to tests. Scans .aiwg/requirements/, code files, tests, and commit messages for ID references like UC-*, REQ-*. Builds matrix, identifies coverage gaps, orphans, and untested code.
Guides requirements lifecycle per CMMI RD/REQM: elicitation, analysis, prioritization, specification, bidirectional traceability, change control, and RTM. Use for scope creep, audits, volatility.