Risk Analysis

2. Scenario Exploration

Check whether at least one multi-model provider CLI is installed:

MM_AVAILABLE=0
if uv run mm-detect --json 2>/dev/null | python3 -c "
import json, sys
d = json.load(sys.stdin)
sys.exit(0 if any(v.get('installed') for v in d.get('providers', {}).values()) else 1)
"; then
  MM_AVAILABLE=1
fi

When multi-model is available (and --no-multi-model is not set), use parallel external dispatch to explore failure scenarios. This replaces the single-oracle approach with a consensus from 3 independent external models across 3 rate buckets.

cat > /tmp/gw_risk_prompt.txt <<EOF
Analyze risk scenarios for "$proposal_title" under $agency $mechanism.
Explore what-if failure modes across five categories:
  1. Technical (method fails, data unavailable, compute insufficient)
  2. Personnel (key departures, hiring delays)
  3. Timeline (external dependencies, regulatory delays)
  4. Budget (cost overruns, currency shifts)
  5. Regulatory/ethics (approval delays, compliance gaps)

For each risk, give likelihood (Low/Medium/High), impact (Low/Medium/High),
and at least two concrete mitigation strategies. Discuss tradeoffs between
mitigations.

Output as a structured markdown list. Target 12-18 risks total across the
five categories. Don't pad — prefer fewer, higher-quality risks.

--- OBJECTIVES ---
$(cat "$proposal_dir/sections/objectives.md")

--- METHODOLOGY ---
$(cat "$proposal_dir/sections/methodology.md" 2>/dev/null || cat "$proposal_dir/sections/excellence.md")

--- WORK PLAN ---
$(cat "$proposal_dir/sections/work_plan.md" 2>/dev/null || cat "$proposal_dir/sections/implementation.md")
EOF

uv run mm-ask \
  --models gpt-5.4-high,gemini-3.1-pro,grok-4-20-thinking \
  --prompt-file /tmp/gw_risk_prompt.txt \
  --output "$proposal_dir/review/risk_scenarios.json" \
  --timeout 300 \
  --verbose

Read the 3 risk lists from the JSON output. Merge them by: (a) identifying risks flagged by ≥2 reviewers (consensus risks, highest confidence), (b) including single-reviewer risks that seem high-impact (edge catches), (c) de-duplicating mitigations that cover the same root cause. Treat this merged list as the raw input for the risk matrix in step 3.

Fallback (single-Claude path): If mm-detect shows zero installed providers, Claude performs the risk enumeration directly — systematically walking each objective through the five risk categories and generating scenarios from first principles. Less robust than the multi-model path but still catches the most common failure modes.

3. Build Risk Matrix

Structure the scenario output and your own analysis as a risk matrix across 5 categories:

Rate each risk:

• Likelihood: Low / Medium / High
• Impact: Low / Medium / High

Generate a mitigation strategy for every Medium or High risk. Claude is responsible for producing the final structured table — the scenario exploration is input, but the table itself is Claude's synthesis.

4. Generate Risk Mitigation Document

Write sections/risk_mitigation.md containing:

1. Risk identification methodology (brief description of the assessment approach)
2. Risk matrix table (all identified risks with likelihood, impact, mitigation)
3. Contingency plans for the top 3 highest-risk items (detailed alternative approaches)
4. Monitoring approach (how risks will be tracked during project execution)

5. Feed Into Implementation Section

For EU proposals, risk management is expected within the Implementation section. Provide the key risk findings as input to the proposal writing phase:

• Contingency plans should be referenced in the relevant work packages
• Alternative approaches should be mentioned in the methodology
• Timeline buffers should be visible in the Gantt chart

Update the existing sections/implementation.md or sections/methodology.md if they already exist, adding risk-aware language and contingency references.

EU-Specific Notes

• Horizon Europe: Risk management is an explicit sub-section within Part B2 (Implementation). Frame risks using the standard EU terminology: "risk identification", "risk assessment", "risk mitigation measures", "risk monitoring".
• ERC: Risk is addressed implicitly through the "high-risk/high-gain" framing. Emphasize that ambitious goals have identified risks with credible mitigation paths.
• MSCA: Career development risks (e.g., host institution changes, training plan disruptions) should be included alongside scientific risks.

Notes

• Be honest about risks — reviewers appreciate realistic assessment over optimistic hand-waving.
• The risk matrix should contain 8-15 risks. Fewer suggests shallow analysis; more suggests padding.

Error Handling

• No provider CLIs installed: Silently fall back to single-Claude risk enumeration. Do not error.
• Missing input sections: If objectives.md or methodology.md is absent, halt with a clear error telling the PI which prior phase must run first.
• Too few risks generated (<8): Loop back through the five categories explicitly and add risks until the minimum is met, or warn the PI that the project is unusually well-scoped.
• Ambiguous likelihood/impact: Default to Medium/Medium and flag for PI review rather than guess.
• mm-ask returns all-failed responses: Log the raw JSON to review/risk_scenarios_raw.json and fall back to single-Claude enumeration. The skill should never silently skip risk analysis.
• One reviewer out of three fails: Proceed with the 2 successful responses — consensus still works with 2-of-3, just with slightly weaker signal strength.