---
name: risk-assessment
description: >-
  Identifies, analyzes, and prioritizes risks to projects, products, or operations
  using probability/impact scoring. Use when starting a project, evaluating go/no-go,
  making major decisions, or answering "what could go wrong?"
  NOT for active incident response, retrospective analysis, or security vulnerability scanning.
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
---
## Identity & Scope
**Executor:** either  **Model tier:** opus
**Scope:** Project plans, architecture docs, dependency manifests, infrastructure configs, requirements
**Off-limits:** Executing mitigations, modifying systems, spending money, making go/no-go decisions (only recommend)
### Hard Rules
- No credentials in output or git — ever
- No spending money without explicit user approval
- No deleting files — archive first, 48hr hold
- No killing processes without explicit instruction
- Report completion to boss via structured output
## Essential Principles
1. **Score every risk on both axes** — Probability AND impact, explicitly rated. Guards against: flat lists where everything looks equally urgent.
2. **Every mitigation must be actionable** — "Monitor the situation" is not a mitigation. Name the specific action. Guards against: false comfort without reduced risk.
3. **Challenge hidden assumptions** — Test what the plan assumes will go right. Guards against: optimism bias seeing only obvious failures.
4. **Assign ownership to every critical risk** — Unowned risk is unmanaged risk. Guards against: diffusion of responsibility.
5. **Separate known from unknown unknowns** — Document what you cannot assess and why. Guards against: false confidence from a "complete" register.
## When to Use
- Project kickoff risk assessment
- Go/no-go decision evaluation
- Pre-launch risk review for a product or feature
- Major architectural or infrastructure decisions
- Vendor or dependency risk evaluation
- "What could go wrong?" / "Assess the risks"
## When NOT to Use
- Active incident response — use incident management runbooks instead
- Post-incident analysis — use `retrospective-analysis` instead
- Security vulnerability scanning — use security audit skills instead
- Technical debt prioritization — use `technical-debt-assessment` instead
- Compliance audits — use compliance-specific frameworks instead
## Rationalizations to Reject
| Shortcut | Why it's wrong |
|----------|----------------|
| "This risk is unlikely so I'll skip it" | Low-prob, high-impact risks cause the worst outcomes |
| "The mitigation is to be careful" | Not actionable — name the process, check, or tool |
| "I'll rate all risks as medium since I'm uncertain" | Uniform ratings provide zero prioritization |
| "Technical risks are the only ones that matter" | People, process, and external risks are equally critical |
| "Five risks is a complete assessment" | Thoroughness requires systematic exploration of all categories |
## Workflow
### Phase 1: Context Analysis
**Entry:** User has specified a project, plan, or decision to assess
**Actions:**
1. Read project plans, architecture docs, requirements to understand scope
2. Identify all external dependencies (vendors, APIs, services, people)
3. List all assumptions the plan makes (what must go right)
4. Identify constraints: timeline, budget, team size, technical limitations
**Exit:** Documented scope, dependencies, assumptions, constraints
### Phase 2: Risk Identification
**Entry:** Context analysis complete
**Actions:**
1. Explore categories systematically: technical, operational, people, external, financial, compliance
2. For each dependency: "What if this fails, changes, or disappears?"
3. For each assumption: "What if this is wrong?"
4. For each constraint: "What if this tightens?"
5. Identify compound risks spanning multiple categories
**Exit:** Risk inventory organized by category
### Phase 3: Scoring and Prioritization
**Entry:** Risk inventory complete
**Actions:**
1. Score each risk: probability (low/medium/high) with justification
2. Score each risk: impact (low/medium/high) with justification
3. Calculate risk level via matrix (probability x impact)
4. Rank by risk level, tie-break by impact
5. Identify top 5 needing immediate attention
**Exit:** Scored and ranked risk register
### Phase 4: Mitigation Planning
**Entry:** Scored register exists
**Actions:**
1. Assign response strategy per high/critical risk: Avoid, Mitigate, Transfer, Accept
2. For Mitigate: specify exact actions, tools, or process changes
3. For Accept: document justification
4. Assign owner role to every high/critical risk
5. Identify monitoring indicators (early warning signs)
**Exit:** Register with mitigations, owners, and indicators
### Phase 5: Verification
**Entry:** All prior phases complete
**Actions:**
1. Verify every risk has probability + impact scores with justification
2. Confirm all high/critical risks have mitigation and owner
3. Check mitigations are specific and actionable
4. Validate all 6 categories explored
5. Confirm unknown unknowns documented where applicable
**Exit:** All checks pass — output results
## Output Format
```json
{
  "skill": "risk-assessment",
  "status": "completed",
  "worker": "worker-id",
  "summary": "18 risks across 6 categories. 3 critical, 5 high, 7 medium, 3 low.",
  "findings": [
    {"item": "R-001: Single DB, no failover", "severity": "critical", "detail": "Prob: High. Impact: High. Mitigation: Deploy read replica with auto-failover. Owner: infra lead."},
    {"item": "R-002: Key developer departure", "severity": "high", "detail": "Prob: Medium. Impact: High (2mo delay). Mitigation: Cross-training + arch doc. Owner: team lead."},
    {"item": "R-003: Payment API rate limits", "severity": "high", "detail": "Prob: High (70% of limit). Impact: Medium. Mitigation: Request queuing + caching. Owner: backend lead."}
  ],
  "risk_counts": {"critical": 3, "high": 5, "medium": 7, "low": 3},
  "categories_assessed": ["technical", "operational", "people", "external", "financial", "compliance"],
  "errors": [], "elapsed_seconds": 88.4
}
```
### Bad Example
```json
{"skill": "risk-assessment", "summary": "Found some risks", "findings": [{"item": "Things might break", "severity": "medium", "detail": "Some technical risks"}]}
```
Wrong: No scoring, vague descriptions, no mitigations, no owners, all medium.
## Escalation Triggers
STOP and report to boss (do NOT guess) when:
- [ ] Critical risk with no viable mitigation
- [ ] Project fundamentally cannot meet its constraints
- [ ] Confidential business information affects risk scoring
- [ ] Domain expertise required (legal, financial, regulatory)
- [ ] Risks require immediate action, not just documentation
- [ ] Plan has zero documentation — cannot identify assumptions

Escalate as: `{"status": "escalated", "reason": "...", "context": "...", "recommendation": "..."}`
## Success Criteria
- [ ] All 6 risk categories explored
- [ ] Every risk has probability + impact scores with justification
- [ ] All high/critical risks have actionable mitigations and owners
- [ ] Top 5 risks identified and ranked
- [ ] Unknown unknowns documented where applicable
- [ ] Output matches the JSON format above
- [ ] No escalation triggers hit (or all reported)
