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 skills/kimon1230/claude_extensions/implement-batchnpx skills add kimon1230/claude_extensions --skill implement-batchgit clone --depth 1 https://github.com/kimon1230/claude_extensionsWhat 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.00026 | $0.01515 |
| Opus 5 | $0.00013 | $0.00758 |
| Sonnet 5 | $0.00005 | $0.00303 |
| Haiku 4.5 | $0.00003 | $0.00152 |
Grade A, and why
implement-batch 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implement Batch
This skill must only be invoked from the main session, never from a subagent.
Arguments: <plan-file> <batch-number> (optional — will prompt if not provided)
-
Identify the plan and batch: a. If the user specified a plan file and batch number, use those. b. Else determine the project name: check
origingit remote (parse last path component, strip.git) → git root basename → working directory basename. c. List files in~/.claude/plans/<project-name>/, sorted by modification time. If no plans found, tell the user and stop. d. If no batch number specified, read the plan and identify the next unimplemented batch. Confirm with the user: "I'll implement Batch N of<plan-file>. Correct?" -
Read the plan and extract the batch spec:
- Identify all modules/components in the target batch
- Note dependencies between modules within the batch (some may need sequential implementation)
- Note dependencies on prior batches (verify those are already implemented)
- Read existing source files that the batch modifies or depends on
- Complexity gate: Before spawning subagents, check each task. Flag a task as "likely too complex for a single subagent" if it meets any 2 of these 3 conditions: touches >5 files, has >3 acceptance criteria, has cross-module dependencies. Present the flag to the user with a recommendation to split. Not a hard gate — the user can override and proceed.
-
Spawn parallel subagents for independent modules:
- Spawn each implementer on the latest, most capable model available — omit the per-agent
modeloverride so each inherits the session's model rather than pinning a version-specific name. Don't downgrade to a cheaper tier. (CLAUDE_CODE_SUBAGENT_MODEL, if set in the environment Claude launches subagents under, overrides the inherited model.) - Each subagent receives: the plan section for its module, relevant existing source files, and the project's testing conventions
- Each subagent's prompt MUST include these instructions verbatim:
Implement the specified module per the plan. Also write comprehensive tests targeting 100% coverage of the new code.
Follow existing project conventions for: file layout, naming, imports, docstrings, type hints.
After writing code and tests, report back with:
- Files created: list with brief description
- Files modified: list with what changed
- Test count: number of tests written
- Open questions: anything ambiguous in the plan that you resolved with a judgment call
- Status: exactly one of:
STATUS: DONE(complete, tests pass, no concerns),STATUS: DONE_WITH_CONCERNS(complete and tests pass, but you have doubts — list them),STATUS: NEEDS_CONTEXT(cannot proceed — specify exactly what information is needed),STATUS: BLOCKED(technical blocker — describe it)
- For modules that depend on other modules within the same batch, implement them sequentially after their dependencies complete.
- Spawn each implementer on the latest, most capable model available — omit the per-agent
-
After all subagents complete — triage:
- Handle implementer status for each subagent:
STATUS: DONE→ accept, proceed to 4b.STATUS: DONE_WITH_CONCERNS→ read concerns, re-read affected files, decide whether to accept or add to failure list. Do not silently ignore concerns.STATUS: NEEDS_CONTEXT→ provide missing context, re-dispatch the subagent for the same module (max 1 re-dispatch; if the subagent returnsNEEDS_CONTEXTagain, treat asBLOCKED).STATUS: BLOCKED→ add to failure list in step 5.
- Completion contradiction detection: Scan accepted subagents' summary sections (Files created, Files modified, Test count, Open questions) for contradiction patterns. Heuristic exclusion: skip matches inside triple-backtick fenced code blocks only; inline single-backtick spans are NOT excluded. Patterns to flag:
- "requires manual" / "manual step needed" / "manually run"
- "could not complete" / "unable to" / "cannot be automated"
- "TODO" / "FIXME" / "placeholder" (in subagent's own prose, not in quoted code)
- "skipped" / "deferred" / "left as-is" for items that were in scope
- "should work" / "probably works" / "untested" for claimed completions If a contradiction is detected: re-read the specific files the subagent modified. If real, add to failure list in step 5. If ambiguous after one read pass, treat as failure — do not loop.
- Handle implementer status for each subagent:
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 · 81 lines · 26 tokens per session scan A 4ad659a32b46
implement-batch is a skill published in the GitHub repository kimon1230/claude_extensions (4 stars, last pushed 1mo ago), licensed MIT. It adds 26 tokens to every session and 1,515 once invoked, about $0.0001 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 skills, from other repositories
hook-template
Generate hook script from template. Use when adding a new hook, wiring a PreToolUse/PostToolUse/Stop/Notification hook, or scaffolding hook config for settings.json.
skill-check
Validate skill/command file format and structure. Use after creating or editing a skill, before committing skill changes, or when a skill fails to load or trigger.
check-environment
Verify Claude, Codex, and Grok availability plus Director guidance, relay, agents, and skills. Audit optional hooks only when selected. Use after installation or when a native surface misbehaves.
code-reviewer
Code review knowledge base: quality, security (OWASP Top 10), error-handling, performance, and test-coverage checklists with severity-ranked output format. Use when reviewing code changes, PRs, or before commits. Loaded automatically by the code-reviewer agent.
agents
List all available agents (core, expert, self-evolving). Use when the user asks what agents are available or runs /agents.
handoff-gemini
Delegate long-context analysis, research, and large-document summarization to Google Gemini CLI (1M-token context) via non-interactive gemini -p, preserving Claude context. Use when the user says 'use gemini'/'hand off to gemini' or a task needs 100K+ tokens of context.