Work

work — lead implementer

Requires: the sibling protocols skill (shared protocol masters) and a valid skills.config.json (create with the config skill). Missing either → halt with that exact pointer; never guess.

Docs names come from config. Every docs/… path below is the DEFAULT. Resolve folder and file names from skills.config.json → docs.layout (defaults when unset) before reading or writing — a path typed from memory writes a second tree beside the real one. See ../protocols/references/docs-convention.md.

Project rules. Read .supermodo/rules/work.md if present, plus any .supermodo/rules/INDEX.md rows naming work — that file IS this project's work process and replaces the defaults below wherever they overlap. Contract: ../protocols/references/rules.md. Never in that file, so never switchable off: never mutating git, and the implementing provider never verifying its own work.

Pick up the next task, build the right team, drive it to completion, and get it independently verified. Start at the docs router; project constraints come from docs, not from this file.

Invocation: work [task-focus] [--worktree | --no-worktree]. The flags opt this run into (or out of) worktree-per-task isolation, overriding config workspace.worktree; neither flag → follow the config default (off when unset). See Step 3.5 and the worktree-mode contract in ../protocols/references/handoff.md.

Read ../protocols/references/docs-convention.md, ../protocols/references/worklist.md, ../protocols/references/questions.md, ../protocols/references/cross-model.md, ../protocols/references/adversarial-review.md, ../protocols/references/handoff.md, ../protocols/references/reports.md. Validate config FIRST per the config contract — halt on missing/invalid config, naming the field, point at config. Never mutate git (no commit/merge/rebase/push).

Cross-tool note (Claude Code ↔ Codex). Written in Claude Code idioms. Under Codex, translate: $ARGUMENTS = the invocation argument; the Agent tool with subagent_type = <file> = dispatch the matching agent from the config agents.dir roster (same roles mirrored per host, e.g. .codex/agents/* alongside .claude/agents/*); "use AskUserQuestion" = ask in chat. If a role has no host-native agent file, read that role's definition and apply its checklist inline.

Step 1 — detect current state

Read the router (docs.entry, default docs/README.md) before following any doc path. Resolve the active program/initiative and the next incomplete task from the live documents; never infer current work from archive/. If the user names a task focus, use it as the override; otherwise take the worklist priority lead per ../protocols/references/worklist.md — never a bespoke ordering — and, within the chosen triad, its next unchecked task.

Step 2 — load context chain (in order, skip nothing)

1. The active-work doc the router resolves — current initiative, status, dependencies.
2. The task triad — spec.md, plan.md, tasks.md; find the next incomplete task (pending - [ ] or in-progress - [/], per the convention's task states) by its immutable <!-- task:slug --> ID, never by position or title.
3. Every linked reference/ contract and decisions/ ADR relevant to the task.
4. The agent roster from config agents.dir (if present) — read each agent file's description to know which roles apply to this task's domain.

A plan or spec is never evidence that behavior exists. Do not read archive material unless a live doc names a specific provenance need.

Step 3 — interview (plan phase)

Per ../protocols/references/questions.md: triage first — discoverable facts answered from code/docs (never reach the user); technical tradeoffs consult the adversary model, surfacing only on unresolved conflict; product/scope/ preference ALWAYS reach the user. Transport = chat by default (questions.transport); class-c always goes to the user. Cover approach and tradeoffs, ambiguities, edge cases, scope (narrow/expand), and dependencies on other tasks.

Flow mode exception: when invoked by flow (stage 2), grill already ran the interview at stage 1 — SKIP this step and execute the locked triad.

Step 3.5 — worktree (only when enabled)

Resolve worktree mode: --worktree/--no-worktree wins, else config workspace.worktree (default off). When ON, do this ONCE here, before spawning any teammate, per the worktree-mode contract in ../protocols/references/handoff.md: ask the user the path + branch (suggest worktrees/<task-slug> off the project root, new branch <task-slug>; initiative slug flattens to <program>-<NN-slug>), then git worktree add -b <branch> <path> <dev-base> (dev-base = release.branches.dev, default dev), gitignore the worktree dir, and make that path the designated tree for the rest of the run. Creation failure → halt and report; never silently fall back to the main tree. When OFF, the designated tree is the main working tree (this step is a no-op).

Step 4 — activate teammates

Discover the roster from config agents.dir; read each agent file's description to pick the roles relevant to this task (implementers, reviewers, test/quality, infra). Propose the team (roles + assigned files) to the user and wait for confirmation. Spawn them as subagents/teammates working in the run's designated tree — the main tree, or the task worktree from Step 3.5 when worktree mode is on (pass its absolute path in every spawn prompt; one shared worktree per task, never one per subprocess) — and monitor them per the liveness protocol (../protocols/references/handoff.md, "Liveness"): periodic progress checks, stalled teammate = stop + one fresh retry, second stall = that assignment fails loud, never hangs the run.

If no roster is configured, subagents are unavailable, or the user declines: work as a single agent, but apply each relevant role's checklist inline before considering the task done.

Step 5 — execute

• Project code constraints come from docs, not hardcoded here: read the conventions prose the config points at (docs.conventions, e.g. docs/CONVENTIONS.md). Honor it exactly.
• Tiered testing via config commands (argv arrays; first use of each command in a session requires explicit user approval):
  • after every change → commands.test (fast targeted suite);
  • at task completion → commands.testUnit + commands.lint;
  • integration-sensitive work → commands.testAll. A command absent from config → that tier is skipped; say so, never invent a command. Zero tolerance for failures at every tier: fix before proceeding, before marking done, before status updates.
• Write tests alongside implementation, not after — prefer the tdd skill (development mode: red-green-refactor) to drive each behavior.

Step 6 — adversarially verify

When the task is complete, the implementing provider must NOT verify its own work. Per ../protocols/references/cross-model.md + ../protocols/references/adversarial-review.md:

• Launch the OPPOSITE provider as a read-only reviewer (Claude impl → Codex; Codex impl → Claude). Never substitute a same-provider agent. If the opposite CLI is absent/unauthenticated/can't run the proof, stop and ask the user (fix+retry / continue single-model / abort) — never fake a second opinion.
• Give it the spec, the current diff, the applicable convention constraints, and the exact tier commands. Permit source reads + test runs; forbid edits, commits, implementation.
• Require a structured APPROVED / REVISE verdict with findings, evidence, commands run, residual risks. Burden of proof is on the diff; "no material objection found" is a valid, logged outcome.
• On REVISE, fix and resume the SAME reviewer session with the new diff. Loop until agreement or the five-round cap; when disagreement hinges on product intent, present both positions verbatim and the user decides. Persist each verdict to disk as it forms.

Step 7 — documentation

• Flow mode: do NOT mutate docs (single-owner rule). Emit drift_notes and decisions in the stage report frontmatter (../protocols/references/reports.md / ../protocols/references/handoff.md); the stage-7 librarian pass persists them. Return a compressed summary (≤ ~10 lines).
• Standalone mode: after verification passes, you MAY invoke librarian (no args) for full closeout — reconcile code/docs, promote knowledge, archive, regenerate nav. Re-run the matching test tier if librarian changed any behavior-governing artifact.

Hand the clean working tree to the user. Never commit, merge, rebase, or push — the user performs all git operations.

Persist and publish

Standalone runs write this report to .skills/supermodo/work/<YYYYMMDD-HHMMSS>.md per ../protocols/references/reports.md — a result living only in chat dies with the session. Then publish it:

node <skills>/reports/scripts/render.ts --root <project-root> --report <that path>

and NAME the page in your final message. Inside a flow run this does not apply: the stage report is the artifact and the orchestrator renders the one run page.

Sections, same order every run: What was built · Tasks closed (which tasks.md IDs moved, and to what state) · Verification (which tiers ran, which model verified, what it said) · Drift observed · Decisions taken · Left for the user.

Close the final chat message of a STANDALONE run with the board pointer, one line, last:

Board is stale (docs changed) — run `/supermodo:next`.

A standalone run moves task states in tasks.md, and usually runs a librarian closeout on top, so the board the user last saw is a snapshot of the state before this run. It is a POINTER (../protocols/references/worklist.md): no question, no consent gate, nothing auto-run — a board fires its own triage gate and must never do so unasked.

In flow mode this line is the orchestrator's, not the stage's: work mutates no docs there, and the run reports once at the end.

task is never omitted here. Work always runs against a triad — that is what makes it work rather than a patch — so the report carries the triad slug and the archive index links it to the item on the board. A work report with no task is a bug in the run, not a stylistic choice. When several tasks closed, a supermodo:bars of done / in-progress / remaining for that triad shows how far the item has moved; when only one did, the sentence is better than the chart.

Frontmatter: status is needs-input whenever the run stopped on a question (with it in questions), failed when verification did not pass, ok only when the tree is clean and the tiers are green.