DEV Community: alfie.ecom

How to Get Better Claude Code Results With Structured Prompts, CLAUDE.md Templates and Workflows

alfie.ecom — Mon, 03 Aug 2026 13:21:51 +0000

How to Get Better Claude Code Results With Structured Prompts, CLAUDE.md Templates and Workflows

Claude Code can write impressive amounts of code.

That does not always mean it understands what you are trying to build.

You might begin with a simple instruction:

Build me a website.

Or:

Add authentication to this app.

Or the classic:

Fix this error.

Claude will usually produce something.

The problem is that “something” may not match the project you had in mind. The feature could be incomplete, working files might be changed unnecessarily or the visible error might disappear without the underlying problem being solved.

I experienced this repeatedly.

I knew what I wanted to build, but I was not giving Claude enough information to build it properly.

The turning point came when I stopped searching for one magical prompt and started using a complete process:

Plan → Build → Debug → Ship

That process became The Claude Code Toolkit, a library containing 260 structured prompts, CLAUDE.md templates, development workflows, debugging systems and curated skills.

You can view the complete toolkit here:

https://alfiestips.gumroad.com/l/xydfaa

But first, let’s look at why structure makes such a difference when working with AI coding tools.

One-Line Prompts Leave Too Much Room for Guessing

Imagine asking a human developer to “build a SaaS dashboard.”

They would immediately have questions:

Who will use it?
What information should it display?
Where does the data come from?
Which framework is being used?
Does authentication already exist?
What should happen when there is no data?
What should happen when an API request fails?
Which parts of the existing project must remain unchanged?
How will we know the feature is complete?

Claude needs answers to those questions too.

When they are missing, it has to fill the gaps with assumptions.

Sometimes those assumptions are reasonable.

Sometimes they lead the project in the wrong direction.

A useful coding prompt should contain at least five things:

The goal
The project context
The constraints
The required output
The definition of done

That does not mean every prompt needs to be thousands of words long.

It means the important decisions should be clear before Claude begins making changes.

Start With the Goal

Claude should understand the outcome before deciding how to implement it.

Instead of:

Create a booking form.

Try giving it a more complete objective:

Create a booking form for a video-editing service. Customers should choose a package, provide their contact information, describe the project and submit the request. The form must work on mobile devices and clearly show success and failure states.

The second instruction gives Claude a reason for the feature to exist.

It also provides a basic user journey and several conditions that need to be considered.

A good goal explains what the user should be able to accomplish when the work is finished.

Give Claude the Relevant Project Context

The correct solution depends on the existing project.

A prompt that works for a new React application may be completely wrong for an established Next.js project using an existing component library and authentication system.

Before Claude changes anything, it should inspect:

The current folder structure
Existing components
Naming conventions
State management
API routes
Authentication
Database models
Environment configuration
Related features
Existing tests
Project documentation

Claude should reuse the patterns that already exist instead of creating a second architecture inside the same codebase.

One of the most useful instructions you can add is:

Inspect the existing project before suggesting an implementation. Identify the components, utilities and conventions that should be reused. Do not create replacements for functionality that already exists.

That simple rule can prevent unnecessary duplication.

Use CLAUDE.md for Persistent Instructions

Some project information should not need to be repeated in every prompt.

That is where a CLAUDE.md file becomes useful.

It can give Claude persistent instructions covering:

The purpose of the project
The technology stack
The architecture
Folder conventions
Important development commands
Coding standards
Protected files and functionality
Testing requirements
Actions that require approval

For example, a project might include instructions such as:

Reuse components from the shared UI directory before creating new components.

Do not change authentication or payment logic without approval.

Run the existing test suite after modifying shared utilities.

Preserve the current mobile layout unless the task specifically requires a design change.

These instructions give Claude boundaries.

Without boundaries, a small request can turn into a much larger rewrite.

The Claude Code Toolkit includes 15 CLAUDE.md templates for different project types and development situations. Each one can be customized to match the project you are working on.

Make Claude Plan Before It Builds

Starting immediately feels productive.

It can also be the fastest way to build the wrong thing.

Before writing code, ask Claude to explain:

What it believes the task requires
Which parts of the project are relevant
Which assumptions it is making
What it plans to change
Which risks it has identified
How the result will be tested

Here is a planning prompt you can try:

Before writing or editing code, explain the requested outcome in your own words. Inspect the existing project and identify the files, components and systems related to the task. List any assumptions you are making, highlight unclear requirements and create a step-by-step implementation plan. Explain how each stage will be verified. Do not begin implementation until the plan has been reviewed.

If the plan is wrong, you can correct it before hundreds of lines of code are generated.

This is one reason repeatable workflows are more useful than disconnected prompts.

A workflow controls the order in which Claude approaches the project.

Build Complete Projects in Verified Stages

Planning should cover the complete project.

Implementation can then happen in controlled stages.

For a website, those stages might include:

Project structure and shared styling
Navigation and routing
Main pages
Forms and interactions
Responsive behavior
Accessibility checks
Final testing and deployment review

For an application, the stages may include:

Architecture and data model
Authentication and permissions
Core functionality
User interface
Error and loading states
Testing
Production configuration

Claude should understand the complete destination while implementing one verified stage at a time.

This reduces the chance of reaching the end and discovering that important pieces do not connect properly.

The toolkit includes 10 complete development workflows covering planning, building, debugging, improving and launching software.

Debug the Root Cause Instead of the Symptom

One of the weakest debugging instructions is:

Fix this error.

That asks Claude to make the visible problem disappear.

It does not require Claude to understand why the error happened.

A stronger debugging process should make Claude:

Define the expected behavior
Reproduce the actual issue
Trace the complete flow
Find the first incorrect state
Show evidence for the root cause
Propose the smallest safe fix
Protect unrelated functionality
Test the result

Try this prompt:

Trace this issue from the first incorrect state. Explain the expected behavior and compare it with the actual behavior. Identify the root cause using evidence from the relevant files and functions. Propose the smallest safe fix, avoid changing unrelated code and list the tests required to prove the issue is resolved.

This changes debugging from guessing into investigation.

The Claude Code Toolkit contains 10 complete debugging systems designed for different types of failures and existing projects.

“Completed” Does Not Always Mean Complete

Claude may say a task is complete after the main functionality works.

That does not necessarily mean every requirement has been checked.

Before accepting the result, ask it to compare the implementation with the original request.

Use this:

Review the finished implementation against the original requirements. List anything missing, incomplete, unverified or implemented differently. Check the main user journey, related functionality, loading states, empty states, error handling, responsiveness and important edge cases. Do not make additional changes until the gaps have been reviewed.

The final review should answer one question:

Does the project actually do what was requested?

Not just once.

Not just on the happy path.

Across the complete user journey.

What Is Inside the Claude Code Toolkit?

The complete toolkit includes:

260 Structured Prompts
50 website-building prompts
150 app creation and development prompts
50 SaaS feature prompts
10 elite debugging systems
15 Professional CLAUDE.md Templates

Reusable project context for stacks, architecture, conventions, protected areas and testing requirements.

10 Complete Development Workflows

Structured systems for planning, building, debugging, improving and launching software.

100 Curated Claude Code Skills

A hand-picked collection of useful skills with direct links.

Beginner Quick-Start Guide

A simple walkthrough explaining how to customize the prompts, use the templates and follow the workflows.

The toolkit is delivered through a Google Docs library using a simple access PDF.

Who Is It For?

The toolkit is designed for:

Claude Code users
Beginner programmers
Solo developers
Website and app builders
SaaS founders
Freelancers
AI-assisted coders

It is especially useful for anyone who knows what they want to build but struggles to give Claude enough structure to build it correctly.

This Is Not a Promise of Perfect Code

No prompt can guarantee flawless software.

Claude can still misunderstand requirements, make incorrect assumptions or produce code that needs review.

The purpose of this toolkit is not to remove human judgment.

It is to improve the process around the model.

Better context helps Claude understand the project.

Clearer constraints help it stay within scope.

Structured workflows help keep the work organized.

Verification prompts make it prove that the result meets the original requirements.

That is the system:

Plan clearly. Build in stages. Debug with evidence. Review before shipping.

Get the Complete Claude Code Toolkit

Stop starting every Claude Code project from a blank prompt.

Get:

260 structured prompts
15 CLAUDE.md templates
10 development workflows
100 curated Claude Code skills
Beginner quick-start guide

The complete toolkit is available for £3.99 with instant digital access.

https://alfiestips.gumroad.com/l/xydfaa

Give Claude the context, boundaries and testing process it needs.

Build better. Break less. Ship with confidence.

3 Claude Code Prompts I Use to Plan, Build and Fix Projects

alfie.ecom — Sun, 02 Aug 2026 09:50:14 +0000

3 Claude Code Prompts I Use to Plan, Build and Fix Projects

Claude Code can build impressive projects from plain-language instructions.

But vague requests often lead to missing functionality, unnecessary changes and bugs that keep returning.

These are three prompts I use to give Claude a clearer process:

Plan → Build → Fix

Before getting into them, I organized my complete prompt library into The Claude Code Toolkit.

It includes 260 prompts and systems for websites, apps, SaaS products and debugging, plus 15 CLAUDE.md templates, 10 complete workflows and 100 Claude Code skills.

You can view it here:

https://alfiestips.gumroad.com/l/xydfaa

Here are three prompts you can try free.

Plan the Project Before Writing Code

Use this before building a new project or making a large change.


text
Act as a senior software architect.

I want to build:

(PROJECT DESCRIPTION)

Before writing or changing any code:

1. Inspect the existing project structure if one exists.
2. Identify the files, components and dependencies connected to the project.
3. Explain how the current implementation works.
4. Identify technical risks, edge cases and missing requirements.
5. Recommend the simplest architecture that supports the complete project.
6. Create a step-by-step implementation plan.
7. List the files that will need to be created or modified.
8. Ask any questions that must be answered before implementation begins.

Rules:

- Do not write code yet.
- Do not redesign unrelated parts of an existing project.
- Reuse existing patterns and components where possible.
- Avoid adding unnecessary dependencies.
- Keep the proposed scope focused on the requested outcome.

Return the plan in a clear order that can be reviewed before implementation.

This gives Claude time to understand the project before it starts making decisions.

It also gives you a chance to correct the direction before any files are changed.

2. Build the Complete Project From the Approved Plan

Use this after Claude has inspected the requirements and created a plan.

Build the complete project described in the approved plan.

PROJECT:

(PROJECT DESCRIPTION)

TARGET USERS:

(TARGET USERS)

CORE PURPOSE:

(WHAT THE PROJECT MUST HELP USERS ACCOMPLISH)

PROJECT TYPE:

(WEBSITE, WEB APP, MOBILE APP OR SAAS PRODUCT)

TECH STACK:

(PREFERRED TECH STACK OR "CHOOSE THE MOST SUITABLE OPTION")

MUST-HAVE PAGES AND FUNCTIONALITY:

- (PAGE OR FUNCTION 1)
- (PAGE OR FUNCTION 2)
- (PAGE OR FUNCTION 3)
- (PAGE OR FUNCTION 4)

Before building:

1. Review the approved plan and requirements.
2. Confirm the proposed architecture and file structure.
3. Identify the required pages, components, routes and data.
4. Identify any authentication, database or external-service requirements.
5. Ask questions if a missing decision would materially change the build.
6. Do not begin until the requirements are clear.

Build the project in this order:

Phase 1: Create the project foundation, architecture and shared styles.

Phase 2: Build every required page, route and reusable component.

Phase 3: Implement the core functionality, data flow and user interactions.

Phase 4: Add validation, loading states, empty states and error handling.

Phase 5: Improve responsive behaviour, accessibility and visual consistency.

Phase 6: Test the complete user journey and fix any failures.

Requirements:

- Build a functional product, not a static mockup.
- Make every required button, form, link and interaction work.
- Do not add fake reviews, fake statistics or made-up customer data.
- Do not create unnecessary dashboards, pages or features.
- Do not leave placeholder text or unfinished sections.
- Use clear navigation and a consistent visual system.
- Make the complete project responsive across mobile, tablet and desktop.
- Reuse existing components and project patterns where appropriate.
- Avoid unnecessary dependencies and unrelated refactoring.
- Keep secrets and credentials out of the source code.
- Follow the approved scope instead of inventing new requirements.

Before finishing:

1. Test every important user journey from beginning to end.
2. Run the relevant tests, linting, type checks and production build.
3. Check every page at mobile and desktop sizes.
4. Confirm that all forms and interactions work.
5. Review the final project for incomplete or placeholder content.
6. Fix any errors caused by the implementation.

Finish with:

1. A summary of what was built.
2. The final project structure.
3. A list of every page and major function completed.
4. The checks that passed or failed.
5. Any setup or environment instructions.
6. Anything that still requires manual testing.

Do not claim the project is complete if a required page, function or verification check is missing.

This tells Claude to build the complete website, app or SaaS product from the approved plan rather than stopping after one page or feature.

3. Find and Fix the Root Cause of a Bug

Use this when a quick fix has failed or the same bug keeps returning.

Act as a senior debugging engineer.

Investigate this issue:

(BUG, ERROR MESSAGE OR UNEXPECTED BEHAVIOUR)

Expected behaviour:

(EXPECTED RESULT)

Current behaviour:

(CURRENT RESULT)

Do not immediately patch the first suspicious line.

First:

1. Reproduce or trace the issue.
2. Identify the exact execution path connected to the failure.
3. List the most likely causes.
4. Gather evidence for or against each possible cause.
5. Identify the root cause.
6. Explain why the issue is happening.
7. Propose the smallest safe fix.

After identifying the root cause:

- Implement the fix without changing unrelated behaviour.
- Add or update a test that would have caught the issue.
- Run the relevant tests, linting and type checks.
- Check nearby code for the same failure pattern.
- Review the final diff for accidental changes.

Finish with:

1. The confirmed root cause.
2. The files changed.
3. Why the fix works.
4. The checks that passed.
5. Any remaining risks or manual verification needed.

Do not hide failed checks or make unrelated improvements.

This prevents Claude from applying a surface-level patch without understanding the actual problem.

It also creates a clearer record of what failed, why it failed and how the fix was verified.

Final Thought

Better Claude Code results do not always require extremely long prompts.

They require a clear process.

Before asking Claude to code, define:

* What it should inspect
* What outcome you need
* What must remain unchanged
* How the work should be tested
* What completion actually means

The workflow is simple:

Plan carefully. Build the complete project. Fix problems using evidence.

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