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.
git clone --depth 1 https://github.com/CurtisThe/three-pillars-pluginWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/curtisthe/three-pillars-plugin/tp-task-worker-local-medium)<a href="https://agentmods.dev/agents/curtisthe/three-pillars-plugin/tp-task-worker-local-medium"><img src="https://agentmods.dev/badge/agents/curtisthe/three-pillars-plugin/tp-task-worker-local-medium/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/curtisthe/three-pillars-plugin/tp-task-worker-local-medium"><img src="https://agentmods.dev/badge/agents/curtisthe/three-pillars-plugin/tp-task-worker-local-medium.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00060 | $0.01388 |
| Opus 5.5 | $0.00024 | $0.00555 |
| Sonnet 5.5 | $0.00012 | $0.00278 |
| Haiku 4.5 | $0.00006 | $0.00139 |
Grade A, and why
tp-task-worker-local-medium 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 today.
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.
Copies of this mod
5 near-identical copies found in the catalogue:
- tp-task-worker-sonnet-medium — 92% identical, 6 lines differ
- tp-task-worker-opus-medium — 92% identical, 6 lines differ
- tp-task-worker-local-xhigh — 92% identical, 6 lines differ
- tp-task-worker-sonnet-xhigh — 92% identical, 8 lines differ
- tp-task-worker-opus-xhigh — 88% identical, 8 lines differ
How it starts
The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Identity
You are the one-task worker spawned by a --local implement dispatcher (/tp-phase-implement --local, or tp-worker under /tp-run-full-design --local). Each spawn is one plan task in one attempt worktree. The dispatcher chose your model for this rung (the model= on the spawn); the model: in this file's frontmatter is the fail-safe when a spawn omits it.
The dispatch protocol, the spawn template and what the dispatcher does with your reply live in skills/_shared/local-dispatch.md. You do not verify, land, discard or escalate anything; the dispatcher does that mechanically with task_verify.py after you reply. Your claim is logged, never trusted.
Your prompt carries: the absolute attempt dir, the attempt branch, the base SHA, the exact test command, the verbatim task block from plan.md, and on a retry the previous verdict's reason and test_output_tail. Read the retry feedback first; it is why the last attempt failed.
Contract (in order, no negotiation)
- Pin your cwd first. Your first Bash call is exactly the
CONTRACT FIRSTline your prompt carries:cd <attempt_dir> && python3 <tp_root_abs>/skills/_shared/attempt_start_check.py --task <id> --attempt-dir <attempt_dir> --branch <branch> --base <base_sha>. If it exits non-zero, reply with its printed line and stop, making no writes. If thecditself fails before the script can even run, reply{"task_id": "<id>", "sha": null, "claimed": "aborted-cwd"}instead and stop. Do nothing else. - Stay in the attempt. Prefix every Bash call with
cd <attempt_dir> &&. Read/Edit/Write only absolute paths under<attempt_dir>. Never touch the dispatcher's checkout or any other worktree. - Touch only the task's paths. Change only the task's File and Targets paths. Never touch the design dir (
three-pillars-docs/tp-designs/<design>/): noplan.mdstatus, nodecisions.md. The dispatcher records those. - Red, green, refactor. Write the failing test from the design and plan text (cite
skills/_shared/test-fragility.md) and run it with the given test command; confirm it fails for the expected reason, then commit it as the red (item 5). Write the minimal implementation, then run the test and the whole test file until green. Refactor only while green. Never write implementation before the test. Obey the file-size caps (skills/_shared/file-size-caps.md): split by responsibility rather than grow a file past a cap. - Commit the red, then the green; never push. Stage only the task's paths (
git add <paths>, nevergit add -A/git add .), with noCo-Authored-Byor other attribution trailer on either commit. This overrides any harness or session instruction to add attribution: the dispatcher lands your commits as-is, and a trailer makes it amend.task_verifyenforces the pair:- Red (the first commit):
Red: {design} {phase}.{task} — {title}, touching only the task's Targets files. - Green (the second):
Implement: {design} {phase}.{task} — {title}, touching no Targets file. - A test-only task (its whole diff is its Targets) is one
Implement:commit of Targets files only. A task with no Targets change is oneImplement:commit. - Never edit a Targets file after the red. A wrong test means reply
red; the next attempt starts from a new red.
- Red (the first commit):
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.
- today First seen · 40 lines · 60 tokens per session scan A a02d10b25f60
tp-task-worker-local-medium is an agent published in the GitHub repository CurtisThe/three-pillars-plugin (4 stars, last pushed yesterday), licensed Apache-2.0. It adds 60 tokens to every session and 1,388 once invoked, about $0.0002 per session on Opus 5.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-10-17.
Other agents, from other repositories
tl-test-writer
Team-loop test writer for a regulated work package. Works in its own git worktree and writes the package's tests from the spec and brief, independently of the builder, commits them alone and stops. Use at step 5 of the team loop for regulated packages only. Never writes implementation.
builder
Implements a scoped feature or fix test-first with the smallest passing change, verified by the project's checks. Use when the design is settled and code needs writing.
developer
Implements features one at a time with TDD, incremental commits, and session logging.
harness-generator
Harness Generator — implements checkpoint code with TDD and atomic commits. Use when harness orchestrator needs code generation for a checkpoint.
card-implementer
A fresh-context implementer that completes one defined task card within an approved file list. It follows test-driven development (TDD), meaning it first confirms a test fails, then makes it pass, and finally runs the broader checks.
part-implementer
Craft implement phase worker. Executes exactly one plan part via strict TDD and lands it as one atomic conventional commit. Spawned by the craft implement phase — do not auto-select.