Claude Code · Prompt Kit

Henry's Dev Workflow

Blitz Deal / hondabyhenry.ca · Inspect → Diagnose → Plan → Execute → Document
1
Inspect
2
Diagnose
3
Plan
4
Execute
5
Document
1
Session Start — Inspect First
Every new session
Use at the start of every Claude Code session before touching any file.
Works for Blitz Deal, hondabyhenry.ca, or any future project.
Prompt — Copy & Paste
Do not code yet. First inspect this project. Explain: 1. What this app does and who it's for 2. Main folders and files — what each one does 3. Current data flow — how info moves through the app 4. Any messy, fragile, or risky areas I should know about 5. What you need from me before we make any edits // Paste repo structure or key file contents below this line
Why: Forces Claude to build a mental model of your project before suggesting anything. You'll catch misunderstandings before they become bad edits.
2
Something Broke — Diagnose the Error
When things break
When the site behaves wrong or something stops working.
Paste the terminal output or describe what you're seeing.
Prompt — Copy & Paste
Do not change any files yet. Read this error and explain: 1. Root cause in plain English — what actually went wrong 2. Which file(s) are involved 3. Why it's happening (logic issue, config issue, missing dependency, etc.) 4. The safest fix — what to change, and what NOT to touch 5. Any side effects I should watch for after the fix // Paste terminal error or describe the bug below this line
Why: Stops Claude from patching symptoms. Forces it to identify the real cause so the fix actually holds.
3
New Feature — Build the Plan First
Before any new feature
Use before adding anything new to Blitz Deal — a new model, a new calculator field, a new section on hondabyhenry.ca.
Prompt — Copy & Paste
I want to add: [describe the feature] Do not write any code yet. First give me a plan: 1. Which existing files are involved 2. What needs to be added vs. what needs to be changed 3. The exact implementation steps in order 4. Risks — what could break or behave unexpectedly 5. What I should test after it's done I'll review and approve before you write anything.
Why: Prevents the "random changes that break everything" problem. You see the whole plan before a single line is written.
4
Approved — Now Execute Safely
After plan approval
Only run this after you've reviewed and approved the plan from Step 3. Keep control of each change.
Prompt — Copy & Paste
Plan approved. Now implement it. Rules: Make changes one file at a time After each file, show me what changed and why Do not move to the next file until I confirm If anything looks different from the plan, stop and tell me At the end, give me exact steps to test that it works Start with: [first file from the plan]
Why: Keeps edits atomic and reviewable. You stay in control instead of getting a 10-file dump you don't fully understand.
5
Session Done — Write the PROJECT_NOTES
End of every session
Run this at the end of any session where files were changed. Keeps a running log of your project state.
Prompt — Copy & Paste
Create a PROJECT_NOTES.md entry for this session: ## Session — [today's date] Sections to include: ### What Changed List every file edited and what was done ### Why It Changed The reason / goal behind the changes ### How to Test Exact steps to confirm it's working ### Known Issues Anything incomplete, fragile, or worth watching ### Next Steps What to tackle in the next session Keep it concise. This is my project memory.
Why: When you come back after a week — or hand something off — you won't lose context. This is your project's running changelog.

Your Golden Rule

No coding before diagnosis. No diagnosis without reading files.
No big edit without a written plan. No finished task without test steps.