Requirement traceability
Connects accepted game rules to the code and checks that implement them. Shows which requirements are covered, which remain unverified and which changes lack an agreed purpose.
requirement-to-code-traceability
Agents 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
Trace the requirement that a checkpoint restores health but never respawns collected quest items. Map each clause to the respawn handler, save data and relevant tests. Include death during collection and loading an older save, then identify missing evidence without silently adding a new reset rule.
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