Traceability Manager

Traceability Manager

When to Use

Use this skill when the user needs to:

• Establish or audit traceability between requirements and implementation artifacts.
• Detect orphans: requirements without coverage, tasks without parents, APIs without source requirements.
• Perform change impact analysis before modifying scoped requirements or artifacts.
• Build or validate a Requirements Traceability Matrix (RTM).
• Govern a traceability model: define typed links, coverage rules, and governance policies.
• Generate a traceability plan or model in Markdown format.

Do NOT use this skill for static spreadsheet management, project management tooling configuration, or business context documentation. It produces executable traceability artifacts and is designed for both human review and agent-driven workflows.

Core Concepts

Bidirectional Traceability

Traceability flows in two directions:

• Forward traceability: source requirement → design → code → tests → validation
• Backward traceability: artifact → source requirement (confirms every implemented item is justified)

Bidirectional traceability enables both coverage analysis (all requirements are implemented) and impact analysis (a change to any artifact can be traced back to its origin).

Typed Link Vocabulary

Use this controlled set of link types:

Coverage Model

Every requirement must have at least one forward path to a validation artifact. The coverage model distinguishes:

Orphan Detection

Orphan types this skill detects:

Operating Workflow

Phase 1: Discover Artifacts

1. Identify the artifacts in scope: PRDs, PRPs, specs, stories, tasks, APIs, architectures, validation artifacts.
2. Use glob and grep across the project to find relevant files with known extensions (*.md, *.spec.md, *.prd, *.prp, *.api.md).
3. Build a preliminary inventory: artifact ID, type, file path, title or summary.

Phase 2: Map Relationships

1. For each artifact, inspect content to identify explicit and implicit relationships.
2. Apply the typed link vocabulary to record each relationship.
3. Flag artifacts that lack explicit links as candidates for orphan detection.
4. Identify governed-by relationships by checking for embedded policy references.

Phase 3: Coverage Analysis

1. For each requirement or spec, check for a forward chain to tasks and validation.
2. Classify each requirement into fully-covered, partially-covered, or uncovered.
3. For each validation artifact, verify it has a backward link to a traced requirement.
4. Record uncovered requirements and orphan artifacts.

Phase 4: Impact Analysis

1. When a requirement or artifact changes, trace its forward and backward links.
2. Identify all artifacts affected in both directions.
3. For each affected artifact, assess the scope of the change.
4. Present the impact set ranked by proximity from the changed artifact.

Phase 5: Produce Traceability Model

Generate the traceability model as a Markdown document using the required output structure.

Decision Rules

Traceability Model Output Structure

# Traceability Model

## 1. Overview
- Total artifacts:
- Requirements:
- Tasks:
- APIs:
- Validation artifacts:
- Policies:

## 2. Artifact Inventory
| ID | Type | Title | File | Links Out | Links In | Coverage |
| --- | --- | --- | --- | --- | --- | --- |

## 3. Relationship Graph
| From | Link Type | To | Rationale |
| --- | --- | --- | --- |

## 4. Typed Link Definitions
| Link Type | From | To | Cardinality | Coverage Rule |
| --- | --- | --- | --- | --- |

## 5. Coverage Report
### Fully Covered
| Requirement | Forward Path | Validation |
| --- | --- | --- |

### Partially Covered
| Requirement | Missing Link | Recommendation |
| --- | --- | --- |

### Uncovered (Orphans)
| Requirement | Gap | Recommended Action |
| --- | --- | --- |

## 6. Orphan Report
| Orphan Type | ID | Title | File | Recommended Action |
| --- | --- | --- | --- | --- |

## 7. Change Impact Analysis (when triggered)
### Changed Artifact
- ID:
- Type:
- File:

### Forward Impact (downstream)
| Artifact | Distance | Change Scope |
| --- | --- | --- |

### Backward Impact (upstream justification)
| Artifact | Distance | Rationale |
| --- | --- | --- |

## 8. Governance
- Link integrity rules:
- Minimum coverage standard:
- Policy compliance requirements:

## 9. Recommendations
- Immediate:
- Short-term:
- Long-term:

Traceability Plan Output Structure

When the user requests a traceability plan (vs. a snapshot model), use this structure:

# Traceability Plan

## 1. Objectives
- What the traceability model must enable

## 2. Scope
- Artifacts included
- Artifacts excluded
- Boundaries

## 3. Typed Link Architecture
- Defined link types
- Directionality rules
- Cardinality constraints

## 4. Coverage Expectations
- Minimum coverage level per artifact type
- Coverage gap threshold for blocking

## 5. Governance Rules
- Who approves link additions
- Orphan resolution SLAs
- Change impact review triggers

## 6. Workflow Integration
- When to update traceability links
- Who is responsible for each artifact type
- Review cadence

## 7. Reporting
- Coverage reports: frequency and audience
- Orphan reports: frequency and owner
- Impact analysis triggers and audience

## 8. Maintenance
- Link hygiene rules
- Orphan detection schedule
- Coverage recalculation triggers

Quality Checklist

Before presenting the traceability model or plan, verify:

• The output is written in English.
• All artifacts found in scope are listed in the inventory.
• Every relationship uses a defined typed link from the vocabulary.
• Uncovered requirements are listed separately with recommended actions.
• Orphan artifacts are classified by orphan type with recommended actions.
• Change impact analysis covers both forward and backward directions.
• No project-specific names, client names, or unnecessary vendor references were invented.
• The model specifies coverage expectations and governance rules.
• All unknowns are marked as TBD rather than invented.

Files to Read

• references/link-vocabulary.md — full typed link definitions with usage examples (load only when the skill body instructs it)