Decision Risk Register

intent

build a structured risk register for a medium-stakes decision by naming what could go wrong, how likely and severe each risk is, what early warning signs to watch, and what mitigation or contingency plan is realistic. use this when committing to a project, hire, purchase, move, launch, or household plan and you want to surface failure modes before money, time, or reputation is on the line. the skill focuses on the chosen or leading option, not scoring multiple options or forcing a final decision. it's a structured thinking tool, not a substitute for expert judgment on legal, medical, financial, employment, safety, or specialized professional questions.

inputs

user context:

• the decision, planned action, or leading option you're evaluating
• decision deadline or timeline
• constraints (budget, time, team size, regulatory limits, etc.)
• definition of success (what does a good outcome look like)
• stakeholders affected or involved

external connections (optional):

• none required. this skill works offline with conversation and notes.

edge cases to know:

• if the user hasn't chosen an option yet, ask them to name the leading option or focus on the one they're leaning toward
• if the decision is immediate (same-day) or involves urgent safety risk, escalate to expert input before completing the register
• if the decision touches legal, medical, financial, employment, or safety domains with high consequences, the register informs but does not replace professional consultation
• if the user is ambivalent between multiple options, this skill works best when you pick one to risk-check; then repeat for the other if needed

procedure

step 1: state the decision

• input: ask the user for the decision, option name, planned action, deadline, context, constraints, and success definition
• output: a one-paragraph decision snapshot that frames what you're evaluating

step 2: surface risk categories

• input: the decision snapshot from step 1
• output: prompt the user (or generate from context) a list of obvious and hidden risks across these categories: dependency, people, cost, time, quality, reputation, safety, compliance, and opportunity cost. keep categories relevant to their context.

step 3: convert worries into risk statements

• input: vague concerns or risks from step 2
• output: rewrite each as a specific "if [event or condition], then [impact]" statement. separate causes, events, and impacts where possible. example: "if the freelancer quits mid-project, then deliverables delay 4 weeks and rework costs double."

step 4: score qualitatively

• input: ranked risk statements from step 3
• output: assign simple labels (low, medium, high) for probability, impact, detectability, and urgency. explain that scores are judgment aids, not precise predictions.

step 5: identify warning indicators

• input: risks scored in step 4, especially high-impact or high-probability ones
• output: for each important risk, name early warning signs, trigger metrics, deadlines, conversations, missing evidence, or external signals that would show the risk is increasing. example: "freelancer misses first weekly check-in or says 'busy with other projects.'"

step 6: define mitigation and contingency

• input: risks and warning indicators from steps 4 and 5
• output: separate actions to reduce risk before commitment (mitigations) from actions to take if the risk occurs (contingencies). keep both realistic, owned, and time-bound. example mitigation: "require a signed statement of work with penalties for early exit." example contingency: "identify a backup freelancer by month 1."

step 7: assign owners and reviews

• input: mitigation and contingency actions from step 6
• output: assign an owner or reviewer for each risk (can be the user). add review dates or checkpoints tied to the decision timeline. example: "owner: you, review date: before signing contract."

step 8: provide confidence note

• input: all risks, mitigations, contingencies, and owners from steps 1-7
• output: a concise confidence note. choose one: go, go with mitigations, review-first, delay, or no-go. explain the main uncertainty and what evidence would improve confidence. do not force a decision.

decision points

if the user has not chosen a leading option:

• ask them to name the option they want to risk-check, or focus on the option they are most inclined toward. do not score multiple options in one register.

if the decision has immediate consequences (same-day, irreversible, safety-critical, high financial exposure):

• recommend qualified professional input (lawyer, doctor, financial advisor, safety engineer, etc.) before finalizing. the register informs but does not replace expert judgment.

if the user pressures you to say "go" or "no-go":

• do not force a decision. explain the main uncertainties and what evidence (external review, legal check, pilot, contingency test, etc.) would reduce them.

if risks are unclear or vague:

• ask follow-up questions to sharpen the "if X, then Y" statement. avoid generic risks like "people risk." make it concrete: "if the team lead leaves, then the onboarding backlog grows 8 weeks."

if a risk is outside your scope (legal liability, medical outcome, safety certification, regulatory compliance):

• name it as a risk, but recommend expert input. do not score or advise on the substance.

if the user wants to track the register after commitment:

• include review dates and owner checkpoints in step 7. suggest a follow-up in 2-4 weeks or at key milestones.

output contract

deliver a decision risk register as a structured document with these sections:

1. decision snapshot (1 paragraph): decision name, option, timeline, success definition, constraints, stakeholders.

2. ranked risk register (table or list): each risk ranked by probability, impact, detectability, urgency (low/medium/high). include "if X, then Y" statement, cause, event, and impact.

3. top warning indicators (list): for the highest-impact or highest-probability risks, list early warning signs, metrics, conversations, or deadlines that signal increasing risk.

4. mitigation plan (list): actions to take before commitment to reduce the likelihood or impact of each risk. owner, deadline, and status for each mitigation.

5. contingency plan (list): actions to take if a risk occurs. owner, trigger condition, and response timeline for each contingency.

6. owners and review dates (table or list): assigned owner or reviewer for each risk, review date, and checkpoint tied to decision timeline.

7. confidence note (1 paragraph): go, go with mitigations, review-first, delay, or no-go. explain main uncertainty and what evidence would improve confidence.

8. questions that would reduce uncertainty (bullet list): specific questions, data points, conversations, or tests that would increase confidence in the decision.

format as markdown, spreadsheet, or shared doc. ensure the register is readable, not verbose.

outcome signal

you know the skill worked when:

• the user has a clear "if X, then Y" risk statement for every major failure mode they're worried about.
• the register ranks risks by probability, impact, detectability, and urgency, and the user agrees the ranking makes sense.
• the user has identified early warning signs they will actually monitor before and after commitment.
• the user has separated what they will do before committing (mitigations) from what they will do if trouble appears (contingencies), and both are realistic and owned.
• the user has a confidence note (go, go with mitigations, review-first, delay, or no-go) and knows what evidence would change their mind.
• if the decision is high-stakes (legal, medical, financial, safety, employment), the user knows they need expert input and the register does not replace that.
• the user schedules a follow-up review at a specific date or milestone tied to the decision timeline.