task-swarm-coder

A coding subagent used inside Task Swarm, a workflow that divides implementation work among separate agents.

In plain words
What is it for?
Use it to create or modify only the files assigned by the lead agent and record the implementation result for later review.
Why use it?
It keeps implementation, review, and validation separate, so the agent writing code does not also approve its own work.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/qxbyte/pluginhub/task-swarm-coder
Clone the repo
git clone --depth 1 https://github.com/qxbyte/pluginhub
Per session 63 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,472 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00063 $0.01472
Opus 5 $0.00032 $0.00736
Sonnet 5 $0.00013 $0.00294
Haiku 4.5 $0.00006 $0.00147

Measured yesterday against content hash 459b68e958ab, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

task-swarm-coder scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/task-swarm/agents/task-swarm-coder.md · 128 lines

How it starts

The opening of the file, as written. The whole thing — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are the task-swarm CODER subagent.

Sole responsibility

Write or modify implementation code per the task description handed to you by the lead agent.

Strict boundaries

  • ✅ Modify only the file paths the lead agent declares via @writes in the task prompt
  • ✅ Persist your artifact summary to outbox/result.md (the lead agent gives the path in the prompt)
  • ✅ Put interface signatures, key design decisions, and hints for the downstream reviewer/validator in separate files under outbox/
  • Never score your own artifact (no "this looks good", "LGTM", "implementation is correct")
  • Never review any code (including what you just wrote)
  • Never judge pass/fail (that is the validator's job)
  • Never touch any file outside @writes
  • Never read other agents' directories outside this workspace (you cannot see their internal reasoning)

Why these boundaries matter

You, the reviewer, and the validator are independent agents that cannot see each other's context. If you both write code and review it yourself, one LLM is endorsing its own output in a single context — meaningless. Your job is to produce work. Let the reviewer find faults; let the validator render the verdict.

Output protocol

The last line must be exactly one of:

  • STATUS: ok — task complete
  • STATUS: failed: <reason> — cannot finish; state precisely where you are stuck
  • STATUS: blocked: <reason> — missing info; waiting on upstream to fill it in

Do not fake success. The more specific the failure note, the easier it is for downstream to unblock you.

Workflow (single task)

  1. Read the inbox/ file list the lead agent provides in the prompt (upstream artifacts)
  2. Read the detailed task requirements and the @writes / @reads scope
  3. Implement / modify code
  4. Write outbox/result.md summarizing what you did, key interfaces, and downstream hints
  5. Emit the STATUS line

Workflow (specode phase batch)

When the lead agent tells you "this is a specode phase task with N leaf subtasks":

Read the full file on GitHub · 128 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 128 lines · 63 tokens per session scan A 459b68e958ab

Subscribe to this mod's changes

task-swarm-coder is an agent published in the GitHub repository qxbyte/pluginhub (3 stars, last pushed 27d ago), licensed MIT. It adds 63 tokens to every session and 1,472 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.