Skip to main content
Use this workflow when you want PRFlow to learn from what it already shipped. It reads recently merged pull requests, records what went well or badly, looks for patterns that repeat and proposes a bounded number of GitHub issues for a human to triage. It never edits product code and never merges anything.

​
Run It

1

Start from a clean tree on main

This is a local command. It is not available as a GitHub comment command. You can also run the same loop on a weekly schedule with the shipped GitHub Actions workflow — see Run It On A Schedule below.
2

Let the preflight checks pass

The run confirms the working tree is clean, that the GitHub CLI is authenticated and that main is checked out. It switches to main itself when needed.
3

Read the report and triage

The run prints a report, links the state pull request and lists every issue it filed. Everything after that is yours to decide.
This workflow changes your local checkout. It requires a clean working tree, may switch you to main, writes learning records, opens or updates a pull request and creates GitHub issues. Commit or stash your work before running it. A non-empty git status stops the run rather than proceeding.

​
What You Get Back

The report opens with a summary of the scan. For example:
Below that, sections appear only when they have content: the patterns found this run, patterns that regressed after being fixed, the filing queue, patterns a cap withheld, issues filed, patterns skipped by cooldown and any blockers.
The report still carries the product’s former name in its heading. It is the same report. See Migrate From DevFlow.
When there is nothing new, the run says so and stops:

​
What It Scans

The weekly scan finds pull requests by the watched authors that merged in the last seven days and are not already recorded as processed. A pull request with no signal worth analyzing gets a short clean entry. The rest get a bounded analysis. PRFlow then writes the results to its learning records and derives the patterns that recur across them.
To re-run the loop over a specific set of pull requests — backfilling old ones, or re-checking after a fix — pass --prs with a comma-separated list instead of using the rolling seven-day window. Everything downstream behaves identically.

​
Filing Is Deliberately Bounded

A learning loop that files freely produces a backlog nobody reads. Five settings keep the volume down: A pattern with missing evidence is withheld rather than filed on a guess, and the report names which cap withheld what, so a withheld pattern is visible rather than silently dropped. Each filed issue proposes the smallest change that could stop the problem happening again.

​
The State Pull Request

PRFlow opens or updates a separate pull request holding the retrospective records, then returns to main before it files any issues. Review that pull request and merge it yourself once continuous integration passes. PRFlow never merges it.

​
Run It On A Schedule

The same loop can run unattended on GitHub Actions. PRFlow ships devflow-retrospective.yml, which runs /prflow:retrospective-weekly headlessly on two triggers:
  • Weekly cron — every Sunday at 05:23 UTC.
  • Manual dispatch — the workflow’s Run workflow button (workflow_dispatch).
It is disabled by default and opt-in. The workflow runs only when the config key workflows["prflow-retrospective"] reads the JSON boolean true in your default branch’s .prflow/config.json. Anything else — absent, false, or even the string "true" — leaves it off, so a fresh install never runs it until you opt in:
The gate is read from the default branch, so enabling it takes effect once the change is merged to your default branch, not from a pull request. It waits for the previous state pull request to merge. Before running, an enabled run checks for an open prflow/learnings-* state pull request. When one is still open, it skips the retrospective and instead ensures exactly one open reminder issue asking a maintainer to merge that state pull request and re-dispatch the workflow. This keeps the scheduled loop from stacking un-merged learning records. With no open state pull request, the run proceeds normally.
Bump prflow_version in the same upgrade as the plugin. The plugin can auto-update ahead of the pinned engine that the scheduled workflow vendors, so the workflow’s state-guard is still read from the older vendored engine. That older guard recognises only the older devflow/learnings-* branch prefix, so an already-open prflow/learnings-* state pull request would go unnoticed and that week would be re-processed once. Bumping prflow_version (re-running install.sh) alongside the plugin keeps the vendored guard current and closes that window.

​
Where Humans Decide

The retrospective loop does not edit product code, does not implement the issues it proposes and does not merge any pull request. It proposes; you triage.
Pick the findings worth acting on and run them through the normal Implement and Review workflows. The loop never starts that for you. Re-running is safe. The next run processes only pull requests it has not already recorded, and it does not refile a pattern it already filed this cycle.