Add New Features With Claude Code Without Breaking What Already Works

Check the Current Version

Open the current project and test only the behavior that matters for this change.

Open the current website or web app

Confirm the page or feature you plan to change works

Check the most important related flow

Note anything that is already broken

If something is already broken before the new change, stop. Fix it first as its own task instead of mixing a bug fix and a new feature.

Fix a Bug in Your AI-Built Website or Web App With Claude Code

Use this first if the current project is already broken.

/video/fix-a-bug-in-your-ai-built-website-or-web-app-with-claude-code

Keep the Working Version Recoverable

Before editing, make sure you can get back to the version that works now. Your project may also contain unfinished work — the prompts below tell Claude to keep it, and never to discard, reset, commit or push anything.

Describe the Change

Open Customize Prompt, fill in the three fields, then copy the prompt into Claude Code.

Plan the Change Safely

Tell Claude what you want to change, what must keep working, and what success should look like before it edits anything.

I want to make one change to this existing project. The project currently works. Change I want: {{CHANGE_GOAL}} Existing behavior that must keep working: {{MUST_KEEP_WORKING}} Successful result: {{EXPECTED_RESULT}} Do NOT edit any files yet. First inspect the current project. The goal is to understand the smallest safe change before implementation. 1. INSPECT THE CURRENT STATE Find: - where the requested behavior currently lives - the components/files directly involved - shared components used by that area - existing state and data flow - existing routes involved - backend, API or database dependencies, if relevant - authentication or authorization dependencies, if relevant - environment variables or secrets involved, if relevant (names only) - existing tests or validation commands relevant to this area Do not scan or rewrite unrelated parts of the project unnecessarily. 2. IDENTIFY WHAT THE CHANGE CAN AFFECT Trace only the important nearby dependencies. Look for existing behavior that could realistically regress if this change is implemented incorrectly — for example another login method, an existing form submission, navigation, database reads/writes, account state, a shared component used by another page, mobile layout, loading/error states, or server/client boundaries. Do not create a giant theoretical risk list. Focus on real dependencies in this project. 3. CHECK THE CURRENT WORKTREE If Git is available, inspect the current status and diff, and tell me whether unrelated uncommitted work already exists. Do not discard it. Do not reset it. Do not commit it. Do not push it. Never use destructive commands such as: git reset --hard git checkout . git restore . git clean -fd or any equivalent broad destructive operation. The change must coexist safely with my current work. 4. DEFINE THE CHANGE BOUNDARY Tell me: - FILES EXPECTED TO CHANGE — only files likely required for this change - FILES / AREAS THAT SHOULD REMAIN UNCHANGED — nearby working areas that do not need modification - IMPORTANT EXISTING FLOWS TO RECHECK — only the most relevant existing behavior that could be affected 5. CHOOSE THE SMALLEST IMPLEMENTATION Prefer the smallest implementation that fits the project's existing architecture. Do not: - redesign unrelated UI - refactor working code just because it could look cleaner - rename unrelated files or functions - update unrelated packages - replace existing libraries - rewrite a complete feature to add one capability - change database schemas unless required - change auth behavior unless required - add abstractions with no immediate purpose - perform "cleanup while we're here" If a dependency upgrade is genuinely required, explain exactly why before including it in the plan. 6. USE CURRENT PROJECT PATTERNS Reuse the existing components, styling, state patterns, API patterns, database patterns, auth patterns and error/loading states where appropriate. Do not introduce a second architecture for the same job. OUTPUT Return: 1. Current implementation relevant to this change 2. Smallest recommended implementation 3. Files expected to change 4. Areas that should remain untouched 5. Existing behavior that could realistically regress 6. How we should test the new feature 7. How we should re-test the existing behavior afterward 8. Any blocker or ambiguity that must be resolved first Do not edit anything yet.

What do you want to add or change?

Add Google login, add a search bar, change the dashboard, connect a new API...

What already works and must not break?

Email login, project creation, dashboard navigation, contact form...

How should the new change work when finished?

Users can sign in with Google and existing email login still works...

Review the plan before continuing. If Claude proposes unrelated refactoring or cleanup, remove it from the plan before making the change.

Approve the Change Boundary

Continue only when the plan passes these checks.

The requested change is clearly defined

The files expected to change make sense

Important existing behavior is listed

No unrelated redesign or cleanup is included

There is a clear way to test the new behavior

Create the Regression Checklist

Ask Claude for a few checks you will repeat after the change.

Create the Before-and-After Checks

Turn the plan into a small checklist that proves the important existing behavior still works after the change.

Using the approved change plan, create a focused regression checklist for this specific change. Do not modify the project yet. CHECKLIST RULES - Include only behavior that could realistically be affected by this change. - Aim for about 3–6 important checks. Do not create a large QA checklist. - Every check must be something I can observe myself, for example: 1. Email login works 2. Creating a project works 3. Dashboard navigation works We will repeat exactly the same checks after the change. EXISTING AUTOMATED TESTS Check whether the project already has relevant automated tests or checks. If useful focused tests already exist, identify the smallest relevant test file or command. If no suitable tests exist, do NOT install Playwright, Cypress, Vitest, Jest or any other test framework for this change. Use focused manual checks instead. This change is not a testing-infrastructure project. BASELINE Where possible, run the smallest existing validation or check relevant to the affected area BEFORE editing, and record whether it currently passes. Do not run a broad test suite unless it is genuinely this project's established lightweight workflow. If one of the regression checks already fails before editing, STOP. Report it as pre-existing, and do not later blame the new change for that failure. OUTPUT Return a section titled REGRESSION CHECKLIST with the exact checks we will repeat after implementation. Also report: - any relevant existing focused automated check - any pre-existing failure - whether the current baseline is ready for the change Do not edit product code yet.

Make sure the important checks pass now. You will repeat the same checks after Claude makes the change.

Add the Change

Let Claude implement only the plan you approved.

Implement Only the Approved Change

Apply the approved change without refactoring or modifying unrelated working behavior.

Implement the change using the plan and change boundary we already approved. Do not start over. Do not broaden the task. IMPLEMENTATION RULES Make only the changes necessary for the approved result, and reuse established project patterns. Preserve: - unrelated pages and components - working authentication - working database behavior - existing API behavior - existing responsive behavior - existing styles outside the requested area - any unrelated uncommitted work that was already in the project Do not: - refactor unrelated code - rename unrelated functions or files - perform cleanup outside the approved area - rewrite a working feature unnecessarily - upgrade unrelated dependencies or change package versions just because newer ones exist - delete unrelated code - change environment-variable names unless necessary - modify database access rules unless the feature requires it - expose secrets or hardcode private credentials - use destructive Git commands such as git reset --hard, git checkout ., git restore . or git clean -fd - commit, push or deploy IF SOMETHING UNEXPECTED APPEARS If implementation shows the approved plan was materially wrong, STOP. Do not improvise a much larger rewrite. Explain: - what you discovered - why the original plan is no longer sufficient - what additional change would be required Wait for my approval before broadening the scope. AFTER EDITING Run only the smallest validation directly relevant to the change. Do not perform unrelated cleanup after the feature works. Report: 1. Files changed 2. What changed in each file 3. Any file changed that was NOT in the approved boundary, and why 4. Focused validation performed 5. Any issue still unresolved Do not declare the work finished yet — the next step verifies both the new behavior and the existing behavior.

Test the Change

Try it yourself, using the result you described in Step 2.

Perform the new action

Confirm it matches the result you described

Refresh or reopen the page

Repeat the new action once more

Check the existing flow closest to the change

Verify Nothing Else Broke

Verify the Change and Check for Regressions

Re-test the approved regression checklist and inspect the final diff before declaring the change finished.

The new change has now been implemented. Perform the final focused verification. Do not add new features. Do not clean up unrelated code. 1. TEST THE NEW BEHAVIOR Verify the exact expected result we defined at the beginning. Report PASS or FAIL with concise evidence. 2. REPEAT THE REGRESSION CHECKLIST Run or review the SAME important checks we recorded before implementation. Do not silently replace them with different tests. For each check, report BEFORE, AFTER and RESULT. If a behavior that passed before now fails, that is a regression — do not declare success. Identify which change caused it, fix only that regression while keeping the requested feature, then repeat the affected check. 3. RUN RELEVANT EXISTING FOCUSED CHECKS If the project already has a relevant type check, focused test, lint/check command or validation, run only the useful subset. Do not broaden into a large suite without a reason. 4. INSPECT THE FINAL DIFF Review all edits made for this task and check for: - files changed outside the approved scope - unrelated formatting churn - accidental deletions - duplicate implementations - temporary or debug code - console/debug logs added only for diagnosis - unnecessary dependency changes - environment-variable changes - comments or placeholders left from implementation A large diff is not automatically wrong. Decide whether every changed area is actually needed for the requested change. 5. PRESERVE PRE-EXISTING WORK If unrelated uncommitted changes existed before this task, do not alter or remove them. Clearly separate PRE-EXISTING CHANGES from CHANGES MADE FOR THIS FEATURE. Do not use broad Git reset or restore operations. 6. FINAL VERDICT Return exactly one: CHANGE VERIFIED or NEEDS ATTENTION Use CHANGE VERIFIED only if: - the requested new behavior works - every important regression check that passed before still passes - no unrelated accidental edits remain - no temporary or debug code remains Then summarize: - Feature or change added - Files changed for this task - New behavior result - Existing behavior result - Any remaining issue Do not propose additional improvements after verification succeeds.

Use the app yourself one last time: try the new feature, then repeat the most important existing flow. If both work, the change is ready for your normal review.