identify-risks

Files (1)

• SKILL.md

SKILL.md (first lines)

# Identifying Project Risks

Scan plans for risks backed by concrete evidence — not speculation.

## HARD-GATE
- Every risk must cite specific evidence (task, requirement).
- Do not flag everything high-risk; use likelihood/impact matrix honestly.
- Provide at least one concrete mitigation per risk.

## Core Process
1. Receive plan (tasks, tickets, PRD, sprint).
2. Scan for six patterns: dependency chains, single points of failure, ambiguous requirements, external dependencies, capacity/resource issues, technical uncertainty.
3. Classify each risk: Likelihood (High/Medium/Low), Impact (High/Medium/Low), Proximity (Immediate/Near-term/Future).
4. Suggest mitigation (prevention, contingency, owner).
5. Validate: remove risks lacking direct evidence.
6. Output risk register.

## Risk Patterns (six patterns)
1. Dependency Chain (task B blocked by task A not done)
2. Single Point of Failure (only one owner for critical item)
3. Ambiguous Requirement (TBD, vague acceptance criteria)
4. External Dependency (third-party API, vendor, regulatory)
5. Capacity/Resource (team member over-allocated, holiday overlap)
6. Technical Uncertainty (new tech, unproven integration, no spike)

## Output
- Risk Register: ID | Risk | Likelihood | Impact | Proximity | Evidence | Mitigation | Owner
- Summary counts by severity and proximity.
- Top 3 risks with detailed mitigations (including owner).

## Integration
- **estimate-tasks** — high-uncertainty tasks
- `plan-tickets` — dependency risks after draft work-item breakdown
- **generate-status-report** — include risk updates in stakeholder reports

From igmarin/agnostic-planning-skills, MIT.

More from igmarin/agnostic-planning-skills