Generate Risk Register

generate-risk-register

Triggers

Russian: «сформируй реестр рисков», «подготовь risk register», «обнови реестр рисков» English: "generate risk register", "create risk register", "update risk register"

Language Detection

Determine the language of the user's request:

• If the request is in Russian → use templates with -ru suffix
• Otherwise → use templates with -en suffix

All output (headings, labels, comments, instructions) must match the detected language.

1. Input Data

Initial mode (phase 1)

Detailed mode (phase 2)

If required data is missing — request using this template:

To generate the risk register, the following is required:
— Initial mode: approved project charter (project-charter.md).
— Detailed mode: charter + project plan (project-plan.md) + current risk register (risk-register.md).
Available data: [list what is available].
Missing: [be specific].

2. Execution Algorithm

1. Determine mode. If the user has not specified — infer from context: project plan present → detailed, charter only → initial. If ambiguous — ask.

2. Verify input data. Minimum data for the selected mode is present → step 3. Missing → request using the template from §1. Do NOT generate a placeholder or sample register.

3. Read the template risk-register-ru.md or risk-register-en.md from project knowledge (based on detected language).

4. Identify risks.

   • Initial: Analyze the charter from scratch — goal, scope (included and excluded), timeline, budget, constraints, assumptions, team composition. For each charter section evaluate: what could go wrong? Use categories from the reference table (§3). Recommended count: 5–10 risks. Do not automatically copy the top-3 risks from the charter — perform an independent analysis (charter risks may enter the register if confirmed by analysis).
   • Detailed: Use register v1 as the base. Analyze the project plan: WBS (which work packages are highest risk?), critical path, dependencies, resource constraints. Add new risks. Update assessments of existing risks (probability/impact may have changed). For each risk — link to WP-xxx from the plan, assign a specific owner from project-plan. Specify actions concretely.

5. Assess each risk using the scale from the reference table (§3): category, probability (H/M/L), impact (H/M/L), level, strategy (Avoid/Mitigate/Transfer/Accept). Level is calculated strictly by the table below — not by intuition or proximity to adjacent cells:

   Probability	Impact	Level
   H	H	Critical
   H	M	High
   M	H	High
   H	L	Medium
   M	M	Medium
   L	H	Medium
   M	L	Low
   L	M	Low
   L	L	Low

   Common error: H×M and M×H are High, not Medium. Verify every risk against this table before recording in the register.

6. Fill the register table following the rules in §3.

7. Fill the risk matrix. For each risk, perform 3 steps:

   • (a) Read from the table: probability → this is the ROW of the matrix; impact → this is the COLUMN of the matrix.
   • (b) Find the cell at the intersection of that row and column → write the ID.
   • (c) Verify: matrix row = probability from the table? matrix column = impact from the table? If not — correct.

   Common error: for risks with L (low) probability, the ID is incorrectly placed in the "Medium" row instead of "Low". Verify each L-probability risk separately.

8. Validate the result using the checklist (§5).

9. Present the result in chat. Format:

   • What was done: "Risk register generated (mode: initial/detailed) based on [list sources]."
   • Number of risks: N (including critical: M).
   • Assumptions (if any).
   • Action required: "Approve, provide comments, or reject."
   • Do not include system file paths.
   • [register content]

10. Wait for user response.

    • Approval → produce final text.
    • Comments → revise, show updated version. After 3rd iteration — ask: "Continue revising or finalize current version?"

11. After approval — complete both steps:

    • Provide the user with text to insert into log.md and project-state.md.
    • Propose the specific next skill. This is a mandatory part of the response — without it the skill chain breaks. Use these exact phrases:
      • Initial: "Risk register approved. Next task: generate-project-plan (project plan). Start?"
      • Detailed: "Risk register updated. Next task: generate-comm-plan (communication plan). Start?"

3. Filling Rules

Header metadata

• Version: 1.0 (initial) or 2.0 (detailed when updating v1).
• Date: current generation date (YYYY-MM-DD).
• File: risk-register.md.
• Document status: draft (at generation). After user approval — approved.
• Mode: initial or detailed.
• Source: list source files (e.g., "project-charter.md" or "project-charter.md, project-plan.md, risk-register.md v1").

Register table

The table contains exactly 10 columns (no more, no less): ID, Risk, Category, Probability, Impact, Level, Strategy, Actions, Owner, Status. Adding extra columns is prohibited — it breaks compatibility with the template and other skills. The difference between modes is in the depth of content:

Category reference table

Assessment scale

Risk level matrix (probability × impact)

Strategy reference table

Risk matrix (visualization)

Place risk IDs in the matrix cells from the template. Each risk goes into one cell corresponding to its probability and impact assessment.

4. Placeholder Table

Placeholders {{}} in the template are fill-in guides, not auto-substitution variables. Replace each with the corresponding value from the input data.

5. Validation Checklist

Before presenting the result to the user — verify:

• All required placeholders replaced with values
• No {{}} placeholders remaining in the text
• Mode (initial/detailed) specified in the header
• Initial: ≥5 risks covering ≥3 categories from the reference table
• Detailed: all risks from v1 are present (updated or closed) + new risks from the plan
• Each risk: wording is "event → consequence", not just a topic
• Assessments are consistent: for EACH risk calculate the level using the table in §2 step 5 and COMPARE with the recorded value. Special attention: H×M=High (not Medium), M×H=High (not Medium)
• Strategy matches context (not "Accept" for a critical risk without justification)
• Detailed: each risk linked to WP-xxx, owner is a specific person
• Risk matrix is filled in, IDs match the table
• Matrix-table synchronization (element by element): for EACH risk write the triple: ID → probability from table → matrix row; ID → impact from table → matrix column. If row ≠ probability or column ≠ impact — CORRECT. Special attention: risks with L probability frequently end up in the "Medium" row
• All agent assumptions listed in the response
• Document status = draft

6. Dependencies

Consumes (input):

• project-charter.md ← generate-charter (both modes)
• project-plan.md ← generate-project-plan (detailed only)
• risk-register.md v1 ← generate-risk-register initial (detailed only)

Produces (output): risk-register.md → consumed by:

• generate-project-plan — for incorporating risks during planning (if initial)
• generate-closure-report — for final analysis (if detailed)

After the register is approved, the user must upload risk-register.md to the project knowledge base so it is available to dependent skills.

7. Usage Examples

Initial (phase 1)

User command:

Generate the risk register. Project charter is in knowledge.

Agent response (after generation):

Risk register generated (mode: initial) based on: project-charter.md.

Identified 7 risks (critical: 1, high: 2, medium: 3, low: 1). Categories covered: Technical, Resource, External, Organizational.

Assumptions:

• Project type inferred as "IT product launch" from the charter description.
• All risk owners set to PM (to be specified in detailed mode after the project plan is ready).

Action required: approve, provide comments, or reject.

[register content]

Detailed (phase 2)

User command:

Update the risk register. Project plan and current register are in knowledge.

Agent response (after generation):

Risk register updated (mode: detailed) based on: project-charter.md, project-plan.md, risk-register.md v1.

Risks in register: 11 (was 7). New: 4 (from WBS and resource plan analysis). Updated assessments: R003 escalated to "High" (external contractor dependency identified). All risks linked to work packages, owners assigned.

Assumptions:

• Owners assigned based on roles from project-plan.md.

Action required: approve, provide comments, or reject.

[register content]

Change Log