DEV Community: alfie.ecom

Claude Code Wasn’t Breaking My Projects. My Workflow Was.

alfie.ecom — Sat, 01 Aug 2026 13:56:31 +0000

Claude Code can write code quickly.

That is useful until it starts moving faster than it understands your project.

I kept running into the same problems:

Small requests touched unrelated files
Existing logic was rebuilt instead of reused
Bug fixes created different bugs
Claude changed the scope halfway through
Tasks were marked complete without testing the real user flow

The issue was not simply “bad prompts.”

My entire workflow started too late.

I was asking Claude to build before making it inspect, define boundaries and agree on what success looked like.

A quick disclosure

I created The Claude Code Toolkit, a paid collection containing 260 prompts and systems, 15 CLAUDE.md templates, 10 development workflows and 100 curated Claude Code skills.

It costs £3.99:

The Claude Code Builder Kit

Stop fighting Claude Code. Start building with it.You know what you want to build.Claude just keeps guessing wrong, breaking things and making you repeat yourself.This toolkit fixes that.You get 260 structured prompts that give Claude the exact context it actually needs:• What to build• What not to touch• How to test the result• When the task is actually completeWhat’s Inside• 260 prompts for websites, app development, SaaS features and debugging• 15 professional CLAUDE.md templates• 10 complete development workflows• 100 curated Claude Code skills• Beginner quick start guideHere’s one prompt from the toolkitThat’s one of 50 website building prompts included. The full version goes from planning all the way through implementation and testing.How It WorksPick a prompt.Customise it for your project.Paste it into Claude.Get clearer, more structured results.It takes around 30-90 seconds to customise and works with Claude Code, ChatGPT, Gemini and other AI coding tools.Get Instant Access£3.99. One payment. Lifetime access. Instant delivery.You’ll receive a PDF containing access to the full organised toolkit in Google Docs.It works on desktop, tablet and mobile.Stop rewriting the same instructions for every project.Just build.

alfiestips.gumroad.com

The complete pre-flight prompt below is free to copy. It is not a shortened preview.

The pre-flight check I run before important changes

Before Claude edits anything, I make it answer five questions:

What does the current system do?
Which files are actually relevant?
What must remain untouched?
What is the smallest safe change?
How will the result be verified?

That sounds basic, but it prevents a lot of unnecessary work.

Here is the full prompt.

Act as a senior software engineer preparing to make a controlled change inside an existing codebase.

TASK

[DESCRIBE THE FEATURE, FIX OR UPDATE]

EXPECTED RESULT

[DESCRIBE EXACTLY WHAT THE USER SHOULD BE ABLE TO DO]

PROTECTED FUNCTIONALITY

[LIST FEATURES, PAGES, FILES, DATA OR INTEGRATIONS THAT MUST REMAIN UNCHANGED]

KNOWN PROJECT CONTEXT

Project purpose:
[DESCRIBE THE APPLICATION]

Tech stack:
[LIST THE STACK OR WRITE UNKNOWN]

Relevant files:
[LIST THEM OR WRITE UNKNOWN]

Recent changes:
[LIST RELEVANT CHANGES OR WRITE NONE]

Known errors:
[PASTE ERRORS OR WRITE NONE]

Do not edit any code yet.

First, inspect the existing project and perform a pre-flight review.

Your review must include:

Trace the current user flow connected to this task.
Identify the components, routes, services, APIs, database logic and state involved.
Find existing patterns, utilities and components that should be reused.
Identify every file likely to be modified.
Explain why each file may need to change.
Identify functionality that could be affected indirectly.
List unclear requirements or missing information.
Identify security, permission, validation and data-integrity risks.
Recommend the smallest safe implementation.
Create a testing plan for the complete user flow.

Respond using these sections:

CURRENT BEHAVIOUR

Explain how the relevant functionality currently works.

TASK UNDERSTANDING

Restate the requested result in your own words.

RELEVANT FILES

List the files involved and explain what each one controls.

EXISTING PATTERNS TO REUSE

Identify components, services, utilities and conventions that should be preserved.

RISKS

Explain possible regressions, edge cases and security concerns.

SMALLEST SAFE CHANGE

Recommend the minimum implementation required to deliver the requested result.

APPROVED SCOPE

List every file and area you expect to modify.

PROTECTED AREAS

List everything that must remain untouched.

IMPLEMENTATION PLAN

Provide a step-by-step plan.

TESTING PLAN

Explain how you will test:

The complete successful flow
Invalid and missing input
Failed requests
Loading, empty and error states
Authentication and permissions
Repeated clicks or duplicate submissions
Related functionality
Browser console errors
Server logs
Protected functionality

Wait for my approval before editing any code.

After approval:

Stay inside the approved scope.
Follow the existing architecture.
Reuse existing project patterns.
Do not perform unrelated refactoring.
Do not change unrelated styling.
Do not add dependencies without approval.
Stop and ask before modifying an unapproved file.
Preserve existing user data, permissions and integrations.

After implementation:

List every file created or modified.
Explain the exact changes made.
Compare the result against the approved plan.
Test the complete user flow.
Test related protected functionality.
Report failed tests.
List anything that could not be verified.

Do not claim completion because the code compiles or the page loads.

The task is complete only when the intended user flow has been tested and protected functionality still works.

ENJOY!

5 Claude Code Prompts That Stop Small Changes From Breaking Your Project

alfie.ecom — Sat, 01 Aug 2026 10:21:17 +0000

_Claude Code can build quickly, but speed becomes a problem when it starts making decisions before it understands the project.

A small request can suddenly become:

Unrelated files being edited
Working features breaking
Existing logic being duplicated
New dependencies being added
Claude claiming completion without testing the actual flow

I stopped asking Claude to immediately build or fix things.

Now I make it follow this order:

Understand → Scope → Investigate → Build → Verify

Below are five complete prompts you can copy into Claude Code.

Quick disclosure: I created a larger paid Claude Code Toolkit containing 260 prompts and systems, 15 CLAUDE.md templates, 10 complete workflows and 100 curated skills. The five prompts in this post are complete and free to use.

Understand the Project Before Changing Anything

Use this before adding an important feature or fixing something inside an existing codebase.

Act as a senior software engineer joining an existing project.

Before writing or editing any code, inspect the project and explain how it currently works.

Current task:

[DESCRIBE WHAT YOU WANT TO BUILD OR FIX]

Protected functionality:

[LIST FEATURES, PAGES, DATA OR INTEGRATIONS THAT MUST NOT CHANGE]

Review:

The folder and file structure.
Application entry points.
Frontend and backend architecture.
Database models and relationships.
API routes and external services.
Authentication and permissions.
State management.
Shared components and utilities.
Existing features related to the task.
Tests and project documentation.

Then provide:

PROJECT SUMMARY

Explain what the application currently does.

RELEVANT FILES

List the files connected to the requested task and explain what each one controls.

EXISTING PATTERNS

Identify components, utilities and conventions that should be reused.

RISKS

Explain what could break if the task is implemented incorrectly.

MISSING CONTEXT

List anything you cannot confirm from the project.

Do not edit any files yet.

Do not invent missing information.

Wait for me to confirm your understanding before creating an implementation plan.

This catches misunderstandings before they turn into code.

Lock the Scope Before Coding

Use this when Claude has a habit of turning a small task into a larger rewrite.

Create an implementation contract for the following task.

Requested change:

[DESCRIBE THE FEATURE, FIX OR UPDATE]

Expected user experience:

[DESCRIBE WHAT THE USER SHOULD SEE AND DO]

Protected functionality:

[LIST EVERYTHING THAT MUST REMAIN UNCHANGED]

Do not edit any code yet.

The contract must include:

Your exact understanding of the request.
The current user flow.
The proposed user flow.
Every file expected to change.
Why each file needs to change.
Any new files required.
Existing components and utilities that should be reused.
Validation, loading, success and error states.
Authentication or permission requirements.
Possible regressions.
The smallest safe implementation.
A step-by-step plan.
A testing plan.
A rollback plan.

Create two explicit sections:

APPROVED SCOPE

List every file and area you will be allowed to modify.

OUT OF SCOPE

List unrelated refactors, styling changes and improvements that will not be included.

Wait for my approval before editing any code.

After approval, stop and ask before touching any file outside the approved scope.

This gives you something concrete to compare against after the work is finished.

Investigate a Bug With Evidence

Use this before letting Claude make changes based on its first guess.

Act as a staff software engineer investigating a bug.

Bug:

[DESCRIBE THE PROBLEM]

Expected behaviour:

[WHAT SHOULD HAPPEN]

Actual behaviour:

[WHAT CURRENTLY HAPPENS]

Reproduction steps:

[LIST THE STEPS OR WRITE UNKNOWN]

Error messages:

[PASTE ERRORS OR WRITE NONE]

Recent changes:

[LIST RELEVANT CHANGES OR WRITE UNKNOWN]

Do not edit any code yet.

Trace the complete flow from the user action to the final result.

Inspect every relevant layer:

Interface
State
Validation
API request
Authentication
Backend logic
Database operations
External services
Response handling
Error handling

Create a ranked list of possible root causes.

For every hypothesis, include:

Why it could explain the bug
Evidence supporting it
Evidence against it
Exact files or functions involved
How the hypothesis can be verified
What result would confirm it
What result would reject it

Do not change code until the root cause has been verified.

Once verified, recommend the smallest safe fix and explain how the original bug and related features will be tested.

The goal is to make Claude prove the cause instead of producing a confident-looking guess.

Build the Feature in Controlled Checkpoints

Use this for larger tasks that would be risky to complete in one pass.

Implement the following approved task in controlled checkpoints.

Approved task:

[DESCRIBE THE TASK]

Expected result:

[DESCRIBE THE FINAL USER EXPERIENCE]

Approved files:

[LIST THE FILES CLAUDE MAY MODIFY]

Protected functionality:

[LIST EVERYTHING THAT MUST REMAIN UNCHANGED]

Do not implement the entire task at once.

Divide the work into the smallest practical checkpoints.

For every checkpoint, provide:

Objective
Files to modify
Files to create
Protected functionality
Expected result
Testing plan
Rollback plan

Wait for approval before beginning Checkpoint 1.

During each checkpoint:

Work only on the current checkpoint.
Do not begin later work.
Do not edit unapproved files.
Do not perform unrelated refactoring.
Reuse existing project patterns.
Do not add dependencies without approval.
Preserve unrelated styling and functionality.

After each checkpoint, report:

Files changed
Exact changes made
Tests completed
Tests passed
Tests failed
Protected functionality checked
Anything still unverified

Then stop and wait for approval before continuing.

This makes it much easier to catch a bad decision before it spreads through the project.

Verify the User Flow Before Claiming Completion

Use this after implementation.

Act as a senior quality engineer verifying a recently completed change.

Original request:

[PASTE THE ORIGINAL TASK]

Expected user experience:

[DESCRIBE THE COMPLETE USER FLOW]

Acceptance criteria:

[LIST THE RESULTS THAT MUST BE TRUE]

Protected functionality:

[LIST FEATURES THAT MUST STILL WORK]

Do not assume the implementation is correct.

Do not treat compilation, a successful build or a loading page as proof of completion.

Test:

The complete successful flow.
Invalid input.
Missing data.
Failed requests.
Loading states.
Empty states.
Error states.
Repeated clicks.
Duplicate submissions.
Refresh behaviour.
Direct URL access.
Authentication and permissions.
Mobile layouts.
Browser console errors.
Server logs.
Related features that share modified logic.
Every protected flow.

Then provide:

IMPLEMENTATION VERDICT

Choose one:

Verified complete
Complete with unverified areas
Partially complete
Not complete
Regression detected

TESTING EVIDENCE

State exactly what was tested and what happened.

FAILED TESTS

Include reproduction steps, expected behaviour and actual behaviour.

UNVERIFIED AREAS

List anything that could not be checked.

REQUIRED FOLLOW-UP

List any remaining work.

Do not describe the task as complete unless the evidence supports that conclusion.

Claude saying “done” and the feature actually working are not the same result.

The Workflow

The system is simple:

Understand the project

Lock the scope

Investigate with evidence

Build in checkpoints

Verify the full flow

Claude Code is still fast.

The difference is that it now moves inside clear boundaries instead of improvising across the entire project.

For anyone looking for the full organised system, I created The Claude Code Toolkit.

It includes:

260 prompts and systems
15 professional CLAUDE.md templates
10 complete development workflows
100 curated Claude Code skills
A beginner quick-start guide

The toolkit costs £3.99 with instant access:

The Claude Code Builder Kit

Stop fighting Claude Code. Start building with it.You know what you want to build.Claude just keeps guessing wrong, breaking things and making you repeat yourself.This toolkit fixes that.You get 260 structured prompts that give Claude the exact context it actually needs:• What to build• What not to touch• How to test the result• When the task is actually completeWhat’s Inside• 260 prompts for websites, app development, SaaS features and debugging• 15 professional CLAUDE.md templates• 10 complete development workflows• 100 curated Claude Code skills• Beginner quick start guideHere’s one prompt from the toolkitThis prompt makes Claude plan before coding: sitemap, visitor journey, visual direction, trust signals, files, accessibility, testing, and more. It stops Claude from jumping straight into a generic website and hoping for the best.That’s one of 50 website-building prompts included. The full version goes from planning all the way through implementation and testing.How It WorksPick a prompt.Customise it for your project.Paste it into Claude.Get clearer, more structured results.It takes around 30-90 seconds to customise and works with Claude Code, ChatGPT, Gemini and other AI coding tools.Get Instant Access£3.99. One payment. Lifetime access. Instant delivery.You’ll receive a PDF containing access to the full organised toolkit in Google Docs.It works on desktop, tablet and mobile.Stop rewriting the same instructions for every project.Just build.

alfiestips.gumroad.com