Software prompts

TASK: Implement [feature] in [repository/module].

STACK: [language + version], [framework], [package manager], [test runner].
RELEVANT FILES: [paths — read these before writing code]
EXISTING PATTERN TO FOLLOW: [file that shows the convention]

BEHAVIOUR
- [Requirement 1, phrased as observable behaviour]
- [Requirement 2]
- Edge cases: [empty input], [permission denied], [network timeout]

CONSTRAINTS
- No new dependencies without asking first.
- Do not change the public API of [module].
- Match existing error-handling and logging conventions.
- Keep functions under [n] lines; no clever one-liners.

ACCEPTANCE CRITERIA
1. [Checkable statement]
2. [Checkable statement]
3. Existing tests still pass.

VERIFY WITH: `[build command]`, `[lint command]`, `[test command]`

OUT OF SCOPE: [files/areas to leave untouched]

Plan first, list the files you will change, then implement.

Help me find the root cause of this bug. Do not suggest fixes until you have named the cause.

EXPECTED: [what should happen]
ACTUAL: [what happens]
REPRODUCTION: [exact steps, including inputs and environment]
FREQUENCY: [always / intermittent — how often]
WHEN IT STARTED: [after which change or version, if known]

ERROR OUTPUT:
"""
[paste full stack trace / logs]
"""

RELEVANT CODE:
"""
[paste the smallest code that includes the failure path]
"""

ALREADY RULED OUT: [what you have checked and why it is not the cause]

DELIVER
1. Most likely root cause, with the reasoning and the specific line.
2. Two alternative hypotheses, and a cheap way to test each.
3. The minimal fix, plus a regression test that fails before it and passes after.

Review this change as a senior [language] engineer on the team that owns it.

CONTEXT: [what the change is meant to do]
CONVENTIONS: [link or summary of the team's style rules]
RISK AREAS: [auth / data migration / concurrency / anything user-facing]

REVIEW FOR, IN THIS ORDER
1. Correctness — logic errors, off-by-one, unhandled null, race conditions.
2. Security — input validation, injection, secret handling, authorisation gaps.
3. Failure behaviour — what happens on timeout, partial write, or retry.
4. Performance — obvious N+1 queries, unbounded loops, unnecessary allocations.
5. Maintainability — naming, duplication, missing tests.
6. Style — last, and clearly labelled as optional.

FORMAT: for each finding give severity (blocking / should-fix / nit), file and line, why it matters, and a suggested change. Skip praise. If a section has no findings, say "none".

DIFF:
"""
[paste diff]
"""

Write tests for the code below using [test framework] and the conventions in [example test file].

WHAT THIS CODE IS RESPONSIBLE FOR: [one or two sentences]
CURRENT COVERAGE GAPS: [what is untested, if known]

COVER
- Happy path with typical input.
- Boundaries: empty, single item, maximum size, zero, negative.
- Invalid input and the exact errors expected.
- External failures: [timeout], [500 response], [malformed payload] — mocked, not live.
- Idempotency / repeated calls, if relevant.

RULES
- One behaviour per test, named so a failure explains itself.
- Arrange-act-assert, no shared mutable state between tests.
- No assertions on implementation details or private methods.
- No snapshot tests for logic.
- Deterministic: fix time and randomness.

CODE:
"""
[paste code]
"""

List anything untestable as written, with the smallest refactor that would fix it.

Refactor [file/module] with zero behaviour change.

WHY: [the specific pain — e.g. this function is 400 lines and untestable]
DEFINITION OF DONE: same inputs produce same outputs, all existing tests pass unchanged.

DO
- Extract [x] into [y] following the pattern in [reference file].
- Keep the public interface identical.
- Preserve existing error messages and log lines verbatim.
- Work in small steps, and after each step tell me what to run to verify.

DO NOT
- Rename public methods or change signatures.
- Add dependencies, change formatting wholesale, or touch unrelated files.
- "Improve" behaviour you think is a bug — list it separately instead.

DELIVER
1. Step plan with the order of changes.
2. The refactored code, step by step.
3. A list of behaviours you noticed that look wrong but were left alone.

CODE:
"""
[paste code]
"""

Write the project rules file an AI coding agent should read before every task.

PROJECT: [name] — [one-line purpose]
STACK: [languages, frameworks, versions]
STRUCTURE: [top-level directories and what belongs in each]

COMMANDS
- Install: `[cmd]`
- Dev: `[cmd]`
- Build: `[cmd]`
- Test: `[cmd]`  (single test: `[cmd]`)
- Lint / format: `[cmd]`

CONVENTIONS
- [Naming, file layout, error handling, logging]
- [State management / data access pattern]
- [Testing philosophy: what must have tests]

GUARDRAILS
- Never edit [generated files / migrations already applied / vendored code].
- Never commit secrets; config comes from [source].
- Ask before adding a dependency or changing a schema.
- Always run build and tests before reporting a task complete.

Output as a concise Markdown file, imperative voice, no filler sections.