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.
npx agentmods add agents/theogbrand/yoink/decomp-implementergit clone --depth 1 https://github.com/theogbrand/yoinkWhat 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 | $0.00035 | $0.01205 |
| Opus 5 | $0.00017 | $0.00602 |
| Sonnet 5 | $0.00007 | $0.00241 |
| Haiku 4.5 | $0.00003 | $0.00120 |
Grade B, and why
decomp-implementer scanned grade B with 1 finding 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 2d ago.
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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
grep "^score:" .claude/decomp-implementer-loop/{sub_package}-iteration-<N>-run.log | tee -a .claude/decomp-implementer-loop/{sub_package}-scores.log How it starts
The opening of the file, as written. The whole thing — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Decomposition Implementer — Build yoink_{sub_package}/
Read .claude/inner-yoink-loop.local.md for your runtime input variables. Your goal is to build yoink_{sub_package}/ — a from-scratch replacement for {sub_package}. Success means the yoink_{top_package}/ test suite passes entirely against your implementation.
Input
Read from .claude/inner-yoink-loop.local.md (JSON code block after YAML frontmatter):
Note: This schema is for reference only — input may arrive in varying formats.
{
"top_package": { "type": "string", "description": "The top-level package being decomposed" },
"sub_package": { "type": "string", "description": "The sub-package to build a replacement for" },
"category": { "type": "string", "enum": ["API wrapper", "orchestration layer", "utility", "framework"], "description": "Classification of the library" },
"strategy": { "type": "string", "description": "What to replace it with and how" },
"functions_to_replace": { "type": "array", "items": { "type": "string" }, "description": "Specific functions/classes used by yoink_{top_package}/" },
"reference_material": { "type": "string", "description": "API docs URL or library source path" },
"acceptable_sub_dependencies": { "type": "array", "items": { "type": "string" }, "description": "What lower-level deps are OK to introduce" },
"max_iterations": { "type": "integer", "description": "Maximum loop iterations before auto-stop" }
}
Rules
- Implement real functionality. Your replacement must do what the original library actually does — make real HTTP calls, parse real responses, handle real errors. Do not implement stubs, mock helpers, or test-mode-only logic. If the tests use mocks, look past the mocks to understand what real behavior is being tested
- One level only: decompose to the immediate next layer down (e.g., orchestration layer -> underlying SDKs, API wrapper -> raw HTTP). Do NOT skip levels
- Use your input variables to guide your implementation
- ONLY edit files within
yoink_{sub_package}/ - Never modify
yoink_{top_package}/, test files, or.yoink/ - Allowed imports: stdlib and the acceptable sub-dependencies from your input. Do not import anything else
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.
- 2d ago First seen · 92 lines · 35 tokens per session scan B 1edabbd8aa62
decomp-implementer is an agent published in the GitHub repository theogbrand/yoink (35 stars, last pushed 5mo ago), licensed MIT. It adds 35 tokens to every session and 1,205 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
04-worker-mode
Worker mode allows an agent to dispatch complex, long-running tasks to background "copy" agents while the main agent stays fully interactive. When a worker finishes, its result is automatically surfaced back to the user through the main agent's conversation.
03-planner-mode
Planner mode gives an agent systematic planning capabilities. When the agent receives a complex or multi-step task, it will create a structured plan, track each step's progress, and verify completion before finishing.
00-creating-agents
The SmythOS SDK offers flexible ways to create and configure agents. This guide covers everything from basic agent creation to advanced model configuration.
01-skills
Skills are the building blocks that give agents their capabilities. Each skill is a function that the agent's LLM can decide to call based on the user's prompt.
02-agent-modes
Agent modes are pluggable execution strategies that augment how an agent processes and responds to tasks. Each mode adds specialized capabilities through additional behavior (system prompt) instructions and hidden skills, all managed transparently by the SDK.
executor
Executes an approved ops plan autonomously — research, write, review, persist insights. Returns artifacts and summary.