formtrieb

wave-shared

Shared reference that the wave execution skills — wave-start, wave-reviewer, wave-close — load for the exact result shapes a dispatched agent has to return, and for the working rules they all follow: checking access to the tracker and the code host up front, handling each review outcome the same way every time, and writing to a wave's plan file without ever leaving it half-written. Read via a sibling-path file read by those skills, from their own base directory rather than loaded by name; never picked on its own.

Data & Documents Listed

goal

Use when a project needs a named finish line on the tracker — creating it, deciding which issues belong to it, and reading what is still open before it is reached. It files the first round of work as plain placeholder tickets that carry no readiness marker, so nothing it creates can be picked up by a background agent until a person sharpens it, and its status pass only reports — it never declares the finish line reached. Triggers on "cut a goal", "what is left before <goal>", "add this to the goal", "goal status".

grill-with-docs

Grilling session that challenges a plan against the vocabulary the project already uses and the decisions it has already recorded, sharpens the terminology, and updates the glossary and the decision records inline as each answer settles. Use when user wants to stress-test a plan against their project's language and documented decisions.

Data & Documents Listed

report

Use when an agent has a fully-analyzed finding ABOUT FLOTILLA ITSELF — a bug, a step that is wired to nothing, a pointer to something that no longer exists, documentation that no longer matches the code — found while running flotilla in the repo that adopted it, and it is ready to file upstream at flotilla's own public repo in the format its maintainers expect. Triggers on "report this to flotilla", "file this upstream", "this looks like a flotilla bug, not ours", "report this finding to the maintainers", "file an issue against flotilla".

Data & Documents Listed

to-issues

Use when breaking a plan, spec, or product requirements document into issues small enough that an agent can pick each one up on its own — or when adding the planning header an already-filed issue is missing: how risky it is, who should do it, which files it touches, and what it has to wait for. Triggers on "turn this into issues", "create implementation tickets", "make these wave-ready".

to-prd

Use when turning the current conversation, spec, or design discussion into a product requirements document, published as an issue on the project tracker so the plan is written down before anyone builds it. Triggers on "write a PRD", "turn this into a PRD", "draft a product requirements doc", or when an upstream design session is ready to be captured as a planning artifact for slicing.

triage

Use when an incoming issue needs sorting out — deciding whether it is a bug or an enhancement, trying to reproduce it, asking for the details it is missing, and marking it ready for a background agent or for a person to pick up. Triggers on "triage this issue", "review incoming bugs", "is #42 ready for an agent?", "prepare this for an agent".

wave-close

Use when finishing a wave — works out which order the open pull requests should land in, deletes the working copies the agents ran in, flags anything that got stuck so it is not lost, and files the wave's plan away. Safe to run again if it was interrupted. Add --auto and it also tells the pull requests that do not depend on each other to merge themselves once their checks pass, then stops. Triggers on "close the wave <slug>", "finalise wave <slug>", "archive wave <slug>".

wave-create

Use when turning a chosen set of issue ids into a wave that can actually be run — re-checks that every issue has what an agent needs, surfaces any overlapping files and any issue in the batch that has to wait for another one (stopping to ask before it goes ahead either way), writes the wave's own plan file, and marks the issues as taken so a second batch will not grab them. Triggers on "create the wave", "materialize wave <slug>", "build the spine for these issues".

wave-plan

Use when planning the next wave — one batch of issues that can safely run side by side. Lists which issues are ready to be picked up, then checks them for overlapping files, both against each other and against the issues another batch has already taken. Changes nothing: a person picks which ones to run and hands them to wave-create. Triggers on "plan a wave", "what can run next", "cross-wave check".

wave-resume

Use when a running wave was interrupted part-way — a crash, a closed window, a machine that went away — and it has to be picked up where it stopped. Reads the wave's own plan file, compares it against the working copies still on disk, the results the agents left behind, and the pull requests that have already merged, brings the tracker back in step with reality, and re-runs only the work that is genuinely still outstanding. Triggers on "resume wave <slug>", "the coordinator died — pick up wave <slug>", "reconcile and resume".

Code & Development Listed

wave-reviewer

Use to understand or operate the wave reviewer — the second agent that checks one issue's finished work before a pull request is opened, and that only ever reads. It runs on every issue in the batch, however small the change, re-runs the project's own tests against the commit the batch started from, and answers with one of three verdicts: looks good, needs changes, or a question that has to be answered first. Triggers on "review this wave row", "what does the wave-reviewer check", "run the reviewer on <branch>".

wave-setup

Use when setting flotilla up in a repo for the first time — writes the one `wave.config.json` every other flotilla skill reads: which issue tracker the repo's issues live on, which of them agents are allowed to pick up, and the build or test commands that have to pass before anything is proposed for merge. Triggers on "set up flotilla", "configure the wave store", "init wave config", "initialize flotilla for this repo".

Code & Development Listed

wave-start

Use when running a wave that has already been planned — re-checks the batch is still safe to run side by side, leaves alone anything parked for a human to decide, then puts one background agent on each issue in its own copy of the repo, has a second agent re-run the tests and review the result, and either opens a pull request or sends the work back for exactly one more attempt. Anything that goes wrong is flagged on the tracker for a person to follow up. It stops with every pull request open and waiting — it never merges. Triggers on "start the wave <slug>", "dispatch wave <slug>", "run wave-start".