api-test-suite-builder
Skill1 starsChanged 5 months agoMITView on GitHub
Use when the user asks to generate API tests, create integration test suites, test REST endpoints, or build contract tests.
6 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- darkweb19/skillsword for word, first seen Nov 8, 2026
- Hassaan146/claude-skillsword for word, first seen Jul 25, 2026
- mahiunfiltered/claude-code-skillsword for word, first seen Jul 8, 2026
- Hussain-Elfalah/Agentic-Skillsedited, first seen Jun 4, 2026
- csiddhant796-blip/claude-skills-collectionword for word, first seen May 10, 2026
- Arnav-0/claude-code-setupword for word, first seen Mar 28, 2026
Used with
Projects with it also use karpathy-coder, andreessen and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
csiddhant796-blipSkillkarpathy-coder
Use when writing, reviewing, or committing code to enforce Karpathy's 4 coding principles — surface assumptions before coding, keep it simple, make surgical changes, define verifiable goals. Triggers on "review my diff", "check complexity", "am I overcomplicating this", "karpathy check", "before I commit", or any code quality concern where the LLM might be overcoding.
Also in 5 projects that use this
Hussain-ElfalahSkillandreessen
Also in 4 projects that use this
Hussain-ElfalahSkillbusiness-investment-advisor
Also in 4 projects that use this
- +8 more from Hussain-Elfalah
Other versions6 projects use a version of this.
Word for word · 5
- Hassaan146/claude-skills★ 18100% same
- csiddhant796-blip/claude-skills-collection★ 2100% same
- mahiunfiltered/claude-code-skills★ 1100% same
- Arnav-0/claude-code-setup★ 0100% same
- darkweb19/skills★ 0100% same
Edited · 1
- Hussain-Elfalah/Agentic-Skills★ 286% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository84 other files it gives its agents.
- api-design-reviewerSkill
- ask-mattSkill
- aws-solution-architectSkill
- captureSkill
- changelog-generatorSkill
- ci-cd-pipeline-builderSkill
- cloud-securitySkill
- codebase-designSkill
- codebase-onboardingSkill
- code-reviewerSkill
- context-compressSkill
- context-modeSkill
- database-designerSkill
- database-schema-designerSkill
- dependency-auditorSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- env-secrets-managerSkill
- finish-branchSkill
- firecrawlSkill
- focused-fixSkill
- frontend-designSkill
- get-shit-doneSkill
- git-guardrails-claude-codeSkill
- git-worktree-managerSkill
- git-worktreesSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- implementSkill
- improve-codebase-architectureSkill
- incident-commanderSkill
- incident-responseSkill
- mcp-builderSkill
- memSkill
- migration-architectSkill
- monorepo-navigatorSkill
- observability-designerSkill
- performance-profilerSkill
- playwright-testingSkill
- ponytail-auditSkill
- ponytail-debtSkill
- ponytail-gainSkill
- ponytail-helpSkill
- ponytail-reviewSkill
- ponytailSkill
- prompt-engineeringSkill
- prototypeSkill
- pr-review-expertSkill
- rag-architectSkill
- red-teamSkill
- reflectSkill
- resolving-merge-conflictsSkill
- root-cause-tracingSkill
- runbook-generatorSkill
- self-evalSkill
- senior-architectSkill
- senior-backendSkill
- senior-devopsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 142
When given a codebase, follow this process:
- Very specific: line 173
Use beforeAll for shared setup, afterAll for cleanup — not beforeEach for expensive ops
- Distinctive: line 175
Test that sensitive fields (password, secret) are never in responses
- Distinctive: line 177
Add rate limit tests last — they can interfere with other test suites if run in parallel
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
API Test Suite Builder
Tier: POWERFUL Category: Engineering Domain: Testing / API Quality
Overview
Scans API route definitions across frameworks (Next.js App Router, Express, FastAPI, Django REST) and auto-generates comprehensive test suites covering auth, input validation, error codes, pagination, file uploads, and rate limiting. Outputs ready-to-run test files for Vitest+Supertest (Node) or Pytest+httpx (Python).
Core Capabilities
- Route detection — scan source files to extract all API endpoints
- Auth coverage — valid/invalid/expired tokens, missing auth header
- Input validation — missing fields, wrong types, boundary values, injection attempts
- Error code matrix — 400/401/403/404/422/500 for each route
- Pagination — first/last/empty/oversized pages
- File uploads — valid, oversized, wrong MIME type, empty
- Rate limiting — burst detection, per-user vs global limits
When to Use
- New API added — generate test scaffold before writing implementation (TDD)
- Legacy API with no tests — scan and generate baseline coverage
- API contract review — verify existing tests match current route definitions
- Pre-release regression check — ensure all routes have at least smoke tests
- Security audit prep — generate adversarial input tests
Route Detection
Next.js App Router
# Find all route handlers
find ./app/api -name "route.ts" -o -name "route.js" | sort
# Extract HTTP methods from each route file
grep -rn "export async function\|export function" app/api/**/route.ts | \
grep -oE "(GET|POST|PUT|PATCH|DELETE|HEAD|OPTIONS)" | sort -u
# Full route map
find ./app/api -name "route.ts" | while read f; do
route=$(echo $f | sed 's|./app||' | sed 's|/route.ts||')
methods=$(grep -oE "export (async )?function (GET|POST|PUT|PATCH|DELETE)" "$f" | \
grep -oE "(GET|POST|PUT|PATCH|DELETE)")
echo "$methods $route"
doneExpress
# Find all router files
find ./src -name "*.ts" -o -name "*.js" | xargs grep -l "router\.\(get\|post\|put\|delete\|patch\)" 2>/dev/null
# Extract routes with line numbers
grep -rn "router\.\(get\|post\|put\|delete\|patch\)\|app\.\(get\|post\|put\|delete\|patch\)" \
src/ --include="*.ts" | grep -oE "(get|post|put|delete|patch)\(['\"][^'\"]*['\"]"
# Generate route map
grep -rn "router\.\|app\." src/ --include="*.ts" | \
grep -oE "\.(get|post|put|delete|patch)\(['\"][^'\"]+['\"]" | \
sed "s/\.\(.*\)('\(.*\)'/\U\1 \2/"FastAPI
# Find all route decorators
grep -rn "@app\.\|@router\." . --include="*.py" | \
grep -E "@(app|router)\.(get|post|put|delete|patch)"
# Extract with path and function name
grep -rn "@\(app\|router\)\.\(get\|post\|put\|delete\|patch\)" . --include="*.py" | \
grep -oE "@(app|router)\.(get|post|put|delete|patch)\(['\"][^'\"]*['\"]"Django REST Framework
# urlpatterns extraction
grep -rn "path\|re_path\|url(" . --include="*.py" | grep "urlpatterns" -A 50 | \
grep -E "path\(['\"]" | grep -oE "['\"][^'\"]+['\"]" | head -40
# ViewSet router registration
grep -rn "router\.register\|DefaultRouter\|SimpleRouter" . --include="*.py"Test Generation Patterns
Auth Test Matrix
For every authenticated endpoint, generate:
| Test Case | Expected Status |
| No Authorization header | 401 |
| Invalid token format | 401 |
| Valid token, wrong user role | 403 |
| Expired JWT token | 401 |
| Valid token, correct role | 2xx |
| Token from deleted user | 401 |
Input Validation Matrix
For every POST/PUT/PATCH endpoint with a request body:
| Test Case | Expected Status |
Empty body {} | 400 or 422 |
| Missing required fields (one at a time) | 400 or 422 |
| Wrong type (string where int expected) | 400 or 422 |
| Boundary: value at min-1 | 400 or 422 |
| Boundary: value at min | 2xx |
| Boundary: value at max | 2xx |
| Boundary: value at max+1 | 400 or 422 |
| SQL injection in string field | 400 or 200 (sanitized) |
| XSS payload in string field | 400 or 200 (sanitized) |
| Null values for required fields | 400 or 422 |
Example Test Files
→ See references/example-test-files.md for details
Generating Tests from Route Scan
When given a codebase, follow this process:
- Scan routes using the detection commands above
- Read each route handler to understand:
- Expected request body schema
- Auth requirements (middleware, decorators)
- Return types and status codes
- Business rules (ownership, role checks)
- Generate test file per route group using the patterns above
- Name tests descriptively:
"returns 401 when token is expired"not"auth test 3" - Use factories/fixtures for test data — never hardcode IDs
- Assert response shape, not just status code
Common Pitfalls
- Testing only happy paths — 80% of bugs live in error paths; test those first
- Hardcoded test data IDs — use factories/fixtures; IDs change between environments
- Shared state between tests — always clean up in afterEach/afterAll
- Testing implementation, not behavior — test what the API returns, not how it does it
- Missing boundary tests — off-by-one errors are extremely common in pagination and limits
- Not testing token expiry — expired tokens behave differently from invalid ones
- Ignoring Content-Type — test that API rejects wrong content types (xml when json expected)
Best Practices
- One describe block per endpoint — keeps failures isolated and readable
- Seed minimal data — don't load the entire DB; create only what the test needs
- Use
beforeAllfor shared setup,afterAllfor cleanup — notbeforeEachfor expensive ops - Assert specific error messages/fields, not just status codes
- Test that sensitive fields (password, secret) are never in responses
- For auth tests, always test the "missing header" case separately from "invalid token"
- Add rate limit tests last — they can interfere with other test suites if run in parallel
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

