The workflow beats

What you need to understand before the tools start sounding useful.

This workflow is easier to follow when each phase answers one clear question: what are we doing, how are we building it, how do we know it works, and what happens when it ships?

01

Understand

Clarify the job before implementation starts.

02

Build

Build on one ticket branch so the change still has a readable shape.

03

Prove

Treat proof as evidence, not as a polite summary.

04

Ship

Only call it done when deploy, merge, and cleanup all line up.

Tool map

Four lanes, collapsed until you need the detail.

The long homepage columns were doing too much at once. This version keeps the same guidance, but lets visitors open one lane at a time.

Projects

The workflow makes more sense once you can inspect a real repo.

These project pages connect the explanation to real GitHub repos, live URLs, and diary evidence. They answer the practical follow-up question: where has this approach already been used?

Featured project

Workflow Garden

Live

A public educational site that turns an issue-driven AI workflow into something a visitor can understand.

Educational siteworkflow-garden

Proof-heavy example

Proof Pack

Live

A public project centered on visible evidence, browser proof, and inspectable output.

Proof workflowproof-pack

Live example

Choice Compass

Live

A weighted decision helper prototype built through the full workflow chain.

Decision helperchoice-compass

Setup path

The workflow, in order, with the details ready when you need them.

Start with a clean repo, turn the work into a plan, ship from a ticket branch, and prove the result before you celebrate. The short version stays visible. The deeper notes sit right underneath it.

  1. 01

    Bootstrap a clean repo

    Set the repo rules and make the README useful from the first day.

    repo-bootstrapgh repo creategit init -b main
  2. 02

    Write the plan in normal language

    Turn a rough product idea into a PRD, then slice it into shippable work.

    write-a-prdprd-to-planprd-to-issues
  3. 03

    Ship from one ticket branch

    Keep the implementation narrow enough that one issue, one branch, and one PR still feel natural.

    git checkout -b raj-37-…gh pr creategh pr merge --delete-branch
  4. 04

    Require proof before celebration

    Run the real browser flow, inspect the screenshots, then decide whether the work actually passes.

    playwright-clidesign-proofacceptance-proof

Expanded guide

Open the exact expectations for each step.

This is where the commands, proof bar, and branch discipline become explicit. It stays out of the way until the visitor wants to slow down.