API security testing workflow for REST and GraphQL APIs covering authentication, authorization, rate limiting, input validation, and security best practices.
51
26%
Does it follow best practices?
Impact
96%
1.10xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/api-security-testing/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description identifies a clear domain (API security testing) and lists relevant topic areas, but it reads more like a table of contents than an actionable skill description. It lacks concrete actions (what specifically does it do?) and completely omits trigger guidance (when should Claude use it?). The topic coverage provides moderate distinctiveness but would benefit from sharper specificity and explicit usage triggers.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to test API security, perform penetration testing on endpoints, check for authentication vulnerabilities, or audit REST/GraphQL APIs.'
Replace topic area listings with concrete actions, e.g., 'Tests for broken authentication and authorization flaws, validates rate limiting configurations, fuzzes API inputs for injection vulnerabilities, and checks security headers.'
Include additional natural trigger terms users might say, such as 'pen test', 'vulnerability scan', 'OWASP', 'JWT security', 'API keys', or 'security audit'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (API security testing) and lists several areas covered (authentication, authorization, rate limiting, input validation, security best practices), but these read more as topic areas than concrete actions. It doesn't specify what actions are performed, like 'tests for broken authentication' or 'fuzzes input parameters'. | 2 / 3 |
Completeness | Describes what the skill covers at a high level but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and since the 'what' is also somewhat vague (topic areas rather than concrete actions), this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'REST', 'GraphQL', 'API', 'authentication', 'authorization', 'rate limiting', and 'input validation' which users might naturally mention. However, it misses common variations like 'OWASP', 'pen test', 'vulnerability scan', 'API keys', 'JWT', 'tokens', or 'security audit'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'API security testing' with 'REST and GraphQL' provides some distinctiveness, but it could overlap with general API testing skills, security auditing skills, or input validation skills. The broad mention of 'security best practices' increases conflict risk. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
20%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a shallow orchestration document that delegates all real work to other skills without providing any concrete testing methodology, commands, or examples. The repetitive phase structure inflates the document significantly while each phase contains only vague action items like 'Test JWT tokens' that provide no actionable guidance. The workflow sequencing is reasonable but lacks validation checkpoints and error recovery steps that are critical for security testing workflows.
Suggestions
Add concrete, executable examples for each phase—e.g., actual curl commands for testing JWT validation, specific GraphQL introspection queries, or rate limit testing scripts.
Replace vague action lists ('Test SQL injection') with specific techniques, payloads, or tool commands that Claude can directly execute.
Add validation checkpoints between phases—e.g., 'Before proceeding to Phase 3, confirm all authentication endpoints are documented and auth bypass attempts are logged.'
Condense the repetitive phase structure significantly—the current format repeats 'Skills to Invoke / Actions / Copy-Paste Prompts' seven times with minimal unique content in each.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose and repetitive structure. Each phase follows an identical template with vague action lists that add no real value. The 'Copy-Paste Prompts' sections are trivially simple one-liners that don't provide meaningful guidance. Much of the content is padding—numbered lists like 'Test SQL injection, Test NoSQL injection, Test command injection' tell Claude nothing it doesn't already know. | 1 / 3 |
Actionability | No concrete code, commands, or executable examples anywhere. Every action item is vague ('Test JWT tokens', 'Test rate limit headers') with no specifics on how to actually perform these tests. The 'Copy-Paste Prompts' are just 'Use @skill-name to do X' which is not actionable guidance—it delegates entirely to other skills without providing any concrete testing methodology. | 1 / 3 |
Workflow Clarity | The phases are clearly sequenced and the overall flow from discovery through authentication, authorization, input validation, rate limiting, GraphQL, and error handling is logical. However, there are no validation checkpoints between phases, no feedback loops for when tests fail, and no guidance on how to handle findings before proceeding to the next phase. The quality gates at the end are too generic to serve as real validation. | 2 / 3 |
Progressive Disclosure | References to other skills are present and clearly signaled, which is good. However, the main file itself is a monolithic wall of repetitive content that could be significantly condensed. The references are all one-level deep which is appropriate, but the inline content is so thin and repetitive that it doesn't justify the length—it should either be condensed into a compact overview or have meaningful content added. | 2 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
7241463
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.