risk-register

What this skill does

# Risk Register Skill

When creating or updating a risk register, follow this structured process. The goal is to maintain a living document that surfaces project risks early enough to act on them — before they become incidents, missed deadlines, or scope explosions.

**IMPORTANT**: Always save the output as a markdown file in the `project-decisions/` directory at the project root. Create the directory if it doesn't exist.

**PRINCIPLE**: A good risk register is not a one-time document. It should be reviewed and updated every sprint. Risks change — new ones appear, old ones are mitigated, some become reality.

## 0. Output Setup
```bash
mkdir -p project-decisions

# File naming:
# First time:  project-decisions/YYYY-MM-DD-risk-register.md
# Updates:     Edit the existing file, add to the changelog at the bottom
# If no existing register exists, create a new one
# If one exists, update it

ls project-decisions/*risk-register* 2>/dev/null
```

## 1. Risk Discovery

### 1a. Codebase & Technical Risks
```bash
# Complexity hotspots (high complexity = high risk of bugs)
find . -type f \( -name "*.ts" -o -name "*.js" -o -name "*.py" \) ! -path '*/node_modules/*' ! -path '*/dist/*' -exec wc -l {} + 2>/dev/null | sort -rn | head -15

# Files with highest churn (most changes = most fragile)
git log --name-only --since="3 months ago" --format="" -- src/ app/ 2>/dev/null | sort | uniq -c | sort -rn | head -15

# Files with most bug fixes (where problems live)
git log --name-only --since="6 months ago" --grep="fix\|bug\|hotfix" --format="" -- src/ app/ 2>/dev/null | sort | uniq -c | sort -rn | head -10

# Dependency vulnerabilities
npm audit --json 2>/dev/null | head -50
pip audit 2>/dev/null | head -20

# Outdated dependencies
npm outdated 2>/dev/null | head -20
pip list --outdated 2>/dev/null | head -20

# TODO/FIXME/HACK count (unaddressed known issues)
echo "TODO: $(grep -rn 'TODO' --include='*.ts' --include='*.js' --include='*.py' src/ app/ 2>/dev/null | grep -v 'node_modules' | wc -l)"
echo "FIXME: $(grep -rn 'FIXME' --include='*.ts' --include='*.js' --include='*.py' src/ app/ 2>/dev/null | grep -v 'node_modules' | wc -l)"
echo "HACK: $(grep -rn 'HACK' --include='*.ts' --include='*.js' --include='*.py' src/ app/ 2>/dev/null | grep -v 'node_modules' | wc -l)"

# Test coverage gaps (untested code = risk)
find src/ app/ -type f \( -name "*.ts" -o -name "*.js" -o -name "*.py" \) ! -name "*.test.*" ! -name "*.spec.*" ! -name "test_*" ! -name "*.d.ts" ! -name "index.*" ! -path '*/node_modules/*' ! -path '*/dist/*' 2>/dev/null | while read f; do
  base=$(basename "$f" | sed 's/\.\(ts\|tsx\|js\|jsx\|py\)$//')
  if ! find . \( -name "${base}.test.*" -o -name "${base}.spec.*" -o -name "test_${base}.*" \) ! -path '*/node_modules/*' 2>/dev/null | grep -q .; then
    echo "UNTESTED: $f"
  fi
done | head -20

# Single points of failure (bus factor)
for f in $(git log --name-only --since="12 months ago" --format="" -- src/ 2>/dev/null | sort -u | head -30); do
  authors=$(git log --format='%aN' --since="12 months ago" -- "$f" 2>/dev/null | sort -u | wc -l)
  if [ "$authors" -eq 1 ]; then
    echo "BUS FACTOR 1: $f ($(git log --format='%aN' -1 -- "$f" 2>/dev/null))"
  fi
done | head -15

# Missing error handling in critical paths
grep -rn "catch\|except\|rescue" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | wc -l
grep -rn "async function\|async def\|async (" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | wc -l

# Infrastructure configuration
cat docker-compose.yml Dockerfile 2>/dev/null | head -40
cat .github/workflows/*.yml 2>/dev/null | head -40

# Check for health checks and monitoring
grep -rn "health\|readiness\|liveness\|monitor\|sentry\|datadog\|prometheus" --include="*.ts" --include="*.js" --include="*.py" --include="*.yaml" --include="*.yml" . 2>/dev/null | grep -v "node_modules" | head -10

# Check for secrets management
grep -rn "process\.env\|os\.environ\|os\.Getenv" --include="*.ts" --include="*.js" --include="*.py" --include="*.go" src/ app/ 2>/dev/null | grep -v "node_modules\|test\|spec" | wc -l
ls .env .env.local .env.production 2>/dev/null
```

### 1b. Project & Delivery Risks

Evaluate from context, PRDs, recent activity:
```bash
# Recent velocity (commits per week)
for week in 4 3 2 1 0; do
  start=$(date -d "$((week+1)) weeks ago" +%Y-%m-%d 2>/dev/null || date -v-$((week+1))w +%Y-%m-%d 2>/dev/null)
  end=$(date -d "$week weeks ago" +%Y-%m-%d 2>/dev/null || date -v-${week}w +%Y-%m-%d 2>/dev/null)
  count=$(git log --oneline --after="$start" --before="$end" 2>/dev/null | wc -l)
  echo "Week -$week: $count commits"
done

# PR cycle time (how long PRs stay open)
gh pr list --state merged --limit 10 --json number,title,createdAt,mergedAt 2>/dev/null | head -40

# Open PRs (work in progress)
gh pr list --state open --json number,title,createdAt,author 2>/dev/null | head -20

# Pending issues
gh issue list --state open --limit 20 --json number,title,labels,createdAt 2>/dev/null | head -40

# Recent incidents
ls project-decisions/*incident* 2>/dev/null

# Recent scope changes or decision records
ls project-decisions/ 2>/dev/null | tail -10

# Check for deadline references
grep -rn "deadline\|due date\|launch\|go-live\|ship by\|target date" --include="*.md" . 2>/dev/null | grep -v "node_modules\|\.git" | head -10
```

## 2. Risk Categories

### Technical Risks

| ID | Risk Category | What to Look For |
|----|--------------|-----------------|
| T1 | **Architecture** | Single points of failure, monolith pain points, scaling bottlenecks, circular dependencies |
| T2 | **Code Quality** | High complexity files, low test coverage, excessive tech debt, code smells |
| T3 | **Dependencies** | Vulnerable packages, outdated major versions, unmaintained libraries, license issues |
| T4 | **Security** | Exposed secrets, injection vulnerabilities, auth gaps, data exposure |
| T5 | **Performance** | Slow queries, memory leaks, missing caching, N+1 problems |
| T6 | **Data** | Missing backups, no migration rollback, data integrity gaps, missing validation |
| T7 | **Infrastructure** | No redundancy, manual deployments, missing monitoring, no auto-scaling |
| T8 | **Integration** | Flaky third-party APIs, missing circuit breakers, undocumented API contracts |

### Delivery Risks

| ID | Risk Category | What to Look For |
|----|--------------|-----------------|
| D1 | **Timeline** | Unrealistic deadlines, scope creep, incomplete requirements, blocked tasks |
| D2 | **Resources** | Team capacity constraints, key person dependency, skill gaps, competing priorities |
| D3 | **Scope** | Vague requirements, missing acceptance criteria, unbounded features, no MVP definition |
| D4 | **Dependencies** | Cross-team blockers, external vendor timelines, design deliverables, stakeholder approvals |
| D5 | **Communication** | Unclear ownership, missing documentation, no stakeholder alignment, siloed knowledge |

### Operational Risks

| ID | Risk Category | What to Look For |
|----|--------------|-----------------|
| O1 | **Availability** | No SLA defined, missing health checks, no incident response plan, no runbooks |
| O2 | **Disaster Recovery** | No backup strategy, untested recovery, missing failover, no RTO/RPO targets |
| O3 | **Compliance** | GDPR gaps, missing audit logging, data retention policy unclear, security certifications pending |
| O4 | **Support** | No on-call rotation, missing runbooks, no escalation path, knowledge silos |

### Business Risks

| ID | Risk Category | What to Look For |
|----|--------------|-----------------|
| B1 | **Market** | Competitive pressure, changing requirements, pivoting product direction |
| B2 | **Vendor** | Vendor lock-in, pricing changes, vendor stability, contract expiry |
| B3 | **Revenue** | Payment system reliability, billing accuracy, churn risk from outages |
| B4 | **Reputation** | Data breach risk, public-facing outage risk, user trust |

## 3. Risk Scoring

### Likelihood Scale

| Sco