Workflows and ad hoc work

An order becomes a filter

Ask Claude Code to work through more than one ticket and the build skill takes over.

/teamflow:build

What you said is turned into a workflow: which tracker, which project, which issues, and in what order.

• "Build the backlog" becomes every open issue, in your tracker's own priority order.
• "Everything in the backlog but skip the auth work" becomes the same filter plus a judgment applied when the pool is selected.
• "Do the open bugs in order" becomes the open bugs, in order.

Your sentence is kept so the run can say what it was asked for. It stays on the machine and is never published.

Deploying is out of scope unless you asked for it.

A plan with dependencies and phases

Before the first ticket starts, the whole pool is read and the dependencies between the tickets are worked out and recorded, each with a short sentence saying why.

Those dependencies are then sorted into phases. A phase is a set of tickets that can be built at the same time because none of them waits on another. Nothing from a later phase starts early.

Two things follow that are worth knowing:

• A pool with no dependencies is one flat phase, which claims everything can be built at once. That is almost never true, which is why the planning step happens at all.
• The phases are arithmetic, not judgment. Recording an edge re-levels them immediately. Nobody reorders a phase by hand.

If the dependencies form a cycle, the phases come back blocked and you are asked which edge to drop.

The reason recorded against each dependency is what the board draws on the arrow, so a week later the arrow still says why it is there.

Kept current as the run goes

Every change is published the moment it happens, not at the end of the run. The ticket's state and cycle at each gate, the edge the moment a team hits it, the title the moment the work turns out to be something else.

When a gate fails, the ticket goes back with the gate that failed named, and the phase offers it again. The hooks report the rework and the board draws the loop; nobody reports a stage by hand.

When a team finds a dependency mid-build, it is recorded as found while building rather than as part of the plan. The phases re-level at once and the ticket moves. Work already done is kept, and the run can tell you afterwards which edges were the plan and which were news.

Add a ticket you missed

A ticket that should have been in the pool and was not is added to the running workflow:

npx -y github:macleodlabs-ai/teamflow-plugin workflow add MACLEOD-534

It levels into a phase with everything else. Record any dependency it has in the same way as the rest, and the phases re-level around it.

An edge may point at a ticket outside the pool. That is worth recording and it gates nothing — so if the run genuinely needs that ticket, add it.

Ad hoc work: work with no ticket

A fix somebody mentioned in passing, a question that turned into a change, a chore nobody raised. Until it has a key, that work reaches the board under no key at all.

/teamflow:adhoc

TeamFlow mints a key of the form ADHOC-7, per organisation, so two sessions never invent the same one. From a shell:

npx -y github:macleodlabs-ai/teamflow-plugin adhoc start "Retry the Linear backfill on a 429"

That mints the key, publishes the item and binds the session to it in one go. From there the hooks take over exactly as they would for a ticket.

An ad hoc item is an ordinary ticket in every way that matters. It sits in the same pool, takes dependencies in both directions, moves through the same stages, and the board draws it beside the tickets. The only difference is who minted the key.

The title is what the work is, never what was asked

Write a short sentence, in the third person, saying what the work is.

• "Retry the Linear backfill on a 429" — what the work is.
• The words somebody typed to ask for it — never. Prompts do not leave the machine, and the title is the one field where that is easy to get wrong.

One line, and no more than 180 characters. The cap is a backstop, not the rule: a title that fits and still quotes the request is still wrong.

Ending one

npx -y github:macleodlabs-ai/teamflow-plugin adhoc done

That publishes its final state and unbinds, so the next thing you do is attributed to whatever it is actually about. If the session simply stops, the item is ended for you.

An ad hoc item never reopens. A follow-up is a new item with a new key, even about the same code — otherwise one key would mean two pieces of work and the board could not say when either finished.

Next

• The delivery flow
• What a report carries
• A ticket stopped moving