Team-workflow router

One entry point for the team-workflow pack. The pack is a portable discipline for running tracked, multi-session, agent-assisted development: pressure-test an idea, build it in parallel lanes, ship it reviewed and merged. The table below names every skill and its moment. Everything repo-specific lives in, or is pointed at from, one binding doc seeded by the setup skill; every skill defers decisions to the decider, the role that doc names.

First run in a repo? Run setup before anything else. The other skills read the bindings it seeds. Where the binding doc records working mode lead, the human works from the orchestrator seat: a new session invokes orchestrate and follows its startup checklist, and this table is what that seat runs, not a menu for the human.

The main flow

Most work travels one route: idea → grill → map → tickets → lanes → review → merge. An idea is pressure-tested in grilling; when real fog surfaces, decision-map charts and works it until nothing gating is undecided (no fog means skipping the map entirely); to-tickets turns what was decided into tracer-bullet items; orchestrate routes those items into parallel lanes, each building under implement's discipline; adversarial-review tries to break each change before it merges. prototype and research are detours off any point of the route, taken when a question needs seeing or reading rather than deciding, and handoff carries state across every session boundary along it.

On-ramps merge onto that route rather than starting a new one: ingest turns a recording or media URL into evidence plus a recommendation for where it enters the flow (tickets, a grilling session, strategy for the decider); research findings and returned questionnaires flow back to the stage that owns them: the map ticket, the driving ticket, or the grilling session that spawned them; wizard clears the human-only steps a lane stalls on and hands the flow back.

The skills

Skill	Reach for it when
setup	Installing the pack into a repo, or refreshing its bindings. Once-per-repo interview: confirms the tracker, verify commands, the decider, the binding-doc home, and the working mode (lead from the orchestrator seat, or read code and pick skills); seeds the binding doc, templates, and the session-start handoff hook; re-runs are idempotent diffs, never overwrites.
domain-memory	The repo's institutional memory needs writing or reading: a grilling just closed, a review disposition landed, the decider corrected a wrong assumption, or a session is starting and wants the settled terms and decisions. One store, two artifacts: a small domain glossary plus supersede-never-edit decision records, written as side effects of work at the memory home the binding names; consolidation and backfill happen only by decider disposition.
grilling	An idea or plan is half-formed and nobody has pressure-tested it. Interviews the decider in rounds over a design tree, where the frontier is every decision whose prerequisites are settled, until nothing load-bearing is still assumed. Facts are the agent's job; decisions are the decider's. Run it before charting a map or writing a spec off a conversation.
decision-map	The work is genuinely foggy: open questions gate each other and nobody can spec it in one sitting. Charts a map (destination, clusters, two ledgers), files gate-decision tickets, and runs briefed decision rounds with the decider. Not for work you could already spec: a map with nothing undecided is overhead.
prototype	The question is "how should this look / behave / feel in action" and discussion or static artifacts can't settle it. Throwaway code on a prototype/<name> branch: UI variants on the live route, or a terminal UI or single shareable HTML file over a pure logic module; the verdict is the deliverable and the winner is re-implemented properly.
research	A question is answerable from primary sources and should run fire-and-report. Autonomous investigation ending in a cited findings file, and a questionnaire when the missing facts are human-held.
codebase-review	The codebase itself needs review: a spec is about to land in an area, enough lanes have merged since the last look, or lanes report the code fighting them. A read-only lane: lens-named finders, a built-in skeptic that kills unproven candidates, a plain-markdown report on the tracker, and a disposition loop where the decider adopts, rejects into rejection memory, or defers every survivor. Zero survivors is a success verdict, not a failure.
to-tickets	The decision is made and the work needs to be on the board. Turns a plan, a closed decision map, or a pressure-tested conversation into tracer-bullet items: issue-as-spec bodies filed in one pass, blocking edges wired in a second. Files and labels; never claims, never decides.
wizard	The next step is one only a human can take: a vendor dashboard, a registrar's DNS panel, a credential that must not enter an agent's context. Generates an interactive bash wizard that opens each URL, says what to click, captures the values, verifies what it can, and reports what still needs doing by hand.
handoff	Context is filling (around half the window), the session is wrapping up, or someone says "checkpoint" / "save state". Writes the structured session handoff (overwrite-don't-append, pointer-not-transcript, NEXT points at the tracker query) so a fresh session resumes losslessly.
show-me-your-work	A run will be reviewed by a human who stepped away: an unattended stretch, a long autonomous build, a loop. Keeps one append-only TSV decision log, one row per decision with its why, evidence pointer, and result, audited against the run's record before handback. The pack's third record type: handoff is the resume pointer, domain-memory the institutional why, this the per-run audit ledger.
orchestrate	One session should play the lead developer of an agent team instead of implementing: it routes tracked items into parallel working lanes, audits results, and owns integration, and the human brings decisions. The seat a non-engineer works from. Principles plus per-repo binding slots; the single-orchestrator rule applies.
adversarial-review	A substantial change is about to be committed, a lane is at close-out, or someone asks to break a diff before it ships. Three isolated finders (correctness, a fitting lens, a spec axis), a skeptic pass that kills unproven findings, a gate only confirmed blockers may hold; run before external reviewers see the change.
implement	A build-shaped item is being implemented in a lane. The discipline the lane follows inline: first commit proves the thinnest end-to-end slice, red-before-code at every seam the item's verification set names, a green checkpoint commit per slice, and adjacent discoveries filed to the tracker rather than built. Bugs route to diagnose; ambiguity goes back to the decider; human-only steps get a wizard.
diagnose	A bug is being fixed and the cause is not yet nameable in one plain sentence with evidence. The disciplined loop a lane follows inline: reproduce red with a test written before the fix, minimize until tight, falsifiable hypotheses, instrument before fixing, and close on the named cause plus the regression test. Structural causes report as friction; standing facts feed domain-memory.
ingest	A recording, voice memo, or media URL arrives with a goal. Converts it into an evidence packet of transcript, timestamped frames, and manifest, and ends with a routing recommendation into the flow: what looks like tickets, what needs a grilling session, what is strategy for the decider. Ships as its own plugin, installed beside the pack.

Not skills, but in the pack

• Tracker discipline: the claim / frontier / blocking recipes and the issue-as-spec shape live in setup's references and get bound to the repo via the binding doc. There is nothing to invoke; sessions follow the recipes.
• Templates: work-item spec and lane brief are templates the setup skill seeds into the consuming repo; the session-handoff template ships inside the handoff skill.

Review discipline: the meta-rule

The pack ships a review protocol, the adversarial-review skill, but still no review checklist, on purpose: derive your own defect classes from your own defect history. The reason and the rules that keep a repo's checklist honest live in that skill's defect-class section.

A sibling of the same meta-rule: institutional review memory: review verdicts recorded as per-repo decision entries that later reviews (human and automated) consult before commenting, so settled decisions reopen on new evidence, not on repetition. Repos that already run such a system, a review-response skill with a decision wiki, have the review-RESPONSE stage covered, and this pack deliberately stays out of it: planning, research, prototyping, handoff, and orchestration are the pack's territory; review response belongs to the resident system, and pack outputs should cite that repo's precedent store rather than create a second one.

Attribution

The main-flow-with-on-ramps framing is adapted from Matt Pocock's ask-matt (MIT); the flow itself, the table, and the meta-rules are this pack's.