Task

A skill runs only when something loads it, and this one is a skill: load it with the Skill tool, never through a host tool named Task. Pick the task's route and work through its steps, loading each step's skill when the step starts. A route names skills; each skill owns how its step is done.

Pick the route

1. Read the request and the repo's rules and conventions: its AGENTS.md or CLAUDE.md, CONTRIBUTING, recent history and merged pull requests. Every task in every repo runs the same way: it works on a topic branch in its own worktree, commits each slice there once design-review accepts it, editing nothing for the next slice until that commit is made, since an accept holds only for the uncommitted changes exactly as they were judged, and lands as a whole once review by one fresh agent accepts the branch; slices never land on the default branch one by one. The repo's rules decide only the rest: branch naming, whether and when the branch is pushed, rebase or merge onto the branch it lands on, commit style, and the landing route, straight to the default branch by a fast-forward or merge as the repo does it, or a pull request through pr. Where those leave a choice open, ask the user once instead of guessing; a worker asks whoever coordinates it. A repo skill that covers a step takes that step's place; the topic branch, its per-slice commits and landing as a whole still hold.
2. Match the route by what the task changes, read from the code it names, not by its wording. A code change always has a route. A change to a skill or agent goes through skill-writing, then Close. A task that changes no code, such as a question, goes straight to its own skill; a doc edit goes to docs-writing, loaded before the doc's first edit.
3. Load each step's skill with the Skill tool when the step starts: this set's skill, not a host skill or tool that shares its name. Skip a step only when its work does not arise, such as second-opinion on a design the owner's brief decided rather than one the agent proposed, or one already challenged; a change that looks small still takes every step its work reaches.
4. design-review runs in a fresh agent that did not write the work, briefed with the diff or design in a file it reads, each file named in the brief by its absolute path and written to the worker's own temp folder so a parallel worker cannot overwrite it, and every decision the owner settled, a plan included. Wait for its verdict before going on. A return's findings are all fixed and re-reviewed until accept, which comes only when no finding stands; each re-review is another fresh agent given the fix's diff, the change since the diff that returned, in a new file, to judge alone, and the change's earlier diff files to read as context so its accept covers the whole change, never a message to the agent that returned, for review as for design-review. Lines an earlier review of the change read and did not flag, whether it accepted or returned, are accepted: a re-review that disagrees with them puts that under Conflicts, which does not return. After a third return on one commit, stop fixing that commit: save its diff in your temp folder, go on with the commits that do not depend on it, and report it to whoever coordinates you, or else the owner, with each return's findings. The branch lands without it only when it fixes nothing the branch introduced; otherwise the branch waits for whoever coordinates you, or else the owner. On how the code is built, design-review wins over other reviewers; any other disagreement, such as a finding that clashes with a settled decision, goes to the owner as a conflict, not a finding.
5. Re-route when the task changes kind, and say so.
6. Fix every finding in reach rather than filing it: a review's finding about code no diff of the change touches still returns the change, but its fix is a commit of its own that carries only that code, reviewed alone and made before the returned change, whose re-review then takes that commit's diff as the fix, so the change's own diff never grows to cover a neighbor; neighboring code found any other way lands in its own commit too, through the same commit steps. Another agent's work on the owner's machine is in reach. Only an owner decision, or a change another person owns, goes to the report. Scope decides where a fix lands, inside the change or in its own commit or branch started at once, never whether it lands.
7. Stop at a defect in a tool, hook or gate rather than working around it: when one refuses correct work or misbehaves, report it, with the command and what it said, to whoever coordinates you, or else the owner, and go on only with work it does not block. Rewording a command until a check stops matching it, or reshaping a change to slip past a gate, is a workaround.
8. Coach the task once it lands or stops. A delegated worker runs no coach: it states its report in a message, so its transcript keeps it if the run is cut short, and hands back, and its caller coaches the task. A task in the main session coaches itself as its last step, in a fresh coach agent where the host has one, else in a fresh agent loading workflow-review, scoped to this task's sessions, yours and your subagents', then applies its proposals except conflicts, which go to the owner, opening an experiment for each change where coordinate calls for one.
9. Re-enter the route when the host resumes or forks the session: the session still holds its own context, so load task again, rebuild the route and step from the checkout (git worktree list, git status, git log), then load the current step's skill, and code-writing before any further edit. A plan that lives only in a message goes to the repo first. Picking up another session's work is coordinate's resume, not this.

Report