Files
skills/skills/regulatory-risk-assessment/SKILL.md
T
mathiasandClaude Opus 5 56a947b2a0 refactor(plugin)!: ship as a Claude Code plugin, one dir link per harness
Skills move to skills/<name>/SKILL.md and the repo gains both manifests, so
it is now a marketplace hosting exactly one plugin whose root is the repo
root (source: "."). Claude Code installs it from git; no symlinks involved.

Why: install.sh wired the library into every consuming repo as an ABSOLUTE
symlink to $CHECKOUT_DIR. The checkout moved three times, most recently when
local-dev@1966d5a dropped the embedded .skills/ copy, and nothing migrated
the links — 243 dangling links across 12 repos, hidden from git by the
**/.claude/skills/ ignore rule. Worse, ~/dev spans two path roots
(/Users/mathias on the iCloud-shared Macs, /home/mathias on koala), so an
absolute link stored there is broken on one side by construction. Re-running
the installer cannot fix that; only removing the mechanism can.

install.sh keeps the harnesses with no plugin system and drops from 42 links
per harness to one directory link, via the convergent ~/.agents/skills
convention that Pi and OpenCode both read:

  ~/.agents/skills          -> $CHECKOUT_DIR/skills
  ~/.config/crush/skills    -> ~/.agents/skills
  ~/.config/opencode/skills -> ~/.agents/skills

wire_claude_repo is deleted outright rather than gated behind a flag — on a
mixed-root fleet it cannot be made correct. Antigravity and Vibe targets go
too; both unused. CHECKOUT_DIR keeps its host-local default deliberately:
pointing it into ~/dev would put a git working tree inside iCloud with two
concurrent writers.

Taskfile drops five near-identical wiring loops (they had already drifted)
and delegates to install.sh. `task check` gains frontmatter validation, a
stray-root-entry gate, and manifest/tag version parity — the loose
secret-hygiene.md sat unloadable for months because nothing checked layout.

Verified: claude plugin validate . passes clean; a probe skill loaded as
skills:zzprobe through --plugin-dir; task check green at 42 skills.

Refs: #23
Bump-Type: minor

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BeAp5LTscnz2W7Ubt4eJ6m
2026-08-23 14:29:51 +02:00

4.1 KiB

name, description
name description
regulatory-risk-assessment Produce a structured regulatory risk assessment / risk-register entry for regulated-industry features (banking, payments, PSD2/PSR, DORA, AML). Use when filing a CAD issue that needs a Risk:LOW/MEDIUM/HIGH level, or designing features touching payments, auth, data storage, or external APIs ("what are the risks?", "compliance gate", "risk register").

regulatory-risk-assessment

Produce a structured regulatory risk assessment for a feature, component, or integration — generating a risk register entry that satisfies the audit requirements of regulated-industry clients (banking, finance, insurance, PSD2/PSR, DORA, AML/KYC contexts).

Use when:

  • Filing a Gitea issue dispatched via CAD (needs Risk: LOW/MEDIUM/HIGH)
  • Designing a feature touching payments, auth, data storage, external APIs
  • Preparing a client deliverable in a regulated industry
  • "what are the risks?" / "compliance gate" / "risk register" in session

Do not use for: routine refactoring, docs-only changes, internal tooling with no external data or user impact.

What this skill produces

A docs/risk-register.md section with this schema:

R-[DOMAIN]-[NN] — [Short risk title]

Field Value
Risk What could go wrong (concrete, specific)
Regulatory reference Which obligation/regulation, if any
Likelihood H / M / L
Impact H / M / L
Overall H / M / L (highest of likelihood x impact)
Mitigation What we are doing about it
Validation Test name or Gitea issue number
Status open / mitigated / accepted

Risk ID namespace: R-AUTH-NN authentication and authorization R-DATA-NN data storage, retention, privacy R-API-NN external API integration R-PAY-NN payment and financial transactions R-INFRA-NN infrastructure and availability R-AGENT-NN agentic / AI execution R-COMP-NN compliance and regulatory obligation

Mechanics

Step 1 — Scope the assessment

  1. What external systems does this touch?
  2. What user data does it read, write, or transmit?
  3. What happens on silent failure? Loud failure?
  4. What is the blast radius of a worst-case bug?
  5. Is a regulation implicated?

Step 2 — Enumerate risks (common examples) Auth/OAuth: token theft, refresh failure, insufficient scope Email/Gmail: misclassification archives HUMAN thread, PII in logs Payment/PAIN.001: wrong amount, duplicate submission, missing field Agentic: irreversible action without approval, prompt injection, spirals Infra: single point of failure, secret in logs

Step 3 — Declare overall risk level Highest individual risk = feature overall level (LOW/MEDIUM/HIGH). This is the Risk: declaration in the CAD agent-ready issue contract.

Step 4 — Write validations Every mitigation needs a validation: - Specific test name (TestXxx) - Gitea issue number - Manual verification step with acceptance criteria Not acceptable: "will test later", "review manually"

Step 5 — Update docs/risk-register.md Append entries. Create if absent:

# Risk Register
All entries follow R-[DOMAIN]-[NN] schema.
See skills/regulatory-risk-assessment/SKILL.md for conventions.
Last updated: [date]

Integration with assessor-loop

For complex regulated-industry features (PSD2/PSR, DORA, AML), route to mathias/assessor-loop for deep obligation decomposition first. Use this skill standalone for internal tooling or general engineering risk.

Integration with CAD

Every CAD-dispatched issue must include: Risk: LOW | MEDIUM | HIGH

CAD pre-flight (agentsquad#29) rejects issues without it. If genuinely no risks: declare LOW and note why.

Example entry

R-DATA-01 — Email misclassification archives a HUMAN thread

Field Value
Risk LLM labels a real person's email as NOISE, causing auto-archive
Regulatory reference None (internal)
Likelihood M
Impact H
Overall H
Mitigation Phase 1 read-only; HUMAN class never auto-archived in any phase
Validation TestClassifier_HumanThreadNeverArchived; 1-week Phase 1 review
Status open