DEV Community

Zac
Zac

Posted on

Prompt templates worth saving for everyday dev work

Most AI prompts get used once and discarded. A few are worth keeping. Here are the ones I reach for constantly.

Code review prompt

Review this code for:
1. Logic errors — anything that will break in production
2. Security issues — injection, auth bypass, credential exposure
3. Missing error handling — null references, unhandled rejections, missing validations
4. Performance — N+1 queries, unbounded loops, unnecessary work
5. Scope drift — anything changed beyond what the stated task required

For each finding: severity (blocker/warning/suggestion), line reference, specific fix.
Do not comment on style unless it affects correctness.
Enter fullscreen mode Exit fullscreen mode

Debugging prompt

I'm seeing: [exact error message]
Where: [file and line number]
When: [what action triggers it]
Expected: [what should happen]
Actual: [what happens]

Do not guess. Read the relevant files first, then explain the root cause. Propose one specific fix.
Enter fullscreen mode Exit fullscreen mode

Refactoring prompt

Refactor [function/file] to [specific goal].
Constraints:
- Do not change the public interface (function signatures, exported types)
- Do not add new functionality
- Do not modify tests
- All existing tests must pass after the change
Show me the diff before applying it.
Enter fullscreen mode Exit fullscreen mode

Feature planning prompt

I want to add [feature] to [system].
Before writing any code:
1. What files will need to change?
2. What existing patterns should this follow?
3. Are there any existing utilities I should reuse?
4. What could go wrong?
5. What should I test?
Then wait for my go-ahead before making changes.
Enter fullscreen mode Exit fullscreen mode

Documentation prompt

Write documentation for [function/module/API].
Audience: [developer unfamiliar with this codebase]
Include:
- What it does (one sentence)
- Parameters: name, type, what it represents, constraints
- Return value: type, meaning, edge cases
- Example usage
- What can go wrong
Do not include anything a reader could infer from the type signatures alone.
Enter fullscreen mode Exit fullscreen mode

Test writing prompt

Write tests for [function].
Write failing tests first — show me they fail before writing implementation.
Cover:
1. Happy path
2. Empty/null inputs
3. Boundary values
4. Error cases
5. One case a caller is likely to get wrong
Do not mock unless mocking an external dependency (network, DB, filesystem).
Enter fullscreen mode Exit fullscreen mode

The common element

All of these have explicit scope, explicit constraints, and ask for a specific output format. That's what makes them reusable: they're not tailored to one situation, they're structured to produce consistent results across situations.

Save the ones that work for you. Delete the rest.

More on prompts and CLAUDE.md patterns: builtbyzac.com/claudemd-templates.html.

Top comments (0)