Prompt libraryCoding
Explain, review, debug and test code, with constraints that avoid invented APIs.
Coding prompts need versions, the failing behavior and the smallest example that shows it. Models guess when context is missing, and a guess that compiles can still be wrong.
Run the code and the tests yourself. A second model reviewing the first model's change is a useful extra check, not a replacement for running it.
Language/version: [..]. This function should [expected behavior] but [actual behavior]. Code:
[code]
Failing input: [input]. Explain the cause in two sentences, then give the fix and two tests, one for the failing case and one for an edge case. If you are unsure an API exists in this version, say so.Why it works. The "say so" line discourages invented functions.
Then check. Run the tests; confirm the API in the official docs.
Explain what this code does, line by line at a high level, then list its inputs, outputs, side effects and anything that looks risky.
[code]Why it works. Structured explanation exposes side effects.
Then check. Read the code yourself for the risky parts.
Review the code below as a skeptical senior engineer. List bugs, security issues (injection, auth, secrets, unsafe input), missing edge cases, and performance traps, ordered by severity. Do not rewrite it.
[code]Why it works. A review role finds issues the author model missed.
Then check. Triage each finding; many will be false alarms.
I want to refactor [module] to [goal]. Give a step-by-step plan where each step leaves the tests passing, and note the riskiest step. Do not write code yet.Why it works. Small safe steps beat a big rewrite.
Then check. Adjust to your real test coverage.
Write unit tests for the function below covering normal cases, boundaries, invalid input and one property that should always hold. Use [test framework].
[code]Why it works. Tests encode the behavior you expect.
Then check. Make sure tests fail when the code is wrong.
Schema:
[schema]
Write a query for [goal]. Explain each clause, say how it would behave with NULLs and duplicates, and suggest an index if it is slow. Dialect: [dialect].Why it works. NULLs and duplicates are common silent errors.
Then check. Run it on a copy of the data.
Write a regular expression for [pattern] in [language]. Give 5 strings that should match and 5 that should not, and explain each part.Why it works. Examples reveal mistakes faster than reading the pattern.
Then check. Test the examples in a regex tool.