01
Understand
Clarify the job before implementation starts.
Workflow Garden
Workflow Garden explains an issue-driven AI workflow in plain language. Read the guide, inspect real repos, and follow an automated diary built from actual repository activity.
Start here
The workflow separates idea, plan, and execution issue so each stage stays readable and auditable.
See it in practice
A public educational site that turns an issue-driven AI workflow into something a visitor can understand.
Follow the diary
The repository updated its latest snapshot, memory surfaces, and the workflow guide that explains how the agent operates. Four categories of work—content, proof, automation, and configuration—touched the README, CLAUDE instructions, and agent handbook.
The workflow beats
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
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
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
Live
A public educational site that turns an issue-driven AI workflow into something a visitor can understand.
Proof-heavy example
Live
A public project centered on visible evidence, browser proof, and inspectable output.
Live example
Live
A weighted decision helper prototype built through the full workflow chain.
Setup path
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.
Set the repo rules and make the README useful from the first day.
Turn a rough product idea into a PRD, then slice it into shippable work.
Keep the implementation narrow enough that one issue, one branch, and one PR still feel natural.
Run the real browser flow, inspect the screenshots, then decide whether the work actually passes.
Expanded guide
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.