i came up with an idea i can make a guide showing people how to conserve they're claude code tokens while still getting as good performance is this something you guys would pay for??? if so how much?
ive been heavily promoting this product i made (a claude code toolkit) but i think prompts are a bit in the past people need full guides from how to go from problem to fixed. so whats something you guys would easily pay alright money for (9.99 or more) or am i thinking wrong again? lmk in the replies i NEED help
If Claude or ChatGPT keeps giving you vague answers, try structuring your prompt like this:
1. ROLE
Tell it who it should act as.
“You are a senior TypeScript developer who writes clean, production-ready code.”
2. CONTEXT
Explain what you’re working on, your tech stack, the problem and any limits.
“I’m building a Next.js dashboard. The login page works, but users aren’t redirected after signing in. I’m using Supabase Auth and TypeScript.”
3. OBJECTIVE
Say exactly what you want it to do and how you want the answer returned.
“Find the likely cause, explain it simply, then give me the corrected code. Don’t rewrite unrelated files.”
So instead of:
“Fix my login”
Try:
Role: You are a senior Next.js developer.
Context: I’m using Supabase Auth with TypeScript. Login succeeds, but the user stays on the login page.
Objective: Identify the problem, explain it briefly and provide the smallest possible code change to fix it.
It takes an extra minute to write, but normally saves way more time going back and forth.
I’m not going to link it here, but if you want a full Claude Code Toolkit, check the link in my profile.
If Claude or ChatGPT keeps giving you vague answers, try structuring your prompt like this:
1. ROLE
Tell it who it should act as.
“You are a senior TypeScript developer who writes clean, production-ready code.”
2. CONTEXT
Explain what you’re working on, your tech stack, the problem and any limits.
“I’m building a Next.js dashboard. The login page works, but users aren’t redirected after signing in. I’m using Supabase Auth and TypeScript.”
3. OBJECTIVE
Say exactly what you want it to do and how you want the answer returned.
“Find the likely cause, explain it simply, then give me the corrected code. Don’t rewrite unrelated files.”
So instead of:
“Fix my login”
Try:
Role: You are a senior Next.js developer.
Context: I’m using Supabase Auth with TypeScript. Login succeeds, but the user stays on the login page.
Objective: Identify the problem, explain it briefly and provide the smallest possible code change to fix it.
It takes an extra minute to write, but normally saves way more time going back and forth.
I’m not going to link it here, but if you want a full Claude Code Toolkit, check the link in my profile.
There is a point in almost every AI-built project where making changes stops feeling safe.
The app still runs, but the structure has started drifting.
Claude duplicates logic that already exists, follows outdated patterns, edits files outside the task and fixes one flow while quietly breaking another.
At that point, giving it another feature request usually makes the project worse.
I now use one recovery workflow that forces Claude to reconstruct the project, identify the drift, define a safe repair plan, work in checkpoints and verify everything before claiming completion.
Quick disclosure: I created a larger Claude Code Toolkit around this system. For anyone looking to improve how they use Claude Code, it is linked in my profile.
The complete recovery workflow below is free to copy.
Replace anything inside [brackets] with your own project details.
Act as a senior software engineer taking responsibility for an existing project that has become difficult to understand, modify or trust.
Your goal is not to immediately add another feature.
Your goal is to recover control of the project before further development continues.
PROJECT INFORMATION
Original project goal:
[DESCRIBE WHAT THE PROJECT WAS SUPPOSED TO DO]
Target users:
[DESCRIBE THE INTENDED USERS]
Current tech stack:
[LIST THE STACK OR WRITE UNKNOWN]
Current problems:
[DESCRIBE WHAT FEELS BROKEN, MESSY, INCONSISTENT OR RISKY]
Recent changes:
[DESCRIBE RECENT FEATURES, FIXES OR REFACTORS]
Last known stable state:
[DESCRIBE WHEN THE PROJECT LAST FELT RELIABLE OR WRITE UNKNOWN]
Protected functionality:
[LIST FEATURES, PAGES, FLOWS, DATA OR INTEGRATIONS THAT MUST NOT BREAK]
Current priority:
[DESCRIBE WHAT YOU NEED TO BUILD OR FIX NEXT]
GENERAL RULES
Do not edit, delete, rename, move or create files until the investigation and recovery plan have been approved.
Do not assume the documentation is correct.
Do not assume the newest code is the intended code.
Do not assume that similar-looking components serve the same purpose.
Do not recommend a full rewrite simply because the project is messy.
Do not replace working architecture with your preferred architecture unless the current approach prevents a safe recovery.
Base every conclusion on evidence from the project.
When evidence is incomplete, label the conclusion as uncertain and explain what is missing.
Complete this recovery process in five stages.
Stop after every stage and wait for my approval before continuing.
==================================================
STAGE 1: RECONSTRUCT THE PROJECT
Inspect the complete project before proposing any changes.
Review:
1. The folder and file structure.
2. Application entry points.
3. Frontend architecture.
4. Backend architecture.
5. Database models, queries and relationships.
6. API routes.
7. Authentication and authorisation.
8. State management.
9. Shared components.
10. Shared utilities and services.
11. Third-party integrations.
12. Environment variables and configuration.
13. Validation.
14. Error handling.
15. Loading, empty, success and failure states.
16. Existing tests.
17. README files.
18. CLAUDE.md files.
19. Comments describing architectural decisions.
20. Recent commits or change history when available.
21. Dead, duplicated or abandoned code.
22. Features that appear partially implemented.
23. Features that bypass established project patterns.
24. Code paths that are no longer reachable.
25. Files that appear to serve overlapping responsibilities.
Create the following output:
PROJECT PURPOSE
Explain what the application currently does based on the code, not only the documentation.
ARCHITECTURE MAP
Describe how the frontend, backend, database, APIs, state and external services connect.
CORE USER FLOWS
Trace the most important user journeys from the initial action to the final result.
SOURCE-OF-TRUTH MAP
For each important type of data or behaviour, identify the file, service or system that currently acts as the source of truth.
RELEVANT FILES
List the most important files and explain what responsibility each one currently holds.
PATTERN MAP
Identify the main conventions used for components, routes, services, data access, error handling and styling.
UNCERTAINTIES
List anything that cannot be confirmed from the available project files.
Do not continue to Stage 2 until I approve your understanding of the project.
==================================================
STAGE 2: DETECT PROJECT DRIFT
Compare the original project goal with the current implementation.
Identify where the project has drifted through:
- Duplicate logic
- Conflicting sources of truth
- Inconsistent architecture
- Partially replaced systems
- Outdated documentation
- Unused dependencies
- Abandoned features
- Repeated components
- Contradictory validation rules
- Client-side checks without server enforcement
- Inconsistent permissions
- Old and new API patterns existing together
- Multiple approaches to state management
- Features that bypass shared utilities
- Tests that validate outdated behaviour
- Error handling that differs between similar flows
- Temporary workarounds that became permanent
- Features that work alone but fail when connected
- Styling systems that conflict
- Database fields that no longer match product behaviour
- Environment variables that are unused, duplicated or unclear
Create a DRIFT LEDGER.
For every issue, include:
ISSUE
Describe the inconsistency or drift.
LOCATION
List the exact files, functions, routes, components or services involved.
EVIDENCE
Explain what in the project proves the issue exists.
LIKELY INTENTION
Explain what the original or intended behaviour appears to be.
CURRENT BEHAVIOUR
Explain what the project currently does instead.
USER IMPACT
Explain how users could be affected.
TECHNICAL IMPACT
Explain how the issue affects maintenance, reliability or future development.
CONFIDENCE
Label the conclusion as:
- Confirmed
- Strongly supported
- Possible
- Unknown
SEVERITY
Classify it as:
- Critical
- High
- Medium
- Low
RECOMMENDED ACTION
Choose one:
- Keep
- Remove
- Consolidate
- Repair
- Document
- Investigate further
Do not make any changes.
At the end, provide:
1. The five most dangerous forms of drift.
2. The areas that are currently safe.
3. The areas that should not receive new features yet.
4. The information still needed from me.
5. The smallest recovery target that would make future development safer.
Wait for my approval before continuing.
==================================================
STAGE 3: CREATE THE RECOVERY CONTRACT
Using the approved findings, create a recovery contract.
The contract must define exactly what will be repaired and what will remain untouched.
Include:
RECOVERY OBJECTIVE
Describe the specific result this recovery should produce.
IN SCOPE
List every problem included in the recovery.
OUT OF SCOPE
List everything that will not be addressed during this recovery.
PROTECTED FUNCTIONALITY
List the pages, features, data, integrations and user flows that must continue working.
APPROVED FILES
List every existing file expected to change.
NEW FILES
List every file expected to be created.
FILES THAT MUST NOT CHANGE
List sensitive or unrelated files that should remain untouched.
SOURCE-OF-TRUTH DECISIONS
For every conflicting system, state which implementation should become the official source of truth and explain why.
REMOVAL DECISIONS
List dead, duplicated or outdated code that should be removed.
MIGRATION REQUIREMENTS
Explain whether existing users, data, settings or sessions need to be migrated.
REGRESSION RISKS
List what could break during the recovery.
ROLLBACK PLAN
Explain how the project can return to its current state if the recovery fails.
ACCEPTANCE CRITERIA
Define observable conditions that must be true before the recovery can be considered successful.
TESTING REQUIREMENTS
List the exact flows, errors, permissions, devices and integrations that must be tested.
Do not use vague acceptance criteria such as:
- Works correctly
- Looks good
- Is production-ready
- Has no bugs
Every acceptance criterion must be observable and testable.
Wait for my approval before implementation.
==================================================
STAGE 4: RECOVER THE PROJECT IN CHECKPOINTS
Divide the approved recovery into the smallest practical checkpoints.
Each checkpoint must leave the project in a reviewable and testable state.
Before each checkpoint, report:
CHECKPOINT OBJECTIVE
Explain the single result this checkpoint should achieve.
FILES TO MODIFY
List the approved files that will change.
FILES TO CREATE
List any approved files that will be added.
FILES TO REMOVE
List any approved files that will be deleted.
PROTECTED FLOWS
List the functionality that must remain unchanged.
EXPECTED RESULT
Describe what should be visibly or technically different after this checkpoint.
TEST PLAN
Explain how the checkpoint will be verified.
ROLLBACK PLAN
Explain how this checkpoint can be reversed.
During implementation:
- Work only on the current checkpoint.
- Do not begin later checkpoints.
- Do not edit files outside the approved contract.
- Do not perform unrelated refactoring.
- Do not add dependencies without approval.
- Reuse existing project patterns where they remain valid.
- Remove duplicated logic only when the official source of truth has been approved.
- Preserve user data.
- Preserve authentication and permissions.
- Preserve unrelated styling.
- Stop when unexpected architecture or dependencies are discovered.
- Ask for approval before expanding the scope.
After each checkpoint, report:
1. Files created.
2. Files modified.
3. Files removed.
4. Exact changes made.
5. Differences from the approved plan.
6. Tests completed.
7. Tests passed.
8. Tests failed.
9. Protected flows checked.
10. Console errors discovered.
11. Server errors discovered.
12. Database issues discovered.
13. Anything still unverified.
14. Whether rollback is recommended.
Stop after every checkpoint.
Do not continue until I approve the completed checkpoint.
==================================================
STAGE 5: VERIFY THE RECOVERED PROJECT
After all checkpoints are approved, perform a final recovery verification.
Compare the final project against:
- The original project goal
- The approved recovery contract
- The acceptance criteria
- The protected functionality
- The core user flows
Test:
1. The complete successful user journey.
2. Invalid input.
3. Missing data.
4. Incomplete data.
5. Failed network requests.
6. Expired sessions.
7. Unauthorised access.
8. Different user roles.
9. Repeated clicks.
10. Duplicate submissions.
11. Refresh behaviour.
12. Direct URL access.
13. Back and forward navigation.
14. Loading states.
15. Empty states.
16. Error states.
17. Mobile layouts.
18. Narrow-screen layouts.
19. Keyboard navigation.
20. Browser console output.
21. Server logs.
22. Database writes.
23. Database reads.
24. Third-party integrations.
25. Every protected flow listed in the recovery contract.
Then provide:
RECOVERY SUMMARY
Explain what was repaired.
FINAL ARCHITECTURE
Describe how the recovered project is now structured.
OFFICIAL SOURCES OF TRUTH
List the systems, files or services that now control each important responsibility.
REMOVED DRIFT
List the duplicate, abandoned or conflicting implementations that were removed.
TESTING EVIDENCE
State exactly what was tested and the result.
UNVERIFIED AREAS
List anything that could not be tested.
REMAINING RISKS
List issues that still exist but were outside the approved scope.
DOCUMENTATION UPDATES
List any README, CLAUDE.md or technical documentation that should now be updated.
NEXT SAFE TASK
Recommend the next feature or repair that can be completed without destabilising the recovered project.
Do not describe the project as fully fixed, production-ready or bug-free unless the evidence supports that statement.
Do not claim completion because the project compiles or the homepage loads.
The recovery is complete only when the approved acceptance criteria and protected user flows have been verified.
This is different from asking Claude to “clean up the codebase.”
That kind of instruction gives it permission to make broad, subjective changes.
This workflow forces it to prove what the project currently does, show where the drift happened and agree on a recovery contract before touching anything.
The five stages are:
Reconstruct → Detect → Contract → Recover → Verify
It takes longer than sending one vague cleanup request.
It is still much faster than spending another night repairing an AI-generated “fix” that changed half the project.
For anyone looking to improve how they use Claude Code, the full toolkit is linked in my profile.
I kept making the same mistake with Claude Code.
I would open a project, explain the next feature in one or two sentences, then let it start editing immediately.
The result looked productive at first. Files changed, components appeared, and Claude confidently explained what it had built.
Then I tested it.
It had misunderstood the project structure, recreated logic that already existed, changed files that did not need touching, and ignored decisions made earlier in the build.
The problem was not that Claude could not code.
It was coding before it had enough context.
i organised the wider workflow into a paid Claude Code toolkit, but both prompts below are complete and free to use. but if you're interested you can grab the full kit from the link in my profile description, anyway enjoy these prompts!
These are the two prompts I now use before letting it make important changes.
Replace anything inside [brackets] with your own details.
Use this when opening an existing project, returning after a long break, or starting a new conversation where Claude has little context.
Act as a senior software engineer taking responsibility for an existing codebase.
Your first task is to understand the project accurately.
Do not write, edit, delete or move any code yet.
Project purpose:
[DESCRIBE WHAT THE PROJECT DOES]
Target users:
[DESCRIBE THE USERS]
Current task:
[DESCRIBE WHAT YOU PLAN TO BUILD OR FIX NEXT]
Before suggesting an implementation, inspect the project and build a complete project map.
Review:
1. The folder and file structure.
2. The main application entry points.
3. The current architecture.
4. The primary user flows.
5. Shared components and utilities.
6. State management.
7. API routes and external services.
8. Authentication and authorisation.
9. Database models, queries and relationships.
10. Environment variables and configuration.
11. Error handling.
12. Loading, empty, success and failure states.
13. Existing tests.
14. Project documentation.
15. Any CLAUDE.md, README or instruction files.
16. Naming conventions and code patterns.
17. Existing features related to the current task.
18. Functionality that could be affected by the requested change.
Then respond using these sections:
Project Summary
Explain what the application does and how its main parts connect.
Architecture Map
Describe the frontend, backend, database, APIs, state and external services.
Main User Flows
Explain the most important user journeys from beginning to end.
Relevant Files
List the files most relevant to the current task and explain what each one does.
Existing Patterns
Identify the conventions, components and utilities that should be reused.
Important Decisions
List architectural or product decisions that appear to have already been made.
Risks
Explain what could break if the current task is implemented incorrectly.
Missing Context
List anything you still need from me before planning the work.
Do not invent missing information.
Do not recommend rebuilding the project simply because another architecture may be cleaner.
Do not begin implementation until I confirm that your understanding of the project is correct.
This gives Claude a chance to understand what already exists before it starts adding more code.
It also makes misunderstandings visible while they are still easy to correct.
Once Claude understands the project, I use this before the actual implementation.
You now understand the existing project.
Your next task is to plan the following change:
[DESCRIBE THE FEATURE, FIX OR UPDATE]
Expected user experience:
[DESCRIBE WHAT THE USER SHOULD SEE AND DO]
Functionality that must remain unchanged:
[LIST PROTECTED FEATURES, PAGES, COMPONENTS OR INTEGRATIONS]
Do not edit any code yet.
Create an implementation contract for this task.
The contract must include:
1. Your exact understanding of the requested change.
2. Any requirements that are unclear or incomplete.
3. The current user flow affected by this task.
4. The proposed user flow after implementation.
5. Every file you expect to modify.
6. Why each file needs to change.
7. Any new files you expect to create.
8. Existing components, utilities or services that should be reused.
9. Database changes, if required.
10. API changes, if required.
11. Authentication or permission changes, if required.
12. Loading, empty, validation, success and error states.
13. Mobile and accessibility considerations.
14. Security or privacy concerns.
15. Possible regressions.
16. The smallest safe implementation.
17. A step-by-step implementation plan.
18. A testing plan.
19. Anything you cannot verify.
For every file you plan to modify, explain:
- What will change
- Why it must change
- What must remain untouched
- What could break
- How the change will be tested
Wait for my approval before editing any code.
After approval:
- Follow the approved plan.
- Keep changes strictly within the agreed scope.
- Preserve unrelated functionality and styling.
- Do not perform unrelated refactoring.
- Do not add dependencies unless necessary.
- Stop and ask before changing any file not included in the contract.
- Reuse existing project patterns wherever possible.
After implementation:
1. Compare the final changes against the original contract.
2. Report every file created or modified.
3. Explain any changes that were not originally planned.
4. Test the complete user flow.
5. Test invalid input and failed requests.
6. Test related functionality that could have been affected.
7. Check the browser console and server logs.
8. Confirm that protected functionality still works.
9. State exactly what was tested.
10. Clearly list anything that remains unverified.
Do not claim completion because the code compiles or the page loads.
The task is only complete when the intended user flow has been tested.
The first prompt rebuilds context.
The second turns that context into a controlled implementation plan.
Since using them, I catch far more problems before Claude touches the code instead of discovering them after it has changed half the project.
The basic rule is simple:
Understand the project first. Plan the exact change second. Code third.
I eventually organised the wider workflow into a paid Claude Code toolkit, but both prompts above are complete and free to use. but if you're interested you can grab the full kit from the link in my bio, Enjoy these prompts!
Claude Code used to agree with my request, start coding immediately, then quietly change things I never asked it to touch.
So I started making it write a small “change contract” before implementation.
The idea is simple.
Before Claude edits anything, it has to explain:
This is the prompt I use:
Before making any code changes, create a change contract for this task.
Task:
[DESCRIBE THE TASK]
Your change contract must include:
1. Your understanding of the task.
2. The exact files you expect to modify.
3. Why each file needs to change.
4. Any new files you expect to create.
5. Functionality that must remain untouched.
6. Assumptions you are making.
7. Possible regressions or side effects.
8. The smallest safe implementation.
9. How you will test the result.
10. Anything you cannot verify.
Do not edit code yet.
Wait for my approval after presenting the change contract.
Once approved, follow the contract strictly.
If you later discover that additional files or changes are required, stop and explain why before continuing.
After implementation, compare the final work against the original contract and report:
- Files changed
- Unexpected changes
- Tests completed
- Tests that failed
- Anything still unverified
This has helped most when working on older projects where one feature is connected to several other parts of the app.
It also makes bad assumptions obvious before they become actual code.
I’ve started using the same approach for features, bug fixes and launch reviews.
I organised the wider system into a paid Claude Code toolkit if you're interested the links in my profile, but the full workflow above is free to use. enjoy!
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.
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.
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
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!
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.
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.
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.
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 it here but if you want more claude prompts like this theres a link in my profile description it costs 3.99 and you get full access to the whole system.
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.
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.
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.
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
I kept running into the same problem with Claude Code.
I would ask it to fix one small issue, it would change several files, rewrite working logic, and somehow create a completely new bug.
The problem was that I was telling it what to fix, but not giving it clear boundaries.
This is the prompt I use now:
>
This has been much more reliable than simply saying “fix this bug.”
The biggest improvement came from forcing Claude to investigate first, define the scope, and prove the fix before touching unrelated code.
I ended up organising the rest of my Claude Code prompts and workflows into a toolkit because I was tired of rewriting the same instructions every project.
Not dropping a sales link here, but it’s on my profile description for anyone who genuinely needs it.