/developer

name: developer
description: Orchestrates unattended spec delivery — loops over a spec's child issues in dependency order, dispatching dispatcher (complexity triage), code-author (implement), and diff-reviewer (review) workers per sub-issue, with a review→fix cycle until CLEAN, then merging per the repo's merge policy. Tracker- and host-agnostic — issues and changes live wherever docs/agents/issue-tracker.md and docs/agents/code-host.md say (GitHub via gh is the factory default). Factory defaults are parallel execution and manual merge; repo defaults live in docs/agents/developer-defaults.md and per-run flags (--parallel/--sequential, --auto-merge/--no-auto-merge) override them. Use when user says "/developer", "deliver this spec" (or "deliver this PRD"), "deliver this sub-issue", or wants the build→review→fix pipeline.

Developer (orchestrator)

Drives the triage → build → review → fix → merge pipeline across isolated subagent workers, looping over every sub-issue of a spec unattended. Each worker gets a **clean context** — the only thing it knows is the arguments you pass in its prompt. You (the orchestrator) hold the state between steps.

Invoke

/developer <issue>              # spec with sub-issues → deliver them all
                                # plain issue → deliver just that one
/developer <spec> <subissue>    # deliver a single specific sub-issue

Flags (override the repo defaults — see Run configuration):
  --parallel | --sequential     # spec mode: waves vs one-at-a-time
  --auto-merge | --no-auto-merge  # merge CLEAN PRs vs leave them ready
  --build-oversized             # build `oversized` tickets instead of escalating

If no issue number is given, ask for it and stop. Do not guess issue numbers. The execution flags only change spec mode; in single mode they are a no-op. Accept the bare words `parallel` / `sequential` as synonyms for the flags.

> **Namespacing.** Installed as a Claude Code plugin, skills and agents carry > the plugin prefix: the skills appear as `developer-skills:<name>` and the > subagents as `developer-skills:dispatcher` / `developer-skills:code-author` / > `developer-skills:diff-reviewer`. Use the names exactly as they appear in > your available-skills and available-agents lists; the short names below > refer to whichever form is installed.

Contract docs (tracker + code host)

The pipeline is agnostic about where issues and changes live. Two committed docs define the mechanics for this repo, and every worker reads them in its own context:

• **`docs/agents/issue-tracker.md`** — issue operations (read an issue,

enumerate children of a parent, check a blocker, comment, label, close) in its `## Delivery operations` section.

• **`docs/agents/code-host.md`** — change operations (publish, check out in

a worktree, review, mark ready, reply, merge, auto-close semantics).

Read those two once at the start (they are short — an allowed exception to "never read bodies yourself").

**Their annexes are deferred, and every worker inherits that.** Each core doc links phase annexes naming the phase that opens them: `code-host-ci.md` is opened at the **checks gate**, when a change's CI has to be waited on, read or classified — nowhere earlier; `issue-authoring.md` is for whatever *creates* issues (`/to-tickets`) and this pipeline never opens it at all. Read an annex at the step that names it and not before. A run that opens them at the start pays the whole contract, three workers deep, per sub-issue, to use a fraction of it. **Every command block below shows the GitHub factory default (`gh`); when a contract doc defines a different mechanic for the same operation, the doc wins.** If a doc is missing, the GitHub defaults apply as-is — suggest `/setup-developer-skills` if that looks wrong.

Note one capability flag from `docs/agents/code-host.md`: **issue auto-close on merge?** If not (e.g. issues on a tracker the code host can't close), the orchestrator closes the delivered issue itself per the tracker ops right after verifying the merge.

**If either doc says the tracker or the code host is `local` (files in the repo, no remote), read `LOCAL-HOST.md` now, before anything else.** It holds every standing adjustment a local host or tracker needs — capability overrides, tracker writes, branch discipline, cleanup and wrap-up. A run on a remote host never loads it.

Two more files are read **on demand**, never at the start: `MERGE-FIX.md` at the first merge conflict, and `WRAP-UP.md` when the loop ends.

(All three live **next to this SKILL.md**, in the skill's own directory — under the plugin root when installed as a plugin, the same place `scripts/cleanup-worktrees.sh` comes from. They are part of this skill: a step that says to read one is not optional, it is that step's other half.)

Run configuration

Three knobs govern a run. Resolve each one **before mode detection**, in this precedence order: CLI flag > repo default > factory default.

| Knob | Values | Factory default | |-------------|---------------------------|-----------------| | `execution` | `parallel` / `sequential` | `parallel` | | `merge` | `auto` / `manual` | `manual` | | `oversized` | `escalate` / `build` | `escalate` |

Repo defaults live in `docs/agents/developer-defaults.md`, written by `/setup-developer-skills`. Read it once at the start (it is short — this is an allowed exception to "never read bodies yourself"); if it is missing or a knob is absent, fall back to the factory default. State the resolved configuration in one line before starting, e.g. `Run config: execution=parallel, merge=manual (repo defaults)`.

What `merge` means:

• **`auto`** — a CLEAN verdict triggers the code host's merge operation

(Merge step; `gh pr merge` on GitHub). The committed `merge: auto` line in `docs/agents/developer-defaults.md` is the user's standing authorization for these merges.

• **`manual`** — the pipeline stop