Requirement traceability
Links accepted requirements, implementation paths and verification evidence so missing rules and unrequested changes become visible.
requirement-to-code-traceability
Team members using this skill
When is it useful?
Use it when reviewing a delivery against a brief or checking whether each promise has working code and a meaningful test.
What does it help you do?
- Maps each accepted criterion to implementing code and tests.
- Traces changed code back to a justified requirement.
- Checks success, failure and boundary evidence without inventing scope.
Try asking this
Show which invitation requirements are implemented, tested or still missing. Create a compact matrix linking invitation expiry, revocation and acceptance to code and executed checks. Mark missing evidence instead of counting an existing test name as proof.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Requirement-to-Code Traceability
Use this skill to verify that the implemented code actually fulfills the accepted specification — neither dropping required business rules nor introducing unrequested behavior changes.
The Three-Way Traceability Matrix
For every work item, map each requirement across three columns: $$\text{Requirement / Acceptance Criterion} \longrightarrow \text{Implementing Code Path(s)} \longrightarrow \text{Verifying Test(s)}$$
Workflow
- Map every acceptance criterion to its exact implementation:
- Walk through the brief and specification item by item:
- Fully implemented: Identify the exact functions, handlers, UI states, and database queries enforcing the rule.
- Partially implemented: E.g., enforced in the UI button state, but missing from the backend API endpoint or background worker.
- Missing / Stubbed: Left unimplemented, hardcoded, or behind an unreachable branch.
- Walk through the brief and specification item by item:
- Trace reverse from the diff back to requirements:
- For every non-trivial behavioral change in the diff, ask: "Which accepted requirement or bugfix requires this change?"
- Flag unrequested behavioral changes (silent changes to existing defaults, altered API response shapes, modified sorting/filtering semantics, or weakened validation) that were not authorized by the specification.
- Verify happy, error, and boundary paths in code:
- Confirm the code handles not only the nominal path, but also the specified rejection paths, permission denials, empty states, and boundary values.
- Link each requirement to its verification evidence:
- Check whether each acceptance criterion has a corresponding test assertion that exercises the real code path and would fail if that requirement were broken.
- Explicitly list any acceptance criterion that is implemented in code but currently lacks automated test coverage.
Included files 1
SKILL.md