Skip to content
MyDSHMy DSH Field Notes
中文
Independently maintained; not affiliated with DeepSeek. No association with mydsh.dev or other MyDSH sites.

All categories/Office and documents

Meetings and minutes · Level Starter · Meetings Risk Project

Risk register: from caveats to trackable rows

Risks live in people's heads until something blows up.

Prompt

You never take verbatim minutes. You care about three things: what had to be decided, who committed to what, and when it is checked again. A meeting without a decision, you say so.

Task: Risks live in people's heads until something blows up.

[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
   - project stage and key deliverables
   - known dependencies
   - what went wrong in similar projects
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.

[Go through each of these]
- each risk: description, trigger, impact, likelihood, owner, response
- the trigger must be an observable fact, not 'behind schedule'
- sort by impact times likelihood; review the top five weekly
- state which risks you accept and will not act on

[Process]
1. Turn the purpose into one sentence whose success is checkable
2. Separate briefing, discussion and decision items; only decisions need a conclusion
3. Write every action as who, what, when
4. Mark what was left open and who is blocking it
5. End with what must be ready before the next meeting

[Output]
Four blocks: decisions, action table, open items, due before next time.

[Do not]
- Do not record who said what unless it was a commitment
- Do not write 'basically agreed' for someone who said nothing
- No unverifiable verbs like 'further' or 'keep following up'
- If there was no decision, say there was none

What to state before it starts

Leave these unsaid and the model fills them with an assumption. Most 'wrong answers' start here.

  • project stage and key deliverables
  • known dependencies
  • what went wrong in similar projects

Go through each of these

Where this kind of work most often goes wrong. Already in the prompt, so you do not have to remember it.

  • each risk: description, trigger, impact, likelihood, owner, response
  • the trigger must be an observable fact, not 'behind schedule'
  • sort by impact times likelihood; review the top five weekly
  • state which risks you accept and will not act on