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.
Top comments (0)