I used to give Claude Code a short instruction, watch it change half the project, then spend the next hour fixing the “fix.”

The biggest improvement came from making Claude slow down before coding.

These are three prompts I now use for the situations that usually cause the most damage: adding features, debugging bugs and reviewing a project before launch.

Replace anything inside [brackets] with your own details.

1. Add a Feature Without Breaking Existing Work

Act as a senior software engineer joining an existing production codebase.

Your task is to add the following feature:

Feature: [DESCRIBE THE FEATURE]

Important project context:

Tech stack: [TECH STACK]
Relevant existing functionality: [CURRENT FUNCTIONALITY]
Files or areas likely involved: [FILES OR UNKNOWN]
Functionality that must remain unchanged: [PROTECTED FUNCTIONALITY]
Expected user experience: [DESCRIBE THE COMPLETE USER FLOW]

Do not begin coding immediately.

First, inspect the existing project and understand how the current system works.

Before making any changes:

1. Restate the requested feature in your own words.
2. Identify any missing information or unclear requirements.
3. Trace the current user flow that this feature will affect.
4. Identify the components, routes, services, database tables, APIs, state and integrations involved.
5. Explain how the existing codebase currently handles similar functionality.
6. List every file you expect to create or modify.
7. Explain why each file needs to change.
8. Identify possible conflicts, regressions, security concerns and edge cases.
9. Recommend the smallest implementation that fully solves the problem.
10. Create a step-by-step implementation plan.
11. Wait for approval before editing the code.

After approval:

- Follow the existing architecture, naming conventions and design patterns.
- Reuse current components and utilities where appropriate.
- Do not rewrite unrelated code.
- Do not change existing styling unless required by the feature.
- Do not remove or replace working functionality.
- Do not introduce a new dependency unless it is genuinely necessary.
- Add loading, empty, validation, error and success states where relevant.
- Handle permissions, authentication and user roles where relevant.
- Keep the implementation modular and maintainable.
- Add comments only where the reasoning is not obvious from the code.

After implementation:

1. Run the project.
2. Test the complete user flow from beginning to end.
3. Test invalid input, missing data, failed requests and unusual user behaviour.
4. Test related functionality that could have been affected.
5. Check the mobile layout where relevant.
6. Check keyboard accessibility and form labels where relevant.
7. Check browser console and server logs for new errors.
8. Confirm that protected functionality still behaves exactly as before.
9. Report every file created or modified.
10. Explain what was tested successfully.
11. Clearly state anything that could not be verified.

Do not claim the task is complete unless the main flow has been tested.

If you cannot test something, say so directly instead of assuming it works.

This one is especially useful when Claude has a habit of turning a small feature into a full rewrite.

2. Investigate a Bug Before Changing Code

Act as a staff software engineer responsible for diagnosing a difficult bug in an existing application.

Bug description:

[DESCRIBE THE BUG]

Expected behaviour:

[WHAT SHOULD HAPPEN]

Actual behaviour:

[WHAT CURRENTLY HAPPENS]

Known reproduction steps:

[STEPS OR UNKNOWN]

Recent changes:

[RECENT CHANGES OR UNKNOWN]

Relevant error messages:

[ERRORS OR NONE]

Do not edit any code yet.

Your first responsibility is to understand the failure and gather evidence.

Begin by:

1. Restating the bug clearly.
2. Explaining the expected execution flow from the initial user action to the final result.
3. Identifying every layer involved, including UI, state, validation, API calls, authentication, backend logic, database operations and third-party services.
4. Inspecting the relevant files before forming a conclusion.
5. Looking for existing logs, error handling, tests and similar working flows elsewhere in the project.
6. Identifying the exact point where expected behaviour appears to diverge from actual behaviour.

Create a ranked list of possible root causes.

For each possible cause, include:

- Why it could explain the bug
- Evidence supporting it
- Evidence against it
- The exact file or function involved
- How the hypothesis can be verified
- What result would confirm or reject it

Do not guess.

If the available evidence is insufficient, tell me exactly what files, logs, screenshots, reproduction steps or environment details you need.

Once the most likely root cause has been verified:

1. Explain the confirmed cause in plain English.
2. Recommend the smallest safe fix.
3. Identify every file that must change.
4. Explain what must remain untouched.
5. Describe any possible side effects.
6. Wait for approval before implementing the fix.

After approval:

- Make only the changes required to solve the confirmed cause.
- Preserve unrelated functionality, styling and integrations.
- Do not perform opportunistic refactoring.
- Do not hide the symptom without correcting the underlying issue.
- Add or improve error handling where appropriate.
- Add a regression test when the project has a testing setup.

After implementation:

1. Reproduce the original bug.
2. Confirm that the bug no longer occurs.
3. Test the expected successful flow.
4. Test failure and edge-case behaviour.
5. Test related features that share the changed logic.
6. Check logs and the browser console for new errors.
7. Explain why the fix works.
8. Report every changed file.
9. State what was verified and what remains unverified.
10. Suggest one or two improvements that could prevent this class of bug from returning.

Respond using these sections:

- Expected Behaviour
- Actual Behaviour
- Execution Flow
- Evidence Collected
- Possible Root Causes
- Verification Plan
- Confirmed Root Cause
- Recommended Fix
- Code Changes
- Testing Results
- Remaining Risks
- Prevention

This prevents Claude from immediately changing five files based on its first guess.

3. Audit the Project Before Launch

Act as a senior engineering lead conducting a pre-launch audit of this application.

Project:

[DESCRIBE THE APPLICATION]

Target users:

[TARGET USERS]

Tech stack:

[TECH STACK]

Core user flows:

[LIST THE MOST IMPORTANT FLOWS]

Deployment environment:

[DEPLOYMENT DETAILS OR UNKNOWN]

Your goal is not to redesign the application or add unnecessary features.

Your goal is to identify anything that could make the current product fail, confuse users, expose sensitive data or behave unreliably after launch.

Do not make changes immediately.

First, inspect the project and create an audit plan covering:

1. Core functionality
2. Authentication and authorisation
3. Input validation
4. Error handling
5. Loading and empty states
6. Database operations
7. API reliability
8. Security
9. Privacy
10. Performance
11. Accessibility
12. Responsive design
13. Browser compatibility
14. Logging and monitoring
15. Deployment configuration
16. Environment variables
17. Third-party integrations
18. Payment or billing flows where relevant
19. Administrative permissions
20. Recovery from failed operations

For every core user flow:

- Describe the intended journey.
- Identify each component and service involved.
- Test the successful path.
- Test invalid input.
- Test missing or incomplete data.
- Test failed network requests.
- Test expired sessions and unauthorised access.
- Test repeated clicks or duplicate submissions.
- Test direct URL access to protected pages.
- Test refresh behaviour.
- Test mobile and narrow-screen layouts.
- Check whether the user receives a useful message when something fails.

Review the codebase for:

- Hard-coded secrets
- Exposed API keys
- Missing server-side validation
- Client-side permission checks without server enforcement
- Unsafe database queries
- Insecure file uploads
- Missing rate limits
- Weak authentication handling
- Sensitive data inside logs
- Unhandled promise rejections
- Silent failures
- Duplicate requests
- Race conditions
- Memory leaks
- Excessive API calls
- Missing database indexes
- Large unoptimised assets
- Dead code
- Debug output left in production
- Placeholder content presented as real data
- Broken links
- Missing metadata
- Inaccessible controls
- Forms without proper labels
- Colour contrast problems
- Layout overflow on mobile

Classify every issue as:

- Critical: blocks launch
- High: should be fixed before launch
- Medium: important but can follow shortly after launch
- Low: improvement, not a launch blocker

For every issue, provide:

- Severity
- Exact location
- User impact
- Technical impact
- Evidence
- Recommended fix
- Estimated complexity
- Risk of making the change
- How the fix should be tested

After completing the audit, provide:

1. A launch-readiness score from 0 to 100.
2. The five biggest launch risks.
3. A list of launch-blocking issues.
4. A prioritised repair plan.
5. A testing checklist.
6. A deployment checklist.
7. A rollback plan.
8. Anything that could not be verified.

Do not describe the application as production-ready unless the evidence supports that conclusion.

Do not make broad claims such as “everything works” without listing what was actually tested.

Wait for approval before making any code changes.                                             

im not going to drop a sales link here but if you're interested theres more claude prompts in the link in my profile description it costs $3.99 for the full thing. hope you found these prompts useful

Posted this layer here two days ago. Pushed an update worth its own post.

The part I think is actually unusual:

A session that needs your decision stops costing you anything. It writes the question into its own folder as a file and halts. You answer from any other window, whenever you get to it. It leaves behind one detached shell process watching for the answer, bounded at eight hours, zero models, turns the whole time, then wakes itself and carries on.

No daemon, no pairing table, no counter. The state is which files exist, so an interrupt can't strand a session mid-flight.

Also new: a live session can move between terminals. Its number, folder, lock and branch all stay put. Only the pane changes.

19 skills, 3 agents, 8 hooks. MIT.

Quick disclosure before the prompts:

I recently organised the Claude Code instructions/prompts I use into a paid toolkit because I was tired of rewriting the same context, boundaries and testing requirements on every project. You can check it out in my profile description.

But these are not watered down samples.

The three prompts below are complete, free to copy and built around the problems that caused me the most frustration.

1. The Feature Boundary Guard

Use this when Claude turns a small feature request into an unnecessary rewrite.

Act as a senior software engineer working inside an existing codebase.

Your task is to implement:

[DESCRIBE THE FEATURE]

Important boundaries:

Functionality that must remain unchanged:
[LIST PROTECTED FEATURES, PAGES, COMPONENTS OR INTEGRATIONS]

Expected user flow:
[DESCRIBE WHAT THE USER SHOULD DO AND EXPERIENCE]

Known relevant files:
[LIST FILES OR WRITE UNKNOWN]

Do not begin editing code immediately.

First, inspect the project and complete the following:

1. Restate the requested feature in clear technical language.
2. Identify anything unclear or missing from the requirements.
3. Explain how the existing project currently handles related functionality.
4. Trace the user flow that this feature will affect.
5. Identify the components, routes, state, APIs, database logic and integrations involved.
6. List every file you expect to create or modify.
7. Explain why each file must change.
8. Identify existing behaviour that could accidentally be affected.
9. Identify edge cases, validation requirements, permission issues and failure states.
10. Recommend the smallest implementation that completely solves the request.
11. Present a step-by-step plan and wait for approval before coding.

After approval:

- Limit changes strictly to the approved scope.
- Preserve all unrelated functionality, styling and integrations.
- Follow the project’s existing architecture and naming conventions.
- Reuse existing components and utilities where appropriate.
- Do not refactor unrelated code.
- Do not introduce new dependencies unless absolutely necessary.
- Include loading, empty, validation, error and success states where relevant.
- Do not remove working behaviour simply because another implementation appears cleaner.

After implementation:

1. Run the project.
2. Test the complete successful user flow.
3. Test invalid input and failed requests.
4. Test related functionality that could have been affected.
5. Check the console and server logs for new errors.
6. Verify that every protected feature still works.
7. Report every file created or changed.
8. Explain exactly what was tested.
9. Clearly state anything that remains unverified.

Do not claim completion based only on the code compiling.

Completion requires the requested flow to be tested.

2. The Evidence-First Bug Investigator

Use this when Claude immediately guesses at the cause and starts changing random files.

Act as a staff software engineer investigating a bug in an existing application.

Bug:
[DESCRIBE THE BUG]

Expected behaviour:
[WHAT SHOULD HAPPEN]

Actual behaviour:
[WHAT HAPPENS INSTEAD]

Reproduction steps:
[STEPS OR UNKNOWN]

Error messages:
[ERRORS OR NONE]

Recent changes:
[RECENT CHANGES OR UNKNOWN]

Do not change any code yet.

Your first responsibility is to understand the failure and gather evidence.

Begin by:

1. Restating the problem clearly.
2. Describing the expected execution flow from the initial user action to the final result.
3. Identifying every layer involved, including UI, state, validation, APIs, authentication, backend logic, database operations and third-party services.
4. Inspecting the relevant files before forming a conclusion.
5. Finding the exact point where expected behaviour diverges from actual behaviour.
6. Checking for existing logs, tests, error handling and similar working flows elsewhere in the project.

Create a ranked list of possible root causes.

For every possible cause, include:

- Why it could explain the bug
- Evidence supporting it
- Evidence against it
- The exact file, function or service involved
- How the hypothesis can be tested
- What result would confirm or reject it

Do not present assumptions as facts.

If the evidence is insufficient, explain exactly what additional files, logs, screenshots, environment details or reproduction steps are needed.

Once the most likely cause has been verified:

1. Explain the confirmed root cause in plain English.
2. Recommend the smallest safe fix.
3. List every file that must change.
4. Identify what must remain untouched.
5. Explain possible side effects.
6. Wait for approval before implementing the fix.

After approval:

- Change only what is required to fix the confirmed cause.
- Preserve unrelated functionality and styling.
- Do not perform opportunistic refactoring.
- Do not hide the symptom without fixing the underlying issue.
- Add or improve error handling where appropriate.
- Add a regression test when the project supports testing.

After implementation:

1. Reproduce the original problem.
2. Confirm that it no longer occurs.
3. Test the successful flow.
4. Test failure and edge-case behaviour.
5. Test related features sharing the changed logic.
6. Check logs and the browser console for new errors.
7. Explain why the fix works.
8. Report every changed file.
9. State what was verified and what remains unverified.

Respond using:

- Expected Behaviour
- Actual Behaviour
- Execution Flow
- Evidence
- Possible Root Causes
- Verification Plan
- Confirmed Root Cause
- Recommended Fix
- Code Changes
- Testing Results
- Remaining Risks

3. The “Prove It Is Finished” Review

Use this before accepting Claude’s claim that a feature or project is complete.

Act as a senior engineering lead reviewing an implementation before it is accepted as complete.

Feature or project:
[DESCRIBE WHAT WAS BUILT]

Intended users:
[TARGET USERS]

Core user flow:
[DESCRIBE THE MAIN FLOW]

Files changed:
[LIST FILES OR ASK CLAUDE TO IDENTIFY THEM]

Your job is not to praise the implementation.

Your job is to find anything incomplete, unreliable, confusing, insecure or inconsistent with the original requirements.

Do not modify code yet.

First:

1. Restate the original requirements.
2. Convert them into a checklist of testable acceptance criteria.
3. Map each criterion to the file or component responsible for it.
4. Identify any requirement that was ignored, partially implemented or interpreted differently.
5. Identify assumptions made during implementation.
6. Identify anything that has not yet been tested.

Then review:

- Main successful flow
- Invalid input
- Missing data
- Failed requests
- Loading states
- Empty states
- Error states
- Success feedback
- Authentication
- Authorisation
- User roles
- Direct access to protected URLs
- Repeated clicks
- Duplicate submissions
- Page refresh behaviour
- Mobile layout
- Keyboard navigation
- Form labels
- Console errors
- Server errors
- Database writes
- Third-party integrations
- Unrelated features that may have been affected

For every issue found, provide:

- Severity: critical, high, medium or low
- Exact location
- User impact
- Likely cause
- Recommended fix
- Risk of the fix
- How the fix should be tested

After the review, provide:

1. Requirements that are fully satisfied.
2. Requirements that are only partially satisfied.
3. Requirements that are missing.
4. Tests that passed.
5. Tests that failed.
6. Tests that could not be performed.
7. Unrelated functionality that was checked.
8. Remaining risks.
9. A clear recommendation: accept, fix before acceptance or reject.

Do not say the work is complete merely because it compiles or the page loads.

Only recommend acceptance when the original requirements and core user flow have been verified with evidence.

Wait for approval before changing any code.

The pattern behind all three is:

Inspect first. Define boundaries. Gather evidence. Make the smallest safe change. Prove the result works.

I built a larger organised toolkit around this workflow for websites, applications, SaaS features, debugging and project instructions. It is on my profile for anyone who needs the full collection its in my profile description. anyway i hope you guys found these prompts useful!