القائمة
Create or update the project's RISK-POLICY.md per ISO 31000 and the risk-scorer agent. Examines the project to derive business-specific impact levels.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Check whether C4 architecture diagrams are up to date with source code
Regenerate C4 architecture diagrams (C3 component + C4 code views) from source code
Create or update a problem ticket per PROBLEM-MANAGEMENT.md. Supports creating new problems, updating root cause analysis, transitioning status, and closing problems.
Generate or update the project's Wardley Map by analyzing the codebase. Produces an OWM source file, SVG, and PNG.
| name | risk-policy |
| description | Create or update the project's RISK-POLICY.md per ISO 31000 and the risk-scorer agent. Examines the project to derive business-specific impact levels. |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Agent |
Create or update RISK-POLICY.md per ISO 31000, tailored to this project's business context. The risk-scorer agent reads this file to score pipeline actions (commit, push, release).
The risk-scorer agent, problem management skill, and any other process that needs to assess risk severity reads these definitions from RISK-POLICY.md.
Read .claude/agents/risk-scorer-pipeline.md to understand what the scorer expects from RISK-POLICY.md. Extract:
RISK-POLICY.md" in "Your Role")Use this contract to guide drafting. Do not hardcode assumptions about the number of levels, their labels, or the appetite threshold -- derive them from the agent definition.
Examine the project to understand what it does and who uses it. Adapt to the project type -- do not assume any particular framework or language.
Find the project manifest (first match wins):
package.json (Node/JS/TS)pyproject.toml or setup.py (Python)go.mod (Go)Cargo.toml (Rust)Gemfile (Ruby)pom.xml or build.gradle (Java/Kotlin)Find the project description:
README.md or README.*description field in the manifestDiscover user-facing features by scanning for:
routes/, pages/, api/, handlers/, controllers/, or grep for route decorators/annotations).html, .svelte, .tsx, .jsx, .vue, .astro files)Discover infrastructure:
Dockerfile, docker-compose.*, fly.toml, app.yaml, serverless.yml, *.tf, cloud config).github/workflows/, .gitlab-ci.yml, Jenkinsfile)Build a mental model of: what does this product do, who are its users, and what would hurt them?
Check repository visibility:
gh repo view --json isPrivate or check for other visibility indicatorsIf RISK-POLICY.md already exists, read it. Identify:
If docs/problems/ exists, scan for open or known-error problems (files ending in .open.md or .known-error.md). For each:
If recent incidents suggest the impact levels need updating, note this for step 6 (user confirmation). ISO 31000 requires risk criteria to be reviewed after incidents, not just on a schedule.
Impact levels must describe business consequences (ISO 31000 context establishment), not categories of files changed. Each level answers: "What happens to users/business if this goes wrong?"
Use 5 levels (Negligible to Severe). Tailor descriptions to this specific product:
Reference specific product features, user workflows, and infrastructure by name. Generic descriptions like "application logic affected" are wrong -- say what breaks and for whom.
Likelihood levels describe how likely a risk is to materialise. Use 5 levels (Rare to Almost certain). These are universal — not product-specific:
Risk matrix: Include the Impact × Likelihood multiplication table (5×5 = scores 1-25) and the label bands:
| Score Range | Label |
|---|---|
| 1-4 | Low |
| 5-9 | Medium |
| 10-14 | High |
| 15-25 | Critical |
The risk matrix is used by both the risk-scorer agent (pipeline risk assessment) and the problem management process (problem severity via /problem skill).
You MUST use the AskUserQuestion tool (not plain text output) to collect user confirmation. Do not proceed to step 7 until you have received answers via AskUserQuestion.
Call AskUserQuestion with a single message that presents:
Before writing the policy file, invoke the risk-scorer agent to validate the draft. This is the gate -- the enforce hook will only allow writes to RISK-POLICY.md after the scorer returns PASS.
Run the risk-scorer agent (subagent_type: "risk-scorer") with this prompt:
Review this draft risk policy for ISO 31000 compliance. Validate it.
[paste the full draft policy content here]
The risk-scorer will check:
It ends its output with RISK_VERDICT: PASS or RISK_VERDICT: FAIL. The PostToolUse hook reads this from the agent output and sets the edit marker on PASS.
Write the policy using the structure derived from the agent contract (step 1). The output must include:
When updating rather than creating:
$ARGUMENTS