plugins/leyline/skills/risk-classification/SKILL.md
Classifies agent tasks into 4 risk tiers (GREEN/YELLOW/RED/CRITICAL). Use when assessing action reversibility before committing to an approach.
npx skillsauth add athola/claude-night-market risk-classificationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Provides inline risk classification for agent tasks using a 4-tier model (GREEN/YELLOW/RED/CRITICAL). Uses fast heuristic file-pattern matching for low-risk tiers and delegates to Skill(attune:war-room-checkpoint) for high-risk tiers requiring full reversibility scoring.
Skill(attune:war-room) instead)| Tier | Color | Scope | Example | Verification | |------|-------|-------|---------|-------------| | GREEN | Safe | Single file, trivial revert | Test files, docs, utils | None required | | YELLOW | Caution | Module-level, user-visible | Components, routes, views | Conflict check and test pass | | RED | Danger | Cross-module, security/data | Migrations, auth, database schema | War-room RS, full test, and review | | CRITICAL | Stop | Irreversible, regulated | Data deletion, production deploy | War-room RS and human approval |
Task received
|
v
Heuristic classifier (file patterns)
|
├── GREEN/YELLOW → Apply tier, continue
|
└── RED/CRITICAL → Invoke Skill(attune:war-room-checkpoint)
for reversibility scoring (RS)
|
└── RS confirms or adjusts tier
Why hybrid: GREEN/YELLOW classification is fast and deterministic (file pattern matching). RED/CRITICAL tasks warrant the overhead of full reversibility analysis because the cost of getting them wrong is high.
Add risk tier to task metadata for downstream consumption:
{
"id": "5",
"subject": "Add user authentication",
"metadata": {
"risk_tier": "YELLOW",
"risk_reason": "Modifies src/components/LoginForm.tsx (user-visible component)",
"classified_at": "2026-02-07T22:00:00Z"
}
}
Tasks without risk_tier metadata default to GREEN (backward compatible).
The 4-tier Readiness Levels system provides clear risk classification with required controls per tier:
| Level | Name | When | Required Controls | |-------|------|------|-------------------| | 0 | Routine | Low blast radius, easy rollback | Basic validation, rollback step | | 1 | Watch | User-visible changes | Review, negative test, rollback note | | 2 | Elevated | Security/compliance/data | Adversarial review, risk checklist | | 3 | Critical | Irreversible, regulated | Human confirmation, two-step verification |
See modules/readiness-levels.md for full level definitions,
selection decision tree, and integration guidance.
Risk classification sets how carefully a change is verified.
Automation tiers set how autonomously the agent acts and when it
must hand control back. Each risk tier carries a default automation
tier (GREEN to A3 autonomous, CRITICAL to A0 manual), and a
pre-licensed downgrade trigger drops the agent one tier on repeated
failure, confidence loss, a stakes spike, or repo-state mismatch
rather than re-prompting at the same level. See
modules/automation-tiers.md for the tier table and the downgrade
trigger, and imbue:assisted-mastery for the explain/produce mode
selection that reads from it.
# In your skill's frontmatter
dependencies: [leyline:risk-classification]
Append [R:TIER] marker to task format:
- [ ] T012 [P] [US1] [R:YELLOW] Create LoginForm component in src/components/LoginForm.tsx
Check risk tier before task assignment:
if task.risk_tier in ["RED", "CRITICAL"]:
invoke Skill(attune:war-room-checkpoint) for RS scoring
if CRITICAL: require human approval before proceeding
data-ai
Models a business in its own language. Use when the domain has real business rules to capture.
research
Generate diverse solution candidates with category-spanning ideation methods and rotation. Use when stuck on a design or fighting repetitive LLM output.
development
Generates and self-executes a diff-derived test plan for a PR. Use when validating PR changes before merge. Do not use for code review; use sanctum:pr-review.
development
Ramps implementation ambition a notch only after the prior increment is understood. Use when building a feature you must understand, not just ship.