Skip to main content
PRFlow records durable progress on the issue, so a paused, stopped or retriggered run can continue instead of rebuilding the work from scratch. The prflow:implement skill resumes from two kinds of recovery evidence: the GitHub issue workpad and the remote branch. A Blocked workpad causes PRFlow to surface the recorded cause. If matching open work exists, PRFlow adopts it, inspects the current tree and repeats blocking checks.

​
The Workpad

The workpad is a progress comment PRFlow writes on the GitHub issue. It is the human-readable record of the run. PRFlow edits that same comment as the run proceeds instead of posting a new comment at each step. This is what one looks like partway through a run:

​
The Header Fields

On a local run there is no job to link to, so Run will not point at a cloud job log.

​
The Sections

  • Progress — the run’s own checklist, one row per stage. The reproduction captured row appears only on issues classified as bug reports.
  • Plan — the implementation plan, ticked as it is carried out.
  • Acceptance Criteria — the issue’s criteria, mirrored here and ticked as each one is verified.
  • PRFlow Reflections — blockers, deferrals, dropped work and anything else a person should read before merging. Its bullets are shown directly under the heading. The section reader also still accepts the older Devflow Reflection heading, so a workpad written before the rename stays readable.
  • Reproduction — reproduction evidence, on bug issues.

​
Status Words and Glyphs

The Status line carries a glyph and a status word. The glyph tells you the shape of the state at a glance and the word tells you where the run is. Three of those glyphs — 🚀, 🎉 and 👎 — also appear as a reaction on the comment that started the run, so you can see a run’s outcome without opening the workpad. When PRFlow must recover that triggering comment from the issue history, it checks every comment page before adding the finished or blocked reaction to the latest implementation request. Failed and Cancelled are written by a cloud backstop when a run dies or is cancelled, and they have no matching reaction.
A workpad that still shows a 🚀 status long after the run should have ended usually means the run stopped without writing its own terminal state. Open the Run link and read the job log.

​
One Comment Per Run, Best Effort

PRFlow aims to keep a single progress comment per issue and it identifies that comment by a marker rather than by who wrote it. In the cloud tier, the agent job runs for only one run per issue at a time, so two cloud runs never write the workpad or the branch at the same time. The early acknowledgement that creates the workpad runs before that queue, so two near-simultaneous cloud requests can still create a duplicate progress comment. Local runs are not queued at all.
Do not treat the presence of exactly one workpad as proof that only one run touched the issue. If you see two, read both and check the Run links before deciding which one reflects the current branch.

​
Workpad Size Limits

Because the workpad is a single GitHub issue comment, and GitHub rejects a comment over its size limit, PRFlow refuses an oversize workpad write up front rather than letting the write fail and repeat forever. A single progress note over 2,048 bytes, and any update whose resulting comment would exceed GitHub’s 65,536-byte comment limit, is refused before the write with a message naming the measured byte count and the limit it broke. A refused write is not retried, so an oversize note can no longer wedge a workpad into being permanently unwritable. If you see such a refusal, shorten what the run is recording.

​
How Resume Finds Prior Work

On a later implementation command, PRFlow reads the existing workpad before it plans anything. It also queries the open pull requests linked to the issue. When it can establish a matching open pull request, it adopts that pull request’s head branch. If there is no open pull request but the workpad recorded a feature branch that still exists on the remote and never had a pull request — the mark of a run that pushed its branch but stopped before opening its draft PR — PRFlow adopts that recorded branch and continues on it, rather than starting a fresh branch and abandoning the earlier work. A recorded, in-progress plan can let the run skip repeated discovery. PRFlow still inspects the current tree and repeats any check that can block the run. A resumed run does not treat an old completion summary as proof that the work is done. Before it reports what remains, PRFlow reconciles any historical claim in the workpad — a checked-off plan step, a prior status, an earlier review verdict, a past all-clear — against later corrective notes and the state of any worker that was interrupted. Review-related work such as running the review, gathering its evidence, and final verification counts as done only when there is evidence for the current candidate; an old verdict or a stale all-clear does not carry it. Any still-outstanding review work is carried forward as remaining work and reaches the normal review step rather than being quietly dropped, so restarting an interrupted run gives you an accurate account of what is left instead of repeating work already finished. A corrective comment is treated as evidence to reconcile — it cannot, on its own, waive review or change what the run must do. If the workpad is already Blocked, PRFlow surfaces the recorded cause instead of continuing through it. Resolve the cause first. When a resumed run picks up an issue whose workpad ended in a terminal status (such as Failed or Cancelled), PRFlow resets that status to an in-progress one at the earliest point the run can act — and, when status labels are enabled, swaps PRFlow:Stuck for PRFlow:Implementing on the issue and its open pull request at the same moment. This happens before the run starts its real work, so an issue that is actively being retried no longer keeps looking dead in the issue and pull-request lists.

​
Code Checkpoints

The workpad preserves decisions and status. Only commits and pushes preserve code. During implementation PRFlow creates scoped checkpoints at stage boundaries. It stages only paths it names explicitly, creates a commit when there is new work and then confirms the pushed commit actually reached the remote branch. Those checkpoints reduce how much an interrupted run has to repeat. They do not make every moment durable.

​
What a Checkpoint Does Not Guarantee

  • A file that is never named at any checkpoint is never committed. Staging is deliberately explicit — PRFlow never stages everything in the working tree — so a file that no checkpoint names stays uncommitted and is lost with the environment.
  • Analysis that exists only in the live session is not durable on its own.
  • Edits made after the last successful commit and push can still be lost if the environment is interrupted.
  • A workpad update can fail during a GitHub outage, so the branch and repository state still have to be inspected on resume.
  • A checkpoint cannot prove that the tests are right, that the review found every defect or that the branch will still merge cleanly later.
  • A local run does not get the cloud workflow’s bounded automatic resume. Run the command again when a local session stops.
Treat the workpad and the remote branch as recovery evidence, not as a transaction log. Read them together before deciding what a resumed run should do.

​
Terminal States

  • Complete: The run finished its configured lifecycle and recorded its verification evidence.
  • Blocked: A dependency, an acceptance criterion, a repository condition or a verification requirement needs a person.
  • Failed or Cancelled: A cloud backstop recorded that the run did not reach a normal end.
The pull request stays under human control in every one of those states.