Risk Management
Risk management in the system is a living register (risk-register.md) that the agent maintains together with you: it finds candidates, proposes scoring, you confirm, it writes it down. Response measures are a separate step: the agent does not invent mitigations at the identification stage.
Important: a risk is a potential future event. A current problem (issue) does not go into the risk table — it goes into the work.
Step 1. Identification and scoring: /risks
Type /risks. If there is no register yet — the agent creates one; if there is — it runs a review: it checks every open risk against new evidence (the plan, the last report, tracker blockers) and proposes changes to scores or statuses.
Then the agent looks for new candidates. The filter: the risk is controllable and material to the objectives, dates, budget, or scope of this project. Each candidate is shaped as cause → effect on a named outcome:
- category (schedule, technical, resource, commercial, stakeholder, external) — only if there is evidence;
- trigger — a quantitative early-warning threshold (when to escalate / activate the contingency);
- source — where the candidate came from (charter, contract analysis, blockers, the walk, the delta).
Scoring
Likelihood (L) and impact (I) on 1–5; score = L × I:
| Score | Band | Response |
|---|---|---|
| 20–25 | Critical | Immediate escalation |
| 12–19 | High | Active management, weekly review |
| 8–11 | Medium | Planned response, fortnightly review |
| 4–7 | Low | Monitor |
| 1–3 | Negligible | Accept / watch |
The 1–5 scale (not just "high/medium/low") keeps risks ranked inside the same band.
Confirmation and writing
Candidates are presented as a list — with the score, the source, the rationale, and an empty "Controls" cell — and are written into the register only after your confirmation. The owner is a named person (from the charter RACI or your list); "the team" is not an owner.
Register columns: ID, risk (cause → effect), category, L × I = S with the band, owner, status (open / accepted / occurred / closed), trigger, controls (mitigation and contingency in one cell), review date, sources. Plus the scoring legend, the change log, and the next review date.
Step 2. Response measures: /risk-mitigate
Type /risk-mitigate (optionally: R01 R03 — specific risks; with no arguments — all High/Critical without measures). For each risk the agent prepares:
- Mitigation — what is done now to reduce the likelihood or impact: concrete actions, dates, a named owner;
- Contingency — what to do if the trigger fires or the mitigation fails;
- optionally — a refined trigger.
Both measures are written into one register cell (the "M: … · C: …" format) after confirmation.
Quality bar: controllable by this project's roles; no fake progress percentages; no empty "monitor closely" without a measurable action. If the evidence is thin, the agent says so and offers to clarify.
How it comes together in a cycle
/risks → the register: candidates, scoring, triggers
/risk-mitigate → measures: mitigation + contingency
/manage (weekly) → the "Risks check" section: what is still valid, progress of measures
/status-delta → a risk occurred? → status "occurred" in the register, the work — into the tracker
Reviews follow the schedule in the register (the next review date) and the triggers.
What the agent does not do
- Does not invent measures at the identification stage — the "Controls" cell stays "not planned" until
/risk-mitigate; - Does not create tracker issues silently — accepted measures can become tickets via
/tickets(as a proposal); - Does not run a GRC register — these are project delivery risks, not organizational security risks;
- Does not wipe the register on refresh — merge only, with a change log.
Where to continue
- Scope control — material scope changes often spawn risks.
- Daily operations: walkthroughs and meetings — the weekly risks check in the walk.
- Reporting for management — risks and measures in the reports.