| name | risk-register |
| description | Maintain a centralized living risk register across projects. Use this skill when:
- You need to create or update a risk register for a project or feature
- You want to consolidate risks from individual specs into one register
- You need to review and update risk status, mitigations, and owners
- You want a cross-project risk view
|
Risk Register
Centralized risk register that consolidates risks from individual spec sections into one living document.
Workflow
- Determine scope — Single spec, single project, or cross-project
- Read Risks and Assumptions from relevant specs
- If existing register exists, read and merge (don't duplicate — match by description)
- Assess each risk using the likelihood x impact matrix
- Output register
Risk Assessment Matrix
Likelihood: Low (unlikely) | Medium (possible) | High (probable)
Impact: Low (minor inconvenience) | Medium (feature degradation) | High (critical failure/data loss)
| Low Impact | Medium Impact | High Impact |
|---|
| High Likelihood | Medium | High | Critical |
| Medium Likelihood | Low | Medium | High |
| Low Likelihood | Low | Low | Medium |
Output Format
# Risk Register — {Scope}
**Last Updated:** {DD-MM-YYYY}
**Total Risks:** {n} | Open: {n} | Mitigated: {n} | Closed: {n}
## Risk Summary
| ID | Risk | Source | Likelihood | Impact | Priority | Owner | Mitigation | Status | Last Reviewed |
|----|------|--------|-----------|--------|----------|-------|-----------|--------|--------------|
| R-001 | {desc} | {spec/feature} | H/M/L | H/M/L | Critical/High/Med/Low | {name/role} | {plan} | Open/Mitigated/Closed | {date} |
## Critical Risks
{Filtered view of Critical priority — requires immediate attention}
## Risk Trends
- New risks this period: {n}
- Risks closed this period: {n}
- Overdue reviews: {risks not reviewed in 30+ days}
Rules
- Every risk MUST have an owner (name or role, not "TBD")
- Every risk MUST have a mitigation plan (not empty)
- Review date updates when risk is revisited
- Risk IDs are sequential (R-001, R-002) and never reused
- When merging with existing register, preserve existing IDs
- Separate risks from assumptions — only risks go in the register
Anti-Patterns
- Don't create a risk without a mitigation plan — "TBD" is not acceptable
- Don't reuse risk IDs — closed risks keep their IDs
- Don't mix risks and assumptions — they're different things
Quality Checklist
