Best PromptsEdge-Case Test Generation
Generate tests from a behavior contract and boundary analysis (happy paths, edges, and error paths) instead of coverage theater.
Write tests for the code below.
Test framework + conventions: [e.g. "vitest, tests in __tests__/, describe/it style", or paste an existing test file to match]
What this code is used for: [THE REAL-WORLD JOB, so tests reflect actual usage]
Code under test:
"""
[PASTE FUNCTION/MODULE]
"""
Work in this order:
1. **Contract**: state what this code promises: valid inputs, outputs, side effects, errors it should raise, and any invariants. If the contract is ambiguous at some point (e.g. what happens on null?), note the ambiguity and test current behavior, flagged with a comment.
2. **Case table**: before writing test code, list the cases as a table: | case | input | expected | category |. Categories to cover:
- Happy paths (the 2-3 mainline uses)
- Boundaries: empty, zero, one, max, off-by-one at every limit, unicode/whitespace for strings
- Invalid inputs: wrong types, null/undefined, malformed data; asserting the ERROR behavior, not just "it throws"
- State-dependent: order of calls, repeated calls, concurrent use if the code can face it
3. **Tests**: implement the table. Name each test by the behavior it proves ("returns empty list when no items match", never "test1" or "works correctly"). One behavior per test. Arrange-act-assert visible.
Rules: test the contract, not the implementation, no asserting on private internals or call counts unless a side effect IS the contract. No tautological tests that mirror the code's own logic back at it. If you spot a case where the code's behavior looks like a bug rather than intent, write the test for the CORRECT behavior, mark it as failing, and tell me: finding that is the point of testing.How to use
The case table is the leverage: reviewing 20 table rows takes a minute, reviewing 400 lines of generated test code doesn't happen. Check the table for missing cases before letting it write code. In an agentic tool, add 'run the tests and fix failures' to close the loop.
More coding prompts
Write the commit message for this change. Diff: """ [PASTE THE STAGED DIFF] """ Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"] Convention: [Conventional Commits / this repo's existing style, pasted below / plain] Recent commits from this repo, to match style: """ [PASTE 5-10 RECENT COMMIT SUBJECT LIN
Commit Message
Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.
Help me recover from a git mistake without making it worse. What I was trying to do: [THE GOAL] What I ran: [THE EXACT COMMANDS, IN ORDER] What happened instead: [THE OUTPUT OR THE STATE NOW] Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled] Uncommitted work I cannot lose: [WHAT AND WHERE, o
Undo a Git Mistake
Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.
Handler code, routes, and models: """ [PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE] """ Generate an OpenAPI 3.1 specification from the code above. API name, version, and base URL: [DETAILS] Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced] Con
OpenAPI Spec From Code
Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.