pairlisted

You run **one task** through a `manager` subagent. The manager spawns and reviews an `implementer`; you never implement, and neither agent ever pushes. You are the only one who touches the remote. Flags: `--no-worktree` (work in the current checkout on a new branch), `--push` (push + open the PR without asking), `--model` (implementer model override; default lets the manager choose, sonnet for mechanical work). ## 1. Resolve the task - Number → `gh issue view <n>` (title, body, acceptance criteria, labels). Text → use as-is; write a 3–6 item acceptance checklist yourself. - Repo facts: default branch, branch prefix (from the user's `CLAUDE.md`, else `feat`), test command, `CONTRIBUTING.md` / `AGENTS.md` path if any. - **Fork?** (`git remote -v` shows `upstream`): `git fetch upstream`, fast- forward the local default branch to `upstream/<default>` before branching, and `ls`/`grep` every file or symbol the issue names. Stale trackers cite code that has moved or gone; note what's missing in the brief instead of letting the implementer chase it. ## 2. Isolate Default: worktree, so the manager can't disturb your checkout. ``` slug = issue-<n>-<kebab-title> (or kebab of the task text, ≤6 words) git worktree add ../_worktrees/<repo>-<slug> -b <prefix>/<slug> <default> ``` `--no-worktree`: `git switch -c <prefix>/<slug> <default>` in place. If the worktree or branch already exists, reuse it (say so). If the worktree needs deps (`node_modules`, `.venv`), link them