API Test Case Generation

Problem: API test context gets lost

API testing is not just about assertions. It often involves endpoint parameters, auth, external dependencies, regenerating a TypeScript client, timeouts, idempotency, and error-code mapping. After a passing run, it is easy to forget whether a failure was environmental, whether the contract changed, or whether a new test case is needed. Docs, chat notes, and terminal output scatter across places, so regression testing often starts from scratch.

How it works: turn test signals into trackable records

The skill maintains .learnings/ at the project or workspace root and writes API-test-related failures, corrections, and missing capabilities to ERRORS.md, LEARNINGS.md, and FEATURE_REQUESTS.md. It emphasizes reproduction steps, external-tool integration details, priority, and area tags such as backend, tests, and config. When an API issue recurs, it asks you to search existing entries first, link similar records with See Also, and bump priority. When a lesson is broadly applicable, it can be distilled into short rules and promoted to CLAUDE.md, AGENTS.md, or .github/copilot-instructions.md, becoming reusable project memory.

Boundaries: a test-memory layer

This skill does not replace HTTP clients or test frameworks, and it should not be treated as an automatic complete test-suite generator. It is better suited to preserving API-test context: converting failures, API behavior differences, coverage gaps, and recurring patterns into structured notes that can inform later test-case work. If the team wants sharing, .learnings/ can be tracked in the repo; if sensitive output is a concern, keep it local and redacted, avoiding tokens, private keys, and full environment variables.