severity-rubric
Every finding gets exactly one severity. Calibration matters more than volume: an inflated severity makes the whole review untrustworthy. When unsure between two levels, pick the lower one and explain.
$ npx -y skills add vanara-agents/skills --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
Every finding gets exactly one severity. Calibration matters more than volume: an inflated severity makes the whole review untrustworthy. When unsure between two levels, pick the lower one and explain.
Agent definition
severity-rubric.mdSeverity Rubric
Every finding gets exactly one severity. Calibration matters more than volume: an inflated severity makes the whole review untrustworthy. When unsure between two levels, pick the lower one and explain.
CRITICAL — Block merge
Exploitable vulnerability, data loss, or data corruption. The change must not merge as-is.
Examples:
- SQL/command injection reachable from user input.
- Authentication bypass or broken authorization (IDOR) exposing other users' data.
- Hardcoded production secret committed to the repo.
- A migration or write path that can corrupt or delete data.
- Unsafe deserialization of untrusted input (RCE class).
**Action:** Verdict = Block. Author must fix before merge. Rotate any exposed secret immediately.
HIGH — Fix before merge
A real bug or significant security/quality risk that will bite in production, but not an immediate exploit/data-loss.
Examples:
- Unhandled error path that crashes the process on bad input.
- Race condition on shared state under concurrency.
- Missing tests on a risky new code path.
- Resource leak (unclosed connection) under load.
- XSS via unescaped output in a low-traffic admin view.
**Action:** Verdict = Request-changes. Should be fixed before merge.
MEDIUM — Should fix
Maintainability concern or minor correctness issue. Won't cause an outage but adds risk or friction.
Examples:
- A 59-line function doing three jobs.
- Duplication that will drift.
- Deep nesting that obscures logic.
- Missing validation on an internal, low-risk input.
**Action:** Fix when reasonable; author may defer with a tracking note.
LOW — Optional
Style, naming, micro-improvements. Never blocks a merge.
Examples:
- A poorly named variable.
- A comment that's now stale.
- A spot where a constant would read better than a literal.
**Action:** Note as a nit. Verdict can still be Approve-with-nits.
Verdict mapping
| Findings present | Verdict | |---|---| | Any CRITICAL | Block | | Any HIGH (no CRITICAL) | Request-changes | | Only MEDIUM/LOW | Approve-with-nits | | None | Approve |
Read more
Severity Rubric
Every finding gets exactly one severity. Calibration matters more than volume: an inflated severity makes the whole review untrustworthy. When unsure between two levels, pick the lower one and explain.
CRITICAL — Block merge
Exploitable vulnerability, data loss, or data corruption. The change must not merge as-is.
Examples:
- SQL/command injection reachable from user input.
- Authentication bypass or broken authorization (IDOR) exposing other users' data.
- Hardcoded production secret committed to the repo.
- A migration or write path that can corrupt or delete data.
- Unsafe deserialization of untrusted input (RCE class).
**Action:** Verdict = Block. Author must fix before merge. Rotate any exposed secret immediately.
HIGH — Fix before merge
A real bug or significant security/quality risk that will bite in production, but not an immediate exploit/data-loss.
Examples:
- Unhandled error path that crashes the process on bad input.
- Race condition on shared state under concurrency.
- Missing tests on a risky new code path.
- Resource leak (unclosed connection) under load.
- XSS via unescaped output in a low-traffic admin view.
**Action:** Verdict = Request-changes. Should be fixed before merge.
MEDIUM — Should fix
Maintainability concern or minor correctness issue. Won't cause an outage but adds risk or friction.
Examples:
- A 59-line function doing three jobs.
- Duplication that will drift.
- Deep nesting that obscures logic.
- Missing validation on an internal, low-risk input.
**Action:** Fix when reasonable; author may defer with a tracking note.
LOW — Optional
Style, naming, micro-improvements. Never blocks a merge.
Examples:
- A poorly named variable.
- A comment that's now stale.
- A spot where a constant would read better than a literal.
**Action:** Note as a nit. Verdict can still be Approve-with-nits.
Verdict mapping
| Findings present | Verdict | |---|---| | Any CRITICAL | Block | | Any HIGH (no CRITICAL) | Request-changes | | Only MEDIUM/LOW | Approve-with-nits | | None | Approve |
🐒 Free agents, skills & packs for Claude Code One subscription. An army of Claude Code agents. 30 production-grade agents, skills, and packs for Claude Code — free, Apache-2.0, install with one command.
Repo: vanara-agents/skills
Other agents on vanara-agents-skills.
- AGENT
Use when designing a new HTTP/GraphQL API or changing an existing one — modeling resources, defining endpoint contracts, choosing status codes, pagination, filtering, error envelopes, versioning, and idempotency. Produces a reviewable API contract plus an OpenAPI snippet, not
Open agent - review-notes
This shows how the api-designer agent reviews a flawed draft. Findings are severity-ranked so the implementer fixes the contract-breakers first. Severity legend: **CRITICAL** (breaks clients / data risk), **HIGH** (real bug or inconsistency), **MEDIUM** (maintainability),
Open agent - contract-and-openapi
The contract is the deliverable. Express it as an **OpenAPI 3.1** document so it is human-readable *and* machine-checkable. This reference covers how to structure that document and what `scripts/lint-openapi.mjs` enforces.
Open agent - design-checklist
Run through this before declaring an API contract done. It is ordered the way you should *design*: resources first, cross-cutting rules last. Every box is a place real APIs go wrong in production.
Open agent - versioning-and-evolution
APIs are forever once published: a consumer you've never met may depend on any field you expose. Design so you can **add without breaking**, and version explicitly when you must break.
Open agent - pr-comment-template
Copy-paste templates for leaving review comments. Keep each comment to one finding: an anchor, the problem, and the fix.
Open agent

