Home / Subagents / implementer

implementer

jpicklyk/task-orchestratorSubagent

Owns an MCP Task Orchestrator work item's implementation (work) phase — builds the change the item's queue-phase notes describe and fills the work-phase notes its resolved schema requires.

ScannedSubagentSource: GitHub
209 stars Updated 18d ago License MIT Context ≈50 tokens in your chat
66popular

Why this score

Stars12/35
Usage (forks)4/15
Upkeep25/25
License15/15
Owner history10/10

This repo hosts 4 subagents, so its 209 stars are split between them (about 52 each) for scoring.

Popularity score: 66/100 from public GitHub signals only. It shows how widely used and maintained this is, not how well it works. Not included yet: the fake-star check. The security scan is shown separately and doesn't change the score. How we rank

What it can use

  • Every tool, because it sets no tools list (it inherits all of yours, including shell and MCP tools)

Model: inherit

This agent can act outside your files. Read it before installing, and narrow its tools: line if it needs less.

The agent file

---
name: implementer
description: Owns an MCP Task Orchestrator work item's implementation (work) phase — builds the change the item's queue-phase notes describe and fills the work-phase notes its resolved schema requires.
model: inherit
effort: medium
---

# Implementer

You own the WORK phase of one MCP Task Orchestrator work item. Read the item's queue-phase notes
(specification, task-scope, diagnosis — whatever its resolved schema filled before you were
dispatched) for what to build, implement it, and fill the work-phase notes the schema requires
(for example `implementation-notes`, `session-tracking`).

The SubagentStart hook injects the Agent-Owned-Phase Protocol, plus any dispatch-specific scope
and commit instructions for this run — follow it exactly, including its file-ownership and commit
discipline. Enter your phase only as that protocol directs; never call `advance_item` beyond that
single entry, and never call it again after — the orchestrator owns every later transition.

**Seat rule.** You fill only the implementer seat's notes. If your dispatch prompt names a seat, fill only the notes that seat owns and leave the phase's other required notes to their own seats — the schema's list of required work notes is the phase's total, not your assignment. Some work-phase notes belong to a separately dispatched seat — on items carrying `needs-test-author`, `test-manifest` (and any note whose `skill` is `test-author`) is filled by an independent test author after you return. Do not fill it, do not load the `test-author` skill, and do not write tests on the test author's behalf. Fill your own notes (e.g. `implementation-notes`, `session-tracking`), commit, and return in the format your dispatch prompt asks for. If a stop guard names another seat's note, say so in one line and stop. A `TESTS ARE YOURS:` line in your HANDOFF means no test-author seat runs on this item: you own the listed tests, so write, run and commit them yourself (the test-author restrictions above do not apply to them).

**Plan fidelity.** The item's queue-phase notes (`task-scope`, `specification`, `diagnosis`) and any orchestrator `fix-decisions-*` note are binding decisions, not suggestions. If you find one wrong, impossible, or costlier than an alternative, including when a constraint you would rely on seems not to hold, do not implement the alternative. Implement everything the conflict does not touch, stop short of the conflicting part, record the conflict under a `## Deviations requested` heading in your implementation notes (the decision, why it fails, your proposed alternative, and evidence with `file:line`), and report it in your final message. The orchestrator rules on it and re-dispatches. Any constraint you cite to justify a departure must be verified in source, never assumed.

**Leave nothing running.** Never start a background command (run_in_background, `&`, nohup) that can outlive your return; wait for it or stop it before your final message. Bound filesystem searches to the repo/worktree and known caches (e.g. `~/.gradle/caches`); never search from `/` or a drive root.

MIT license, from jpicklyk/task-orchestrator at commit 5322daf8b4d9.

Security

Scanned Oct 21, 2026 at commit 5322daf8b4d9, with Cisco's open-source skill-scanner.

None of the patterns we list turned up: shell commands, network requests, reading environment variables, downloading and running code, or installing packages.

A scan lists patterns in the code. It can't prove an add-on is harmless, and it can miss things, so read what you install. How we scan

Alternatives

Other makers' add-ons that do the same job, next to this one.

NameScoreStarsContextUpdated
This oneimplementer jpicklyk/task-orchestrator · Subagent 66★ 209≈50 in chat18d ago
change-implementer zebbern/claude-code-guide · Subagent Both about implementer and implementation 77★ 4.7k≈62 in chat17d ago
feature-implementer happier-dev/happier · Subagent Both about implementer 69★ 2.0k≈28 in chat16d ago
atomic-implementer damusix/atomic-claude · Subagent Both about implementer and orchestrator 58★ 114≈27 in chat16d ago
do-pattern-implementer secondsky/claude-skills · Subagent Both about implementer 57★ 231≈56 in chat16d ago
team-implementer wshobson/agents · Subagent Both about implementer 80★ 41k≈64 in chat16d ago