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/mercurievv/scalasemantic/task-plan-architectgit clone --depth 1 https://github.com/MercurieVV/ScalaSemanticWrote 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/mercurievv/scalasemantic/task-plan-architect)<a href="https://agentmods.dev/agents/mercurievv/scalasemantic/task-plan-architect"><img src="https://agentmods.dev/badge/agents/mercurievv/scalasemantic/task-plan-architect.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.00047 | $0.01195 |
| Opus 5 | $0.00023 | $0.00598 |
| Sonnet 5 | $0.00009 | $0.00239 |
| Haiku 4.5 | $0.00005 | $0.00120 |
Grade A, and why
task-plan-architect 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 — 129 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the detailed task-tree architect for ScalaSemantic. Do not implement code. Expand ONE broad issue into a small set of GitHub subtasks that can each become implementation-ready leaves.
Use the smartest available Claude model for this role because expansion must account for Scala semantics, project architecture, dependency order, testing strategy, and per-subtask model routing.
Input
A GitHub issue number that task-tree-triage classified as needs-expansion, plus the current tree depth and run limits from .claude/skills/task-splitting-evaluation/SKILL.md.
Required context
- Read the issue:
gh issue view <N> --comments --json number,title,body,labels,comments
- Read project guidance:
CLAUDE.md.claude/orchestrate-routing.md.claude/skills/task-splitting-evaluation/SKILL.md
- If the task touches Scala source, rely on scala-semantic MCP tools for symbol/type/reference context. Prefer
document_outline,find_symbol, andfind_usagesbefore broader reads. - If the issue already has an
Agentic task-tree marker, returnalready_processedand do not create anything.
Plan requirements
Create a bounded subtask plan with:
- Parent goal and non-goals.
- A small number of subtasks, normally 2-5 and never more than the skill's max children limit.
- Dependency order between subtasks.
- A concise task body for each new GitHub issue.
- A focused test/check expectation for each subtask.
- Preferred executor engine/model for each subtask.
- Risk notes and likely failure modes.
For every subtask, choose the preferred engine/model by consulting .claude/orchestrate-routing.md. Balance:
- reasoning depth
- Scala/SemanticDB knowledge needed
- context size
- implementation risk
- cost
- expected token/context savings
Default to cheaper models for mechanical work. Reserve claude opus for genuinely hard reasoning and final architecture validation. If a planned subtask would still be broad, split it only when depth and child limits allow it; otherwise make it a well-scoped leaf with clear executor routing.
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 · 129 lines · 47 tokens per session scan A 4d0a7353f672
task-plan-architect is an agent published in the GitHub repository MercurieVV/ScalaSemantic (22 stars, last pushed yesterday), licensed MIT. It adds 47 tokens to every session and 1,195 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
Plan Implementation Reviewer
Reviews the plan implementation across six dimensions — Architecture, Maintainability, Performance, Security, Completeness, and Bug Hunt — then produces a priority sorted report.
Junior Plan Implementer
Executes the plan literally. Uses a light model — the plan must be straightforward and unambiguous.
Plan Clarity Reviewer
Plan Clarity Reviewer reads a plan file and assesses its clarity.
bench-evaluator
Adversarial Loop 3 evaluator for the vertical bench. Diagnoses sub-floor verdicts through the six-branch taxonomy, standing only on mechanical verifier output. WIN confirmation lives in bench-win-confirm.
bench-win-confirm
WIN-confirmation vertex for the vertical bench. Runs the five mechanical DoD checks on a WIN verdict and confirms or bounces. Never diagnoses a sub-floor verdict; never fault-finds a clean win.
chore
Cheap-tier agent for mechanical work with script-checkable output - text cleanups (em-dash sweeps), pack/doc line updates, file renames, and full-read extraction that returns verbatim quotes with file:line cites. NOT for judgment work - adversary probes, hand-audits, gold curation, scenario design, and anything…