Organize a GitHub project into phases with explicit acceptance criteria. Review the evidence behind each gate and see what needs attention before the next phase.
Illustrative workflow, not a live workspace result.
Project
Customer portal
Current phase
Implementation
Save survives reload
Evidence needs review
Next step
Review the persistence test
Flow
A phase ends when the evidence says so.
Each phase carries the criteria that have to hold and the evidence behind each one. The gate opens on what was demonstrated, not on the date the plan hoped for.
Define
Design and architecture
Foundation
Core workflow
Illustration of a project advancing through its phases. Your gates use your own criteria and evidence.
Why use Flow?
A task marked done does not tell you whether the product is ready. Flow puts the conditions for moving forward next to the work that must satisfy them.
Agree on what ready means
Define the criteria for each phase so the team and its agents work toward the same outcome.
Review the basis for progress
A criterion derives its status from attached evidence. An unverified claim stays visible instead of counting as a pass.
Keep the project instructions close
Pin the documents and design instructions an agent should read before changing the project.
How Flow fits your work
01
Connect the project
Choose a GitHub repository and open its project workspace.
02
Set the phase requirements
Review the phase criteria and pin the context needed for the work.
03
Review before advancing
Inspect the gate result, resolve missing evidence, and decide what should happen next.
What to know before you start
A gate reflects the evidence supplied and reviewed. It does not independently test every part of your software.