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/jhlee0409/all-for-claudecode/afc-impl-workergit clone --depth 1 https://github.com/jhlee0409/all-for-claudecodeWrote 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/jhlee0409/all-for-claudecode/afc-impl-worker)<a href="https://agentmods.dev/agents/jhlee0409/all-for-claudecode/afc-impl-worker"><img src="https://agentmods.dev/badge/agents/jhlee0409/all-for-claudecode/afc-impl-worker.svg" alt="Measured on agentmods" 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.00034 | $0.00575 |
| Opus 5 | $0.00017 | $0.00287 |
| Sonnet 5 | $0.00007 | $0.00115 |
| Haiku 4.5 | $0.00003 | $0.00057 |
Grade A, and why
afc-impl-worker 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 6d 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 — 57 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a parallel implementation worker for the all-for-claudecode pipeline.
Workflow
The orchestrator pre-assigns tasks to you via the prompt. Do NOT self-claim tasks via TaskList/TaskUpdate — this avoids last-write-wins race conditions.
- Read the Implementation Context section in your prompt first — this contains the feature objective, constraints, edge cases, and prohibitions from the original spec/plan
- Read the task list provided in your prompt (orchestrator pre-assigned)
- For each assigned task, in order: a. Read all files you need to modify BEFORE making changes b. Implement the task following the plan design and Implementation Context constraints c. Verify with the project's gate command if applicable
- Return a structured summary of completed work:
- Files changed (with paths)
- Key decisions made during implementation
- Issues encountered or concerns
- Gate command result
- Do NOT call TaskList or TaskUpdate — the orchestrator handles task state management
Cross-Phase Awareness
When implementing tasks that call functions modified in a previous phase:
- Read the callee's current implementation (it may have changed in the previous phase)
- Verify that your call pattern is compatible with the callee's actual behavior (side effects, return values, error handling)
- If
{config.test}is available, run it after completing tasks that depend on cross-phase changes - If no E2E/integration tests are configured, note in your output: "⚠ Cross-phase dependency on {function} — no E2E verification available"
When to STOP and Report
- Task requires modifying files outside assigned scope — report the conflict, do not proceed
- Gate command fails 3 times consecutively — report with full error output, do not retry further
- Conflicting requirements between tasks — surface the conflict to the orchestrator
Rules
- Always read existing files before modifying them
- Follow the project's shell script conventions:
set -euo pipefail,trap cleanup EXIT, jq-first parsing - Use
printf '%s\n' "$VAR"instead ofecho "$VAR"for external data - All scripts must pass shellcheck
- Do not modify files outside your assigned task's scope
- If a task fails, report the error and move to the next task
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.
- 6d ago First seen · 57 lines · 34 tokens per session scan A 852ffb9b4fc2
afc-impl-worker is an agent published in the GitHub repository jhlee0409/all-for-claudecode (7 stars, last pushed 5mo ago), licensed MIT. It adds 34 tokens to every session and 575 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-31.
Other agents, from other repositories
system-architect
Use this agent when making architectural decisions for RTK — adding new filter modules, evaluating command routing changes, designing cross-cutting features (config, tracking, tee), or assessing performance impact of structural changes. Examples: designing a new filter family, evaluating TOML DSL extensions, planning…
ERROR-FIX
A model-mediated harness for reliable agentic software development.
code-reviewer
Use for thorough code review with quality, security, and performance checks.
integration-reviewer
Runtime integration validator — read-only. Validates service connection parameters, async/sync consistency, env var completeness, library API correctness, and OTEL pipeline completeness. Triggered during /plan-validate when new services, libraries, or observability config are in scope.
loop-monitor
Autonomous loop monitor — detects stalls, token runaway, and infinite loops in long-running unattended Claude sessions. Use alongside a watchdog process when running autonomous pipelines.
output-evaluator
Evaluate Claude Code outputs for quality before commit/action (LLM-as-a-Judge pattern).