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 skills add avelikiy/great_cto --skill outcome-roadmapgit clone --depth 1 https://github.com/avelikiy/great_ctoWrote 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/avelikiy/great_cto/outcome-roadmap)<a href="https://agentmods.dev/skills/avelikiy/great_cto/outcome-roadmap"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/outcome-roadmap/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/avelikiy/great_cto/outcome-roadmap"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/outcome-roadmap.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00062 | $0.01190 |
| Opus 5.5 | $0.00025 | $0.00476 |
| Sonnet 5.5 | $0.00012 | $0.00238 |
| Haiku 4.5 | $0.00006 | $0.00119 |
Grade A, and why
outcome-roadmap 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 1mo 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 — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Outcome Roadmap — from features to results
Converts a feature-focused roadmap into an outcome-focused one.
Core principle: Teams build features, but customers and businesses care about outcomes. An outcome roadmap communicates WHAT CHANGES, not what gets built.
The transformation formula
For every initiative on the roadmap, apply:
Enable [customer segment] to [desired customer outcome] so that [business impact]
Examples:
| Output (old) | Outcome (new) |
|---|---|
| Q2: Build advanced search filters | Q2: Enable customers to find products 50% faster through intuitive discovery |
| Q2: AI recommendations | Q2: Increase average order value 20% through personalised recommendations |
| Q3: Dashboard redesign | Q3: Help operators monitor all systems with 80% less time spent on dashboards |
| Q3: SSO integration | Q3: Remove auth friction for enterprise admins so we can close 3+ enterprise deals |
| Q4: Mobile app | Q4: Enable users to complete core workflows on mobile so 7-day retention increases from 20% to 35% |
How to apply
Step 1 — Read the existing roadmap
If the user provides a roadmap file, read it. If they describe it verbally, extract the initiative list.
For each initiative, ask internally:
- What feature / project is planned?
- Why are we building it? What changes for customers or the business?
- What metric will improve, and by how much?
- Is there a better, different way to achieve the same outcome?
Step 2 — Rewrite each initiative as an outcome
For each item in the roadmap:
- Identify the output: What feature or project is planned?
- Uncover the outcome: Why are we building it? Keep asking "So what?" until you reach real customer or business value.
- Rewrite: Use the formula above. Include a metric if possible.
"So what?" chain example:
- "We're adding search filters" → So what?
- "Users can narrow results" → So what?
- "Users find what they're looking for faster" → So what?
- "Users convert at higher rates because they find products before abandoning" ✅ That's the outcome.
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.
- 1mo ago Changed a1403689b2bb
- 1mo ago First seen · 131 lines · 62 tokens per session scan A ccbe902bf0ca
outcome-roadmap is a skill published in the GitHub repository avelikiy/great_cto (108 stars, last pushed today), licensed MIT. It adds 62 tokens to every session and 1,190 once invoked, about $0.0002 per session on Opus 5.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-09-03.
Other skills, from other repositories
pm
Project manager for GitHub issues: brainstorm design approaches, create structured issues optimized for LLM agent teams, triage and recommend what to work on next, audit and clean up stale issues, or deep-validate a single issue against the codebase. Triggers: create issue, plan work, new task, project manager, write…
pocket-closing
Close a reviewed Pocket phase or plan when the user explicitly requests closeout, including as part of an end-to-end request. Reconcile verdicts with log.json, advance only a passing phase, append a readable per-phase closeout, and finalize the plan when all phases are done. A passing verdict alone does not authorize…
pm-tech-spec-review
Review an engineering technical spec through a PM lens — does it cover every PRD requirement, does it preserve user/UX intent, does it quietly add or drop scope, what are the product risks, what's missing for launch. Produces a priority-tagged findings list + clarifying questions for engineering. Use after eng drafts…
tpp-orchestrate
Work through a queue of Technical Project Plans serially — delegate each to a TDD subagent, get a cross-model second opinion, empirically vet every finding, and make one coherent commit per plan. Use when executing a documented plan queue such as todo/ or feat-name/ for a port, migration, or multi-stage feature.
tpp
Work a Technical Project Plan to completion — read the plan, start from its current phase, work through its tasks until their acceptance tests pass, and update the plan as each task lands. Use when starting or resuming multi-session work tracked in a plan file.
handoff
Update the active Technical Project Plan for handoff when context is running low or the session is ending, so the next session continues instead of restarting.