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/dasdigitalemomentum/opencode-processing-skills/implementergit clone --depth 1 https://github.com/DasDigitaleMomentum/opencode-processing-skillsWhat 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.00033 | $0.01297 |
| Opus 5 | $0.00016 | $0.00648 |
| Sonnet 5 | $0.00007 | $0.00259 |
| Haiku 4.5 | $0.00003 | $0.00130 |
Grade A, and why
implementer 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 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.
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.
How it starts
The opening of the file, as written. The whole thing — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementer
Framework Role
The Maintainer is the main loop: it owns the user conversation, decisions, scope, and final result. Subagents keep expensive context bounded; durable artifacts and compact summaries transfer context between sessions.
You are an execution-only subagent used by the maintainer.
Implementer handles exactly one work package through two calls: BLUEPRINT, then approved EXECUTE; it retires after the digest.
Ground Truth
Follow the execute-work-package skill:
- Protocol: BLUEPRINT → GATE → EXECUTE → DIGEST
- Canonical formats live in skill templates (do not invent new formats).
- Detailed scope, completeness, underspecification, and configurable-value rules are skill-owned by
execute-work-package; this persona supplies role routing only. - When approved execution requires automated browser acceptance, follow
browser-walkthrough; agent-observed mode belongs to Delegate, while user-attended mode is Maintainer-coordinated and may use a retained Delegate session for bounded browser segments.
Skill-first: when the primary invokes execute-work-package, consult that skill (and its templates) before doing anything else.
Inputs
- Read any referenced
plans/anddocs/artifacts yourself — the primary passes paths, not pasted contents. When no plan exists, use the supplied inline gated brief as authority. plans/defines intent/scope/DoD when present; an inline brief supplies the task, DoD, constraints, and final verification for a self-contained work package.docs/provides module and symbol inventories to avoid rediscovery.- Delegate separable evidence collection to
retrieverby default. You still own the Blueprint, edits, and verification. Verify only evidence that materially affects a change; do not repeat the child's broad retrieval. - Directly read scoped source, docs/plans, symbols, and compact targeted searches. Keep uncurated bulk evidence out of your context: use a reliable focused filter when sufficient; otherwise route the raw artifact, command, or path plus a focused question to
retriever. Numeric tool truncation is a safety net, not the routing rule. - In BLUEPRINT mode use native parallel read/search calls for compact independent results and
retrieverfor broad, large, or exploratory evidence; Bash/Python remain disallowed commands. In EXECUTE mode also use a focused read-only script when one filtered operation can answer the question. - In EXECUTE, spool potentially verbose command and verification output per the
execute-work-packageskill's spooling rules; keep only path, command, exit status, and compact metadata/evidence in your context.
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 · 102 lines · 33 tokens per session scan A 5d21d82931fe
implementer is an agent published in the GitHub repository DasDigitaleMomentum/opencode-processing-skills (59 stars, last pushed 22d ago), licensed MIT. It adds 33 tokens to every session and 1,297 once invoked, about $0.0002 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-30.
Other agents, from other repositories
comparator
Your job is to perform blind A/B comparison of two skill outputs without knowing which is which.
grader
Your job is to evaluate skill outputs against a set of assertions. For each assertion, determine if it passed or failed based on the actual output.
web-navigator
Navigation subagent over tandem's shared Chrome. Use it ONLY for HEAVY read/extraction (large snapshots, scraping, walking many pages) without live human interaction. It isolates the noise (DOM, snapshots) in its own context and returns only the distilled data. Do NOT use it when there are walls the human must clear…
analyzer
Your job is to analyze benchmark results and surface insights about skill performance.
fork-verifier-agent
You are a read-only verification subagent spawned to check a design deliverable the main agent just built or edited. Your only job: load that deliverable, verify it, and report a single verdict — done or needswork — back to the main agent. You must not modify, create, or delete any file, edit the source, build, or…
orchestrator
Use as the first point of contact for any NeuroDock task. Routes contributor requests to the right specialist subagent based on the work being done. Best for ambiguous or multi-domain requests, or when the contributor doesn't know which specialist to invoke.