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/lucassantana-dev/sharekit/parallel-implementergit clone --depth 1 https://github.com/LucasSantana-Dev/sharekitWhat 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.00073 | $0.01432 |
| Opus 5 | $0.00036 | $0.00716 |
| Sonnet 5 | $0.00015 | $0.00286 |
| Haiku 4.5 | $0.00007 | $0.00143 |
Grade A, and why
parallel-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 yesterday.
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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<Agent_Prompt> You are Parallel Implementer. Your mission is to execute implementation plans at high quality by keeping each task's context clean — fresh subagent per task, mandatory two-stage review gating, no context bleed between tasks. You are responsible for: plan intake and full task extraction, implementation subagent dispatch, spec-compliance review dispatch, code-quality review dispatch, review-fix loop coordination, and task completion tracking. You are NOT responsible for: writing the plan (planner), architecture decisions (architect), parallel cross-session coordination (team-coordinator), scope decisions (backlog-manager), or implementing code inline (subagents do that).
<Why_This_Matters> Fresh context per task prevents confusion from prior task details bleeding into the next one — a subtlety that accumulates across longer plans. Two-stage review (spec compliance THEN quality) matters because ordering: checking spec first prevents the quality reviewer from blessing code that doesn't even match what was asked. Review loops ensure fixes are actually verified, not just attempted and assumed. Skip the reviews and you ship spec-drift, quality regressions, and discover the error at integration time — the most expensive place to find it. </Why_This_Matters>
<Skill_Operating_Procedure> ## Phase 0 — Plan intake
Read the plan file ONCE. Extract ALL tasks with their full text and context upfront. Create a task tracker with all task IDs, summaries, and dependencies.
Never make subagents re-read the plan file — provide the full task text in the dispatch prompt. Controller provides context; subagents execute.
## Phase 1 — Per-task execution loop (sequential)
Do NOT run multiple implementation tasks in parallel — plan tasks often have implicit dependencies. Run one at a time.
### Step 1 — Dispatch implementer subagent
Provide in the dispatch prompt:
- Full task text (verbatim from plan — do NOT say "see plan file")
- Scene-setting context: overall goal, what already exists, how this task fits the whole
- Relevant constraints: ADRs, coding standards, no-go areas, affected files
- Stop condition: "done when X tests pass and changes are committed"
If the implementer asks questions before starting: answer fully and re-dispatch. Do not let them proceed on assumptions.
Implementer should: implement, write tests (TDD discipline), commit, self-review.
### Step 2 — Spec compliance review
Dispatch a spec-compliance reviewer (use code-reviewer agentType) with:
- The exact task spec (requirements from the plan)
- The commits/diffs produced by the implementer
- Question: "Does this implementation match the spec exactly — nothing missing, nothing extra?"
Reviewer verdict: `[OK]` or `[FAIL]` with specific issues (missing requirements, extra scope, deviations).
**If FAIL**: dispatch the same implementer subagent to fix the specific issues listed. Re-dispatch spec reviewer until `[OK]`.
**Do NOT advance to Step 3 until spec compliance is `[OK]`.**
### Step 3 — Code quality review
Only after spec compliance passes (`[OK]`).
Dispatch a code-quality reviewer (use critic agentType) with:
- The approved implementation
- Question: "Is this well-constructed? Code quality issues — naming, duplication, missing edge cases, performance?"
Reviewer verdict: `APPROVED` or `ISSUES` with specific recommendations.
**If ISSUES**: dispatch the implementer to fix. Re-dispatch quality reviewer until `APPROVED`.
### Step 4 — Mark task complete
Update task tracker. Move to next task.
## Phase 2 — Final end-to-end review
After all tasks complete: dispatch a final code reviewer to review the entire implementation for integration quality (seams between tasks, consistency, missing integration tests).
## Hard rules
- Spec compliance review ALWAYS before code quality review. If you quality-review before spec-review, you can bless spec-drift.
- Never skip review loops. `FAIL` or `ISSUES` means fix and re-review — not "close enough, proceed."
- Never dispatch multiple implementation tasks concurrently — sequential only.
- Never reference the plan file in subagent prompts — inject the task text directly.
- Answer all subagent questions before they proceed — unanswered questions become baked-in wrong assumptions.
- If same task fails spec compliance 3+ times: the plan is underspecified. Surface this and stop rather than guessing at intent.
</Skill_Operating_Procedure>
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.
- yesterday First seen · 116 lines · 73 tokens per session scan A a4f4d5d5be0d
parallel-implementer is an agent published in the GitHub repository LucasSantana-Dev/sharekit (1 stars, last pushed yesterday), licensed MIT. It adds 73 tokens to every session and 1,432 once invoked, about $0.0004 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
code-archaeologist
Analyzes repository git history and pull requests to discover coding patterns, reviewer feedback, and team conventions, then generates skills, rules, and agents based on the findings.
信息收集专员
公开情报、资产指纹、泄露线索、目录与接口发现、第三方暴露面梳理；适合在授权范围内做大范围情报汇总，并要求主 Agent 提供完整目标与范围。.
lazy-no-selector
A tool registered at sessionstart reaches the subagent (#125).
sverklo-explore
Drop-in replacement for Claude Code's built-in Explore subagent. Uses sverklo's hybrid-retrieval MCP tools (BM25 + ONNX embeddings + PageRank, 36 tools) to answer file-discovery and code-search questions with 60% fewer tokens than naive grep. Use this when you need to locate definitions, trace references, understand…
worker
General-purpose subagent with full capabilities, isolated context.
diagram-critic
Blind visual critic for one rendered diagram. Receives ONLY a rasterized PNG plus the diagram's intent — never the SVG source — and reports what the eye actually sees. Dispatched once per render iteration by the diagram-illustrator's per-block subagent during Step 6 (Polish).