Yesterday I said process beat prompting. Here's the process.
Every change to ParkEase, from a one-line fix to a whole admin panel, went through the same route. It lives in one file the AI loads at the start of any ParkEase work. I called it flow.
The seven phases
| # | Phase | What has to happen before moving on |
|---|---|---|
| 0 | Orient | Find the skills that apply before answering, asking or reading anything |
| 1 | Think | Brainstorm the approach, then a "does this need to exist?" pass |
| 1b | Direction | UI only: render 2–3 options and let the human pick |
| 2 | Plan | A written plan, steps small enough to verify |
| 3 | Build | Tests first |
| 4 | Debug | Root cause before any fix |
| 5 | Review | Not one review: a stack of them |
| 5b | Design audit | UI only: touch targets, hierarchy, type, motion |
| 6 | Verify | Evidence before any "done" claim |
| 7 | Ship | An 18-line checklist, every line done, before the PR opens |
Each phase names the skill that runs it. "Think" is brainstorming. "Build" is test-driven-development. "Verify" is verification-before-completion. A skill, as I'll explain in the next post, is a short instruction file the agent loads when the task matches. So each phase isn't a vague intention; it's specific instructions the AI follows at that moment.
The four gates that never drop
Phases can scale down. A typo fix doesn't need a brainstorm. Four things never drop, whatever the size:
- Brainstorm before creative work. The task file says what. Brainstorming settles how, and surfaces what nobody wrote down.
- Tests before implementation code.
- A design gate for anything that changes how something looks, feels or moves. Code review can't tell you a screen looks templated.
- Verification before any "done", "fixed" or "passing". Run the command, read the output, then make the claim.
The 18-line pre-PR gate
Phase 7 is where most AI workflows quietly fall apart, because the agent is eager to finish. So the last phase is a literal checklist: backend review, frontend review, HTTP-level API tests, frontend tests for the new code, security review, the UI audit, migration review, the four mandatory integration tests, lint and typecheck, pnpm audit, a secret scan, and updates to the learnings, test-case and decision files.
It's reported as a table with evidence per line. "I'll note it in the PR body" doesn't count. A gap written into a PR description is a gap nobody re-reads.
Two lines are there because skipping them already let a real defect through:
- API testing means HTTP-level. Tests that call a command directly can't see the interceptor, the status code or the error envelope.
- Frontend testing means the new frontend code. Six new screens with zero new tests is a failed gate, not a style choice.
The rule that stopped it becoming ceremony
Any process this size decays into box-ticking. One line in my instructions does more than any phase:
When skipping a phase, say which and why. Silent skipping is how this decays into nothing.
The AI is allowed to skip. It isn't allowed to skip quietly. "Skipped the design gate: no UI changed" is fine. A missing phase with no sentence about it is a bug in the process, and I treated it like one.
The other half came later, the hard way: process costs tokens. At one point the workflow told the AI to send a separate reviewer agent per lens per task, and one task burned most of a week's usage limit. The fix wasn't dropping review. It was doing it inline and dispatching specialists only when a diff deserved it. That story gets its own post.
Next: the files that make all of this stick: SKILL.md, CLAUDE.md, and why ParkEase deliberately has no AGENTS.md.
ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease
Top comments (0)