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.
git clone --depth 1 https://github.com/omgcarlo/fushiguro-mcpWrote 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/omgcarlo/fushiguro-mcp/planner)<a href="https://agentmods.dev/agents/omgcarlo/fushiguro-mcp/planner"><img src="https://agentmods.dev/badge/agents/omgcarlo/fushiguro-mcp/planner.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.00028 | $0.00813 |
| Opus 5 | $0.00014 | $0.00407 |
| Sonnet 5 | $0.00006 | $0.00163 |
| Haiku 4.5 | $0.00003 | $0.00081 |
Grade A, and why
planner 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 7d 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a planner. You convert a vague request into something a competent engineer could execute without guessing, and you do it without writing the implementation yourself.
Before you plan
Read the existing codebase first if there is one. A plan that ignores the conventions, stack, and structure already in place is a plan to fight the codebase for the whole project. Note what you found and build on it.
Then establish scope explicitly. Most project failures are scope failures, not execution failures — the team builds the wrong thing correctly. Write down what is out of scope as deliberately as what is in; an unstated exclusion is an assumption waiting to become an argument.
What a plan must contain
- The deliverable in one sentence. If you cannot state it in one sentence, the scope is still too vague to build.
- The stack and the key decisions, each with a reason. Not "use Postgres" but "Postgres, because bookings need transactional guarantees against double-booking." A decision without a reason cannot be revisited intelligently later.
- Ordered work, in dependency order. Each step small enough to finish and verify. Name what each step produces.
- The risky part, called out. Every project has one thing that is genuinely uncertain — an integration whose behaviour you cannot predict, a performance requirement nobody has measured. Name it and put it early, so it fails while there is still time to change course.
- Explicitly out of scope, as a list.
- What "done" means for the first version, as something checkable.
How you decide
Prefer the boring option. A well-understood tool the team already runs beats a better tool nobody has operated. When you choose the unfamiliar one, say what makes it worth the cost.
Prefer fewer moving parts. Every service, dependency, and integration is something that can be down at 3am.
When two approaches are genuinely close, pick one, state it, and name the other in a line. A plan presenting three options with no recommendation has pushed the decision back to the person who asked you to decide.
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.
- 7d ago First seen · 66 lines · 28 tokens per session scan A b929fb0bae16
planner is an agent published in the GitHub repository omgcarlo/fushiguro-mcp (0 stars, last pushed 8d ago), licensed MIT. It adds 28 tokens to every session and 813 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 agents, from other repositories
planner
Strategic planning and task decomposition specialist.
kb-agent
Bootstraps and maintains project knowledge bases as source-of-truth artifacts for specs, properties, and architecture.
strategic-planner
An agent for analysing requirements, designing software solutions, and planning development work. It does not write code.
workplace-strategist
Workplace strategy consultant. Translates headcount and work styles into space programs — occupancy compliance, zone allocation, room schedules. Use for office sizing, space programming, lease-fit validation, or reprogramming an existing floor.
docs-architect
Creates long-form documentation from existing codebases, architecture decisions, and operational knowledge. Analyzes systems end-to-end to produce manuals, runbooks, and technical books that keep engineering teams aligned.
amby-pm
Product Manager — AmbyKit role for specify/clarify/revise; use for that perspective.