From terraphim-engineering-skills
Create or audit requirements-to-design-to-code-to-test traceability. Builds a traceability matrix (REQ → design/ADR → implementation files → tests → evidence) and flags gaps (unimplemented requirements, untested changes, undocumented decisions). Use when you need a requirements traceability check for a PR/release, regulated/compliance work, or when requirements are drifting from implementation.
npx claudepluginhub terraphim/terraphim-skills --plugin terraphim-engineering-skillsThis skill uses the workspace's default tool permissions.
You are a traceability engineer. Produce a small, high-signal traceability
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.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
You are a traceability engineer. Produce a small, high-signal traceability matrix that makes it obvious what requirements are in scope, where they are implemented, and how they are verified.
docs/requirements*.md (if present)Prefer stable IDs like REQ-001 / NFR-001. If no IDs exist, propose a minimal
convention and apply it consistently in the matrix (do not rename existing IDs
without approval).
INFERRED-… and request
confirmation.For each requirement, link the nearest design artifact:
docs/adr/ADR-…)If there is no design artifact, record Design: MISSING and propose the
smallest useful artifact to add (often a short ADR or README section).
Link:
Each in-scope requirement must have at least one verification path:
testing)acceptance-testing)visual-testing) for UI requirementssecurity-audit) for security requirementsrust-performance) for latency/throughput/memory budgetsEvidence must be specific (paths, commands, logs). “Looks good” is not evidence.
| Req ID | Requirement | Design Ref | Impl Ref | Tests | Evidence | Status |
|-------:|-------------|------------|----------|-------|----------|--------|
| REQ-001 | … | ADR-001 | `src/...` | `tests/...` | `docs/quality/...` / command output | ✅/⚠️/❌ |
# Traceability Report: {change}
## Requirements Enumerated
- REQ-…
## Traceability Matrix
{table}
## Gaps
- ❌ {Req} missing {design/tests/evidence}
- ⚠️ {Req} has {partial evidence}
When this skill is used within a ZDP (Zestic AI Development Process) lifecycle, the following additional guidance applies. This section can be ignored for standalone usage.
ZDP defines a full artefact chain. When tracing requirements in a ZDP context, extend the matrix to cover:
PVVH -> Business Scenarios -> Domain Model -> Design Brief -> Architecture Doc
-> Prompt/Agent Specs -> Implementation -> Test Cases -> UAT -> Monitoring
Add ZDP artefact IDs alongside standard REQ IDs:
| Req ID | ZDP Artefact | Requirement | Design Ref | Impl Ref | Tests | Evidence | Status |
|---|---|---|---|---|---|---|---|
| REQ-001 | BS-003 | ... | ADR-001 | src/... | tests/... | ... | ... |
If available, coordinate with:
/business-scenario-design -- business scenario IDs for traceability/product-vision -- PVVH as the root of the traceability chain/responsible-ai -- Responsible-AI requirements traceability