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/anotb/management-consulting-plugin/implementation-planningnpx skills add anotb/management-consulting-plugin --skill implementation-planninggit clone --depth 1 https://github.com/anotb/management-consulting-pluginWrote 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/skills/anotb/management-consulting-plugin/implementation-planning)<a href="https://agentmods.dev/skills/anotb/management-consulting-plugin/implementation-planning"><img src="https://agentmods.dev/badge/skills/anotb/management-consulting-plugin/implementation-planning.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 | $0.00106 | $0.05989 |
| Opus 5 | $0.00053 | $0.02995 |
| Sonnet 5 | $0.00021 | $0.01198 |
| Haiku 4.5 | $0.00011 | $0.00599 |
Grade A, and why
implementation-planning 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 5d 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 — 499 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementation Planning
Turn a strategic recommendation into a concrete, funded, governed plan the organization can actually run. Four connected stages carry the work: generate and evaluate options, build the business case, design the roadmap, develop the implementation plan. For the ongoing oversight machinery (steering committees, status reporting, live risk management), see project-governance. This skill gets the plan approved and structured. That skill runs it.
Before you produce any of these deliverables, get the real inputs. Ask for the actual budget envelope, the real baseline metrics, the org's hurdle rate, the named constraints. When you must show a number you do not have, label it as an example and flag it for validation. Do not invent dollar figures, benchmarks, or engagement precedent. A business case built on fabricated numbers is worse than no business case, because it looks decided.
The Strategy-to-Execution Arc
Most strategies fail in execution, not in formulation. The gap between "we should do X" and "X is happening" is where value gets destroyed. This skill closes that gap on purpose.
The four stages flow in order but rarely run cleanly front to back. Sometimes the path is unclear and you start with options. Sometimes the recommendation is already made and you jump to business case. Meet the work where it actually is.
Strategic Option Business Roadmap Implementation
Recommendation -> Development -> Case -> Design -> Plan
"We should..." "Here are "Here's why "Here's "Here's exactly
the ways it's worth it" the order" how we do it"
we could..."
Stage 1: Strategic Option Development
Develop genuinely different options before committing to a path. Three flavors of the same idea is not a choice. Structurally different approaches are.
Define the Decision
Clarify what is being decided before generating anything.
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.
- 5d ago First seen · 499 lines · 106 tokens per session scan A 145cf1e9f4e6
implementation-planning is a skill published in the GitHub repository anotb/management-consulting-plugin (47 stars, last pushed 11d ago), licensed MIT. It adds 106 tokens to every session and 5,989 once invoked, about $0.0005 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 skills, from other repositories
pipefy-process-design
Use this skill ONLY when the user explicitly asks for help designing or architecting a process ("help me design", "what's the best structure", "how do I organize this flow?"). For direct execution requests ("create a pipe for X", "build a reimbursement process", or any message with a detailed spec), skip this skill…
garden-desk-plan-change
Plan a Garden Desk change against the active milestone before editing. Use when starting non-trivial work, checking whether a request is authorized in the current phase, or deciding what stays out of scope.
garden-desk-handoff
Create a privacy-safe Garden Desk work handoff for another session, contributor, issue, or pull request. Use when work is incomplete, blocked, or changing owners.
delivery-plan
Sequence work by risk rather than convenience - unknowns first so bad news arrives early, slices that are independently shippable, dependencies on other teams surfaced with lead times, and an explicit statement of what would change the plan. Use once feasibility and estimation exist and someone wants an order of work…
handover-pack
Consolidate an engagement into what the receiving team actually needs - refreshed CLAUDE.md, runbooks, ADRs, known issues, and explicitly the open risks and unfinished business that most handovers omit. Use when an engagement is ending, when rotating to another team, when someone else will take over work in progress…
ownership-map
Work out who owns what and who decides, from evidence rather than the org chart - CODEOWNERS, commit authorship over time, review patterns, ticket references, and directory-level activity - distinguishing who wrote the code from who maintains it now. Use when you need a reviewer, an approver, or an interview subject…