OWASP Top 10 audit checklist for Web Applications (2021) and APIs (2023). Use when performing any security review, PR review, or codebase audit touching web, mobile backend, or API code. (triggers: security review, OWASP, broken access control, IDOR, BOLA, injection, broken auth, API review, authorization, access control)
95
93%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly defines its scope (OWASP Top 10 auditing for web apps and APIs), specifies when to use it (security reviews, PR reviews, codebase audits), and provides a comprehensive list of natural trigger terms spanning both common and technical security vocabulary. It uses proper third-person voice and is concise without being vague.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and domains: 'OWASP Top 10 audit checklist for Web Applications (2021) and APIs (2023)', covering security review, PR review, and codebase audit. It names specific standards and versions. | 3 / 3 |
Completeness | Clearly answers both 'what' (OWASP Top 10 audit checklist for web apps and APIs) and 'when' (performing security review, PR review, or codebase audit touching web, mobile backend, or API code), with an explicit 'Use when' clause and enumerated triggers. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'security review', 'OWASP', 'broken access control', 'IDOR', 'BOLA', 'injection', 'broken auth', 'API review', 'authorization', 'access control'. These span both technical and common user language. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: OWASP-specific security auditing for web and API code. The specific trigger terms like 'IDOR', 'BOLA', 'broken access control' are unlikely to conflict with non-security skills, and the OWASP framing distinguishes it from general code review skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
87%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, well-structured security checklist skill that is concise, actionable, and well-organized with appropriate progressive disclosure. Its main weakness is the lack of an explicit audit workflow—it tells Claude *what* to check but not *how* to systematically conduct the review or what to do with confirmed findings beyond marking them. The always-apply rules section is an excellent touch that ensures critical checks happen on every code write.
Suggestions
Add a brief 3-5 step audit workflow (e.g., '1. Identify auth boundaries → 2. Check each endpoint against checklist → 3. Verify findings with exploit scenario → 4. Report with severity') to guide systematic review.
Include guidance on what to do after marking a 🔴 finding—e.g., how to report it, whether to block the PR, or how to suggest a fix pattern.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line earns its place. The tables are dense with actionable detection signals, no concepts are over-explained, and Claude's existing knowledge of security concepts is respected. The 'Always-Apply Rules' section is tight and specific. | 3 / 3 |
Actionability | Provides concrete detection signals (e.g., `findById(params.id)` without owner filter, `Access-Control-Allow-Origin: *`), specific code patterns to flag, a clear severity scoring system (P0 caps at 40/100), and a triage marking system (✅/⚠️/🔴). These are directly executable during code review. | 3 / 3 |
Workflow Clarity | The checklist format provides clear items to evaluate, and the triage marking system is useful. However, there's no explicit workflow sequence for conducting an audit (e.g., where to start, how to proceed through a codebase, what to do when findings are confirmed). For a security audit skill, a step-by-step process with validation checkpoints (e.g., 'after identifying findings, verify exploitability before marking P0') would strengthen this. | 2 / 3 |
Progressive Disclosure | Excellent structure: concise overview tables in the main file with clear one-level-deep references to `references/owasp-web.md` and `references/owasp-api.md` for full detection signals. The split between always-apply rules and context-specific checklist is well-organized. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
19a1140
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.