All kits

Software Engineering

Write, review and ship code

free

For engineers. Pair programming, review, migration and the unglamorous work AI is genuinely good at.

Prompts & skills 3 included

prompt
Review for correctness, not style

Finds the bug that fires on the third Tuesday, not the missing semicolon.
```
Review this diff for correctness only. Ignore formatting and naming.

Look specifically for:
- Boundary conditions: empty, one, many, maximum.
- Error paths that swallow failure or leave partial state.
- Concurrency: shared mutable state, ordering assumptions.
- Resource lifetime: connections, file handles, locks.
- Data assumptions the types do not enforce.

For each finding give: the failing input or sequence, what happens, and why the code permits it. If you cannot describe a concrete failure, it is not a finding — leave it out.

Diff:
{{diff}}
```
Review this diff for correctness only. Ignore formatting and naming. Look specifically for: - Boundary conditions: empty, one, many, maximum. - Error paths that swallow failure or leave partial state. - Concurrency: shared mutable state, ordering assumptions. - Resource lifetime: connections, file handles, locks. - Data assumptions the types do not enforce. For each finding give: the failing input or sequence, what happens, and why the code permits it. If you cannot describe a concrete failure, it is not a finding — leave it out. Diff: {{diff}}
prompt
Migration planner

Turns a large refactor into ordered, individually shippable steps.
```
Plan this migration as a sequence of independently shippable steps.

Constraints:
- Every step leaves the system working and deployable.
- No step requires a coordinated release of two components.
- Each step is reversible, or you state plainly that it is not and why.

For each step: what changes, how to verify it worked, and how to roll back.
Call out the point of no return explicitly.

Current state: {{current}}
Target state: {{target}}
```
Plan this migration as a sequence of independently shippable steps. Constraints: - Every step leaves the system working and deployable. - No step requires a coordinated release of two components. - Each step is reversible, or you state plainly that it is not and why. For each step: what changes, how to verify it worked, and how to roll back. Call out the point of no return explicitly. Current state: {{current}} Target state: {{target}}
guide
Prompting for code that compiles

Giving enough context without pasting the whole repository.
```
Getting usable code depends almost entirely on context. In order of value:

1. THE SIGNATURES it must fit — types, interfaces, the function it will be called from. More valuable than prose.
2. ONE REAL EXAMPLE of surrounding code, so conventions are matched rather than guessed.
3. THE VERSIONS — language, framework, library majors. Most broken output is code for a different version.
4. WHAT IT MUST NOT DO — no new dependencies, no blocking the event loop, no schema change.
5. THE FAILING TEST, if there is one. A test is an unambiguous specification.

Do not paste the whole repository. Irrelevant context reliably degrades output.
```
Getting usable code depends almost entirely on context. In order of value: 1. THE SIGNATURES it must fit — types, interfaces, the function it will be called from. More valuable than prose. 2. ONE REAL EXAMPLE of surrounding code, so conventions are matched rather than guessed. 3. THE VERSIONS — language, framework, library majors. Most broken output is code for a different version. 4. WHAT IT MUST NOT DO — no new dependencies, no blocking the event loop, no schema change. 5. THE FAILING TEST, if there is one. A test is an unambiguous specification. Do not paste the whole repository. Irrelevant context reliably degrades output.

Tools in this kit

The tool list is always free to read — and so are these prompts.