Write the spec. Build. Check.

01 · Question the idea

I start with the Idea clinic: what problem needs solving, who has it, and whether it needs software at all. I look for alternatives and distinguish a personal tool from an idea people might pay for.

Before building, I consider how the idea might succeed or fail and what evidence would change my mind. The clinic can prepare a prompt for an assistant; its WebMCP tool is designed to let a compatible browser agent retrieve it directly.

02 · Write the spec

I describe who the work is for, what it should do, its boundaries and what a passing result looks like. Then I choose whether it calls for an app, a website, a workflow or an agent, and plan how to make it. Significant changes get a written intent and an independent review of the plan.

03 · Build in Orca

In Orca, I give a builder a bounded brief and an isolated task branch or worktree. The brief says what can change and how to check it.

I create my own agents and workflows around the tasks I repeat.

04 · Check the result

I review the changes and run relevant tests against the agreed behaviour. My guardrails call for a separate review agent before higher-risk merges. It is meant to check the change and tests, report evidence and identify what remains untested. I check those findings and whether the result still solves the original problem.

For web work, I also check real browser paths with Jev Browser Control. After significant builds, an independent review looks at what changed and what can be learned.

05 · Keep the context

Unli Rice retrieves decisions, guardrails and next steps through MCP. I check the repository for current technical facts.