Requirement Traceability Analysis

Build a bidirectional, auditable mapping from requirements or controls to acceptance criteria, design, code, tests, defects, and validation evidence. Keep relationship types separate from coverage statuses; never turn names, static presence, or report wording into execution results.

When to Use

• You need to check whether requirements have acceptance, design, implementation, test, and defect coverage.
• You need to find orphan requirements, orphan tests, broken links, stale artifacts, or missing evidence.
• You need an auditable traceability matrix for release, change review, compliance, or risk governance.

Do not use it only to write test cases, execute tests, or decide business priority; this Skill analyzes the mappings and evidence supplied by the user.

Output Format Options

• Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
• Do not present a structured format or static inventory as execution, pass, approval, or release evidence.

How to Use

1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.

Workflow

1. Read and follow prompts/requirement-traceability-analysis.md; audit target, version, scope, time window, and input boundary first.
2. Map requirements, acceptance, design, code, tests, defects, and evidence using stable identifiers, preserving source, version, and applicability.
3. Keep relationship types direct, derived, indirect, contradictory, and missing separate from coverage statuses complete, partial, unverified, stale, unexecuted, and unassessed; never use one group as the other.
4. When the task requests coverage_analysis or test-coverage-analysis, preserve bidirectional RT-## traceability and add a TC-## coverage view with test assets, coverage state, execution identity/time/environment, evidence quality, and orphan signals.
5. Preserve orphan items, broken links, duplicate mappings, missing execution records, and name-only links with a gap, owner, next action, and validation method.
6. Keep conclusions bounded by supplied material; execution, defect closure, and release claims require corresponding evidence.

Core Constraints

• Use RT-## finding IDs; each row includes requirement/control, source, linked artifact, relationship type, coverage status, evidence, and gap action.
• Relationship types: direct, derived, indirect, contradictory, and missing.
• Coverage statuses: complete, partial, unverified, stale, unexecuted, and unassessed.
• In coverage_analysis mode, use TC-## for coverage views while preserving RT-## relationship findings; relationship types and coverage states remain separate.
• Check both directions: trace requirements downstream and trace tests/defects/evidence upstream; mark an item orphaned when no counterpart is found.
• Do not call a file, link, test name, report summary, or code presence executed, passed, fixed, or approved.
• When artifacts, stable IDs, versions, execution records, data, or environment are missing, mark unassessed/unverified/unexecuted and ask for evidence.
• Do not invent requirements, relationships, thresholds, owners, approvals, or runtime results; state the basis and close condition for recommendations.

Reference Files

• Always read prompts/requirement-traceability-analysis.md before producing an analysis.
• Use evals/eval.yaml and evals/cases/ to regress this Skill; configuration and static mappings do not prove real system execution.
• To check discovery behavior, run scripts/run_skill_trace_eval.py with evals/trigger-prompts.csv and evals/local-rules.json; missing skill.selection evidence is BLOCKED, not a trigger pass.
• This is a repository-root development check; a standalone Skill package does not include the repository runner and does not depend on it at runtime.
• To regress test-coverage-analysis, use the coverage-* Evals and a local trigger prompt containing “coverage analysis”; the target remains this physical Skill directory and no alias directory is created.

Best Practices

• Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
• Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.

Pre-delivery Checklist

• Input audit, scope, version, time window, and key assumptions are recorded
• Both requirement-to-artifact and artifact-to-requirement traceability are checked
• Every conclusion has source, evidence, relationship type, coverage status, and validation method
• Relationship types direct, derived, indirect, contradictory, and missing are separate from coverage statuses complete, partial, unverified, stale, unexecuted, and unassessed
• Static presence, report wording, and test names are not presented as execution results

Common Pitfalls

• Claiming coverage because a test filename or ticket link exists.
• Building only a requirement-to-test matrix and missing orphan tests or unlinked defects.
• Treating missing evidence as no issue, or treating a report's “passed” as execution proof.
• Replacing stable IDs with similar titles and linking artifacts across versions or scopes.