Skip to main content
Hand the week’s raw tickets to a team and get back stories a developer could pick up: each with its acceptance checks and the ticket it came from, each read back against the raw tickets by a model from another family, and beside them the questions that must be settled before anyone writes code. Then the person who owns the product ranks. Nothing here writes code: the work is deciding what is worth writing, and the run stops at the person.
In that directory, create package.json with "type": "module", put the brief and the sample inputs from examples/use-cases/engineering/ beside it, then run the copied file.

​
The file

Every event of the run prints as one line as it happens, the usage lines included, and the outcome prints last as JSON. The run stops at rank with the question on the record. The stories and the questions are in backlog/ for the owner to read; an answer through the run’s callbacks client carries on from there, and a no goes back to split with the owner’s note as the finding.

​
What a run printed

The output below is from one real run of this file, with the two command line tools signed in on the machine. This run did not finish, and it is here because of that rather than in spite of it. The reviewer is a model from another family. Three times it read the stories and sent them back with a real problem: a dark-mode story that said every screen renders “correctly” without saying which screens or what proves it, and an export story that had quietly become two, finishing a yearly export and running one every month. Each round the writer fixed what it was told and the reviewer found something else true. On the third the loop reached its allowance and stopped. Nothing was published. A grooming loop that stops with the work unfinished is doing its job; one that runs out of attempts and passes the stories on anyway would not be. The allowance is the thing to match to the work: three rounds suit a job with a few defensible answers, and splitting a backlog of vague tickets is not that job.

​
The team’s shape

Where a stage’s gate names a file, the package checks the file after the job. Where it names an exit code, the command decides. Where it names a reviewer, the reviewer’s decision decides. Where it names a person, the run pauses until the person answers. A model’s own report of its work never passes a stage.

​
Gotchas

  • The reviewer reads the raw tickets, not just the stories. The review’s gate is coverage: a raw ticket with no story sends the split back, which is what happens in the proof.
  • Priority is not the model’s to decide. The brief says so and the workflow ends at a person; a story order that appeared in stories.md would be a model’s guess dressed as a decision.
  • A note that comes back unchanged fails. A split sent back with findings must change; the same bytes again end the stage rather than run a second identical review.

​
Source

The file is examples/use-cases/engineering/backlog-groom-then-rank.ts; its proof, brief and sample inputs sit beside it. The runtime package page lists every input.