Risk assessment
Skill andresnator/agents-orchestrator/skills/risk-assessment
npx -y skills add andresnator/agents-orchestrator --skill risk-assessmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Trigger: risk assessment, refactor risk. Classify technical and functional legacy risk.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
1.5 KB, as published. Nobody here has run it
Risk Assessment
Assess risk from technical and functional evidence.
Signals
- Complexity and large methods/classes.
- Missing tests or low coverage.
- CRAP score when available.
- Fan-in/fan-out and number of consumers.
- External dependencies.
- Public contracts.
- Async behavior, transactions, persistence, and critical domain rules.
- Git churn when history is available.
Classify overall risk as low, medium, high, or critical and explain why.
Churn and hot spots
When git history is available (read-only git log / git blame / git shortlog), rank the target's files by change frequency. High churn on a risky unit raises its priority: refactor pays off where change keeps happening. Churn ≈ 0 lowers it — untouched ugly code is zero-interest debt, and refactoring it has ROI near zero unless a planned change is about to land there.
Business value tier
Depth of investment follows the target's value tier, not only its technical risk: core domain code (differentiating business logic) justifies deep plans; supporting code justifies moderate ones; generic/commodity code is often better replaced than refactored. Infer the tier from evidence (domain language, dependency direction, test intensity) and say explicitly when it cannot be inferred.