The PRD loop · Zurdo

The loop zurdo was built around, how it maps onto agile, and how to use it well.

Writing PRDs covers the artifact. This page covers the loop you run it in: you keep the engineering judgment and hand the agent only the typing.

The loop

The six-stage human and machine workflow with time estimates, looping from verify back to author and from decide back to scope

Two properties make it work:

You're needed only where judgment is irreplaceable: locking the scope and accepting the result. Everything between runs on machine time.
Verification happens on both sides. The spec is checked before the run and the work after it, so the cheap gate always runs first.

Phase by phase

1 · Scope (unbounded) Research the code, constraints, and failure modes, then lock what will exist when you're done. Take as long as it takes: the scope is a commitment.

2 · Author (30–60 min) Turn the scope into tasks and criteria with zurdo-prd-author, or scaffold a draft. If this drags, the scope wasn't locked.

3 · Verify the PRD (minutes) Check that each criterion is honest, falsifiable, and failing today, then run zurdo validate and zurdo analyze. A bad criterion costs a minute here and a whole run later.

4 · Run (machine time) Start zurdo run, often on a remote server, and walk away. Zurdo checks every hint after every iteration, and Max-Attempts caps the spend.

5 · Review (30–60 min) Read the diff and sign off [manual] criteria with zurdo review. The criteria proved it works. Review asks whether it's how you'd have built it.

6 · Decide If the evidence holds, merge it yourself (zurdo has no git automation). If a task kept failing, the scope's model of the system was probably wrong: rescope.

Why scoping is the one phase without a timebox

Once a PRD runs, the scope dictates the work and forces you to finish rather than deviate. Zurdo enforces this mechanically:

The PRD is immutable during a run. A mid-run "actually, let's also…" has no way in.
Zurdo re-runs every criterion itself, so the definition of done can't drift to match whatever got built.
Frozen paths fence off evidence the run must not touch.

Deviation isn't suppressed, it's scheduled into the next scoping session. A good scope makes phase 2 transcription, not invention.

The agile correlation

This is the agile cycle with three changes: the sprint shrinks to hours, an agent replaces the team, and every rule agile enforces socially, zurdo enforces mechanically.

Agile	Zurdo	What changes
Product backlog	Findings and deferred work for the next scope	Same role
Sprint planning	Scope (phase 1)	Still the slow, judgment-heavy phase
Story + acceptance criteria	PRD task + hint-typed criteria	Criteria become executable checks
Definition of Done	The hints	Checked after every iteration, so nobody can just "call it done"
Sprint commitment	The locked PRD	Can't be renegotiated mid-run
The sprint	The run	Weeks become hours; `Max-Attempts` replaces the burndown
Daily standup	`progress.log` + iteration records	Same information, no meeting
Sprint review / demo	Review: report, evidence, `[manual]` sign-off	Gathered evidence replaces "trust me"
Retrospective	Decide (phase 6)	Failing criteria are the retro input
Velocity	Throughput	Counted in merged scopes, not story points

Pipelining

The loop doesn't have to be serial. While one PRD runs, author the next, then review both when you're free.

Machine time overlaps human time. You author and review; the runs fill the hours between.

throughput ≈ available attention ÷ (authoring timebox + review timebox)

Implementation time drops out of the equation, and that's the gain, not agent speed. A chat workflow costs your attention every iteration. Here you spend it once on the design and once on the verdict, and you can batch each: design in one block, review in another.

Tracking the loop with Carol

When the work spans several PRDs, or teammates follow it on GitHub, Carol mirrors each edge of the loop: carol scope at scope, carol publish after authoring, carol sync after a run, and carol status at decide. It never runs zurdo, and every write waits for --apply.

Using it well

Zurdo automates the loop, not the thinking. Everything before zurdo run costs little or nothing. It exists to make the token spend land.

Delegate outcomes You own what, where and how you'll know. If you can't name a check a machine can run, you're still in design.

Split by outcome Each task needs criteria that can fail on their own. Split by verifiable outcome, not by file, and order with Depends-on.

Hint before prose Write each criterion's hint first, and make it fail on today's tree. A criterion green before the run proves nothing.

Freeze the evidence Put ADRs, lockfiles and generated code under **Frozen** or [verification] protected_paths.

Validate every PRD, even ones you're sure about. You're most tempted to skip it when rushing, which is when it catches something. In CI, zurdo validate --strict promotes nine of the twenty-two lint families to errors, unreviewed-scaffold and hint-path among them.
Never pay for a run to learn what zurdo analyze would have told you. It flags hints that run but prove nothing, such as [shell: true] and grep tautologies, and requirements no criterion covers.
Size effort honestly. **Effort** picks the model. Give hard tasks a realistic Max-Attempts and Agent-timeout.
Treat green as a claim. Read run-diff.patch, the passed-at-preflight tally and any evidence-modified warnings. Only you can judge design and naming.
Disconnect freely. State is resumable, so remote runs survive a dropped session.
Ship it yourself. Zurdo has no git automation, and that's where your accountability starts. Keep reports/*.json and iterations/* as CI artifacts.
If authoring or review keeps running over, fix the scope. Don't stretch the timeboxes.

Next: Running a PRD