Risk Mitigate

/risk-mitigate — Implement Mitigation Measures

Read the shared risk model at .claude/skills/shared/risk-model.md for all measure definitions, detection signals, tier requirements, and output formats. Do not duplicate those lists here — always reference the shared model as the single source of truth.

Step 1 — Read Assessment from CLAUDE.md

1. Read the project's CLAUDE.md file.
2. Look for a section titled ## Risk Radar Assessment.
3. If not found, stop and tell the user:

   No Risk Radar Assessment found in CLAUDE.md. Please run /risk-assess first.

4. If found, parse every ### Module: {name} subsection. For each module extract:
   • The five dimension scores (codeType, language, deployment, data, blastRadius)
   • The LLM Runtime Integration level (L0–L4), if present (default L0 for legacy assessments)
   • The overall Tier (1–4)
5. Print a summary table:

Found N module(s) with risk assessments:
| Module | Tier | Highest Dimension | LLM Runtime |
|--------|------|-------------------|-------------|
| ...    | ...  | ...               | L{N}        |

Step 2 — Detect Existing Mitigations

For each module (or repo-wide for measures like CI and linting):

2a. Determine project type

• JavaScript/TypeScript: package.json exists
• Python: pyproject.toml, requirements.txt, or setup.py exists
• Rust: Cargo.toml exists
• Multi-language: multiple of the above

2b. Check detection signals

Use the Detection signals tables in .claude/skills/shared/risk-model.md (one per tier) to check which mitigations are already present.

Tier 1 checks:

Tier 2 checks:

Tier 3 checks:

Tier 4 checks:

For each check, record the result as:

• Present — config file or tool found and appears correctly configured
• Missing — no config found
• Partial — config exists but incomplete (e.g., linter config but no CI integration)

Step 3 — Present Gap Analysis

For each module, show a gap analysis table grouped by tier (cumulative up to the module's tier):

### Gap Analysis: {module-name} (Tier {N})

#### Tier 1 — Automated Gates
| Measure | Type | Status | Details |
|---------|------|--------|---------|
| Linter & Formatter | deterministic | Present | .eslintrc.js found |
| Pre-Commit Hooks | deterministic | Missing | — |
| ...

#### Tier 2 — Extended Assurance
| Measure | Type | Status | Details |
|---------|------|--------|---------|
| SAST | deterministic | Missing | — |
| ...

After the table, summarize:

• Total measures required for this tier: X
• Already present: Y
• Missing: Z
• Completion: Y/X (percentage)

3b. LLM Runtime Callout (L3+ modules only)

If any module has llmRuntimeLevel >= 3, display a callout before moving to implementation, making it explicit that our mitigation catalog is insufficient for runtime LLM risks:

⚠️  {module} has LLM Runtime Integration L{N} ({name})

The mitigations listed above cover build-time risks (how the code was
written). Your runtime LLM use introduces a qualitatively different risk
class — prompt injection, unauthorized tool calls, agentic runaway — that
this framework does not deeply cover.

For these risks, defer to specialized frameworks:

  • OWASP LLM Top 10
    https://owasp.org/www-project-top-10-for-large-language-model-applications/
  • Palo Alto Unit 42 SHIELD
    https://unit42.paloaltonetworks.com/securing-vibe-coding-tools/
  • Aikido VCAL
    https://www.aikido.dev/blog/vibe-coding-security
  • Google SAIF
    https://saif.google/secure-ai-framework

Recommended runtime mitigations (not installable via this skill):
  - Prompt injection detection and input sanitization
  - Tool allow-list / deny-list with least-privilege function calling
  - Output filtering (PII redaction, unsafe content detection)
  - Sandbox for code execution (e2b, Firecracker, gVisor)
  - Rate limiting and cost caps per user/session
  - Audit logging of all tool calls with prompt provenance
  - Human-in-the-loop confirmation for destructive actions

Ask the user:

Would you like to track these runtime mitigations in CLAUDE.md as
pending items? [y/N]

If yes, add a new table ### LLM Runtime Mitigations: {module-name} (L{N}) to CLAUDE.md with the recommended runtime mitigations as Pending, plus links to the source framework for each. The skill does not install these tools — they require architectural decisions that belong with the user, not an automated skill.

Step 4 — Interactive Implementation

Work through missing measures in priority order: all Tier 1 gaps first, then Tier 2, etc.

For each missing measure:

1. Explain what the measure does and why the module's tier requires it.
2. Ask the user whether they want to implement it now. Wait for confirmation before proceeding.
3. Implement based on the tier level:

Tier 1 — Install and configure directly

After installing, verify the tool works:

• Run the linter and confirm it executes without config errors
• Run the formatter in check mode
• Run the type checker
• Validate the CI workflow YAML is well-formed

Tier 2 — Install where possible, suggest for others

Tier 3 — Configure where possible, guide for others

Tier 4 — Recommendations and checklists only

After each installation

• Verify the tool works (run it, check output)
• Create a git commit for the installed tool:

  git add <relevant files>
  git commit -m "chore: set up {tool name} for {module}"
  

Step 5 — Update CLAUDE.md

After completing implementations (or if the user stops partway through):

1. Open CLAUDE.md
2. For each assessed module, add or update a ### Mitigations: {module-name} (Tier N) section
3. Use the format from .claude/skills/shared/risk-model.md:

### Mitigations: {module-name} (Tier {N})

_Updated by `/risk-mitigate` on YYYY-MM-DD_

| Measure            | Status  | Details                        |
| ------------------ | ------- | ------------------------------ |
| Linter & Formatter | Present | eslint.config.js, .prettierrc  |
| Type Checking      | Set up  | tsconfig.json strict enabled   |
| Pre-Commit Hooks   | Set up  | husky + lint-staged configured |
| SAST               | Pending | —                              |
| Branch Protection  | N/A     | Not required for Tier 1        |

Status values:

• Present — was already in place before running this skill
• Set up — installed/configured during this session
• Pending — required but not yet implemented (user deferred or manual action needed)
• N/A — not required at this module's tier level

4. Commit the CLAUDE.md update:

   git add CLAUDE.md
   git commit -m "docs: update mitigation status in CLAUDE.md"
   

Step 6 — Update ADR (if exists)

If an ADR was generated during /risk-assess, update it with mitigation status:

1. Check for ADR reference in CLAUDE.md:

   • Look for a line like _Architecture Decision: See [ADR-NNN](docs/adr/NNN-risk-classification-*.md)_
   • Extract the ADR file path

2. If ADR exists, update it:

   • Read the current ADR file
   • Add or replace a section at the end titled ## Implementation Status (or ## Mitigations Implemented if following strict Nygard format)
   • Include the mitigation status table from CLAUDE.md
   • Update the Status field at the top:
     • If all required mitigations are now "Present" or "Set up" → change Status to Accepted
     • If some are still "Pending" → keep Status as Proposed

3. Example addition to ADR:

   ## Implementation Status
   
   _Updated by `/risk-mitigate` on YYYY-MM-DD_
   
   | Measure            | Status     | Details                                     |
   | ------------------ | ---------- | ------------------------------------------- |
   | Linter & Formatter | ✅ Set up  | eslint.config.js, .prettierrc               |
   | Pre-Commit Hooks   | ✅ Set up  | husky + lint-staged                         |
   | SAST               | ⬜ Pending | CodeQL workflow created, awaiting first run |
   
   **Overall Status:** 8/10 measures active → ADR Status updated to **Accepted**
   

4. Update arc42 reference (if exists):

   • If docs/arc42/chapters/09_architecture_decisions.adoc contains a reference to this ADR
   • Update the status badge there as well:

     **Status:** Accepted | **Date:** YYYY-MM-DD | **Tier:** {N} | **Mitigations:** 8/10 active
     

5. Commit the ADR update:

   git add docs/adr/NNN-*.md docs/arc42/ (if modified)
   git commit -m "docs: update ADR with mitigation implementation status"
   

Important Guidelines

• Always read .claude/skills/shared/risk-model.md at the start for the authoritative measure definitions and detection signals. Do not hardcode or duplicate those lists.
• Never install anything without asking the user first. Present the measure, explain it, and wait for confirmation.
• Verify each tool after installation. Run the tool and confirm it executes without errors.
• Commit each tool separately. Each installed mitigation gets its own commit for clean history.
• Handle both JS/TS and Python projects. Detect from package.json vs pyproject.toml/requirements.txt.
• Tiers are cumulative. A Tier 3 module needs all Tier 1 + Tier 2 + Tier 3 measures.
• Be conservative with automated configuration. For measures that require external service setup (SonarCloud, CodeRabbit), provide guidance rather than attempting partial setup that won't work.
• If a measure is already present, confirm it is properly configured. A linter config without CI integration is only "Partial".