skills/roadmap-analyzer/SKILL.md
Turn a product's ICP into a revenue-ranked roadmap. Reads .agents/memory/icp.md (from the icp skill), inventories what already ships, finds the gaps that block landing/retaining/expanding the primary segment, and outputs a prioritized backlog plus strategic themes. Use when asked what to build next, how to prioritize the roadmap, what's blocking revenue, or to plan toward MRR. Hands off to roadmap-to-milestones.
npx skillsauth add shipshitdev/library roadmap-analyzerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Rank what to build next by how much revenue it moves, grounded in the ICP. The output is a backlog a founder can defend to themselves: every item traces to landing, retaining, or expanding a paying segment.
Read-only on code. It produces analysis, not commits or issues — handoff to
roadmap-to-milestones turns the backlog into tracked work.
Inputs:
.agents/memory/icp.md (from the icp skill) — the segments and their
land/retain/expand levers. If absent, stop and recommend running icp first; a
roadmap without an ICP ranks by taste, not revenue.Outputs:
Creates/Modifies:
Delegates To:
icp when no ICP doc exists yet.roadmap-to-milestones to turn the ranked backlog into GitHub milestones + issues.feature-intake / prd-writer to expand a single backlog item into a PRD.Read .agents/memory/icp.md. Pull out, for the primary segment: the acute pain,
the buying trigger, the churn reasons, and the expansion path. These are the three
revenue levers the roadmap serves:
If icp.md is missing, do not guess a customer. Say so and recommend icp.
Discover current capabilities from the code and docs, not from memory. Search for the
product's core actions, automation, collaboration, integration, and billing surfaces.
For each capability record status (production / partial / missing) and quality
(solid / rough / prototype), with a file:line anchor as evidence. Give credit for
what exists — the gap is measured against reality, not a blank slate.
Compare ICP needs against the inventory. One row per need:
| ICP need (segment) | Lever | Current state | Gap severity | |---|---|---|---| | <need> | Land/Retain/Expand | Missing/Partial/Solid | CRITICAL/HIGH/MEDIUM/LOW |
Severity is revenue-weighted: a Land or Retain gap for the primary segment is at least HIGH; a gap for a "not our ICP" segment is LOW no matter how large.
Score each candidate:
Score = (Revenue × 2 + Urgency) ÷ Effort. Higher = sooner.
Then apply the two rules that a naive score misses:
Bucket the ranked list P0 (build now), P1 (next), P2 (later), and pull out quick wins — high revenue impact, low effort — as the fastest MRR movers.
Group the backlog into 3–5 themes, each named in the product's own language, each tied to a revenue lever. Sequence them: foundations that unblock the primary segment's Land first, then Retain, then Expand. For each theme give a one-line vision, the ICP segment it serves, and its success metric (ideally a revenue or retention number, not a vanity metric).
# Roadmap Analysis — <product> (<date>)
## Executive summary
- <3–5 bullets: the revenue story and the single most important next move>
## Gap analysis
<table from Step 3>
## Revenue-ranked backlog
### P0 — build now
1. **<feature>** (score X.X) — Lever: <Land/Retain/Expand>. Why: <revenue rationale>.
### P1 — next
### P2 — later
## Quick wins
- <high-impact, low-effort items>
## Strategic themes
1. **<theme>** — serves <segment>, <lever>. Success: <metric>.
## Recommended next step
Run `roadmap-to-milestones` to sequence P0/P1 into milestones with due dates.
icp.md, prioritization is preference. Run
icp first.development
Coordinates a weekly engineering review of board accuracy, recent code changes, operational health, and scoped cleanup. Use for a recurring repository health review or a review of the last several days.
testing
Audits project board configuration and prepares explicitly requested setup, copy, or normalization changes while preserving the existing workflow and provider boundaries. Use when inspecting a board's fields, columns, scope, or configuration.
testing
Reconciles a project board with current work and delivery evidence, reports incomplete coverage and metadata gaps, and applies only approved provider-supported field changes. Use when auditing board drift, reviewing blocked work, or assessing upcoming delivery.
development
Walk through how a subsystem works. Use for "how does X work", code walkthroughs before changing something, and placement or ownership questions. Explains architecture, runtime flow, and onboarding mental models. Can critique architecture. Use why for motivation.