product-roadmap

Product Roadmap Workshop

A CPO-grade interactive workshop for defining and operationalizing product roadmaps. Synthesizes knowledge-base context, guides the founder through strategic decisions, and creates GitHub milestones.

Note: The current year is 2026.

Sub-commands

| Command | Description | |---------|-------------| | product-roadmap (no sub-command) | The interactive CPO workshop below (default). | | product-roadmap validate | Read-only drift report: reconcile roadmap.md Current State counts against live GitHub milestones. Never writes. | | product-roadmap next | Read-only advisory: report the next action for the first incomplete phase. |

Dispatch. If the first token of $ARGUMENTS is validate or next, run that sub-command below and STOP — do not run the workshop. Otherwise, skip to Roadmap Context and run the workshop. Both sub-commands are strictly read-only (they never edit roadmap.md); the existing cron-roadmap-review.ts Inngest cron remains the sole writer, via reviewed fix PRs (ADR-033 / ADR-054).

Sub-command: validate

Reconcile the roadmap against live GitHub milestone state and print a drift report. Makes no file writes.

Run the shared module ([roadmap-reconcile.sh](./scripts/roadmap-reconcile.sh)) from the repo root:

bash ${CLAUDE_PLUGIN_ROOT:-plugins/soleur}/skills/product-roadmap/scripts/roadmap-reconcile.sh validate

It prints STALE_STATUS / MISSING_ISSUE / EMPTY_MILESTONE verdicts (the same vocabulary the roadmap-review cron uses) and exits non-zero on drift. Relay the report verbatim. When drift is found, the report already names the remediation — trigger the roadmap-review cron (/soleur:trigger-cron cron/roadmap-review.manual-trigger), which opens a reviewed PR. Do not edit roadmap.md from this skill.

Sub-command: next

Report the single next action for the first incomplete roadmap phase. Read-only — invokes no build.

bash ${CLAUDE_PLUGIN_ROOT:-plugins/soleur}/skills/product-roadmap/scripts/roadmap-reconcile.sh next

It finds the first phase with open issues, picks the lowest-numbered open issue (deterministic tie-break), and classifies it: a codeable item (engineering label) is surfaced as a paste-ready /soleur:go #N; an operator item (recruitment, interviews, research, marketing, ops) is named for the founder to action directly; an empty milestone yields an explicit "no actionable next item". Relay the output. Never invoke /soleur:one-shot or any build from this sub-command — surface the recommendation and stop.

Roadmap Context

<roadmap_context> #$ARGUMENTS </roadmap_context>

If the context above is empty, ask: "What product would you like to create a roadmap for? Describe the product, or say 'current' to use the existing knowledge-base context."

Headless Mode

If $ARGUMENTS contains --headless, set HEADLESS_MODE=true. Strip --headless from $ARGUMENTS before processing remaining content. When HEADLESS_MODE=true, skip all AskUserQuestion prompts and use KB-derived defaults. If insufficient KB context exists to derive defaults, generate a minimal single-phase roadmap with all open issues and flag that manual review is needed.

Phase 0: Setup

Branch safety check: Run git branch --show-current. If the result is main or master, abort: "Error: product-roadmap cannot run on main/master. Checkout a feature branch first."

Load project conventions: Read CLAUDE.md if it exists.

Read knowledge-base artifacts. For each artifact below, check if the file exists and read it. Record status (found/missing) and key findings:

1. knowledge-base/marketing/brand-guide.md -- Identity, Positioning, Target Audience
2. knowledge-base/product/business-validation.md -- Verdict, customer definition, problem statement
3. knowledge-base/product/competitive-intelligence.md -- Executive summary, tier 0 threats
4. knowledge-base/product/pricing-strategy.md -- Pricing hypothesis, validation gates
5. knowledge-base/product/roadmap.md -- Existing roadmap (triggers update mode)
6. Scan knowledge-base/project/specs/ for spec directories

Read GitHub state:

gh issue list --state open --limit 100 --json number,title,labels,milestone

gh api repos/{owner}/{repo}/milestones --jq '.[] | {title, open_issues, closed_issues, due_on}'

Present Context Summary. Display a table of what was found and what is missing. If an existing roadmap.md was found, ask whether to update it or start fresh. In headless mode: default to "Update existing" if found, "Start fresh" if not.

Fill gaps. For each missing critical artifact, ask a brief targeted question or suggest running the relevant specialist agent (competitive-intelligence for competitive gaps, business-validator for validation gaps). In headless mode: skip gap-filling, proceed with available context.

Phase 0.5: CPO Pre-Analysis

Spawn the CPO agent as a background task with all context gathered in Phase 0 (KB artifacts, GitHub state, existing roadmap if any). The CPO produces a draft roadmap proposal before the interactive workshop begins.

CPO task prompt: "You are the CPO. Analyze the following knowledge-base artifacts and GitHub state to produce a draft product roadmap proposal. Include: (1) 2-4 strategic themes with rationale grounded in business validation, competitive intelligence, and current product state, (2) 3-5 proposed phases with objectives, scope, and feature lists drawn from open GitHub issues, (3) gaps and risks you identified — missing phases, features, strategic directions, or unaddressed risks the founder may not have considered, (4) prioritization rationale explaining why you ordered the phases this way, (5) open questions for the founder. Challenge assumptions. Be opinionated — propose a direction, don't just list options.

Scope boundaries for the CPO analysis:

• Flag roadmap-level gaps (missing features, phases, strategic risks) NOT planning-level details (UX flows, screen designs, onboarding step sequences). 'No onboarding exists' is a valid gap. 'The onboarding should have 3 screens' is not — that belongs in spec/planning.
• Verify technical claims before asserting them. Check the codebase for actual architecture (git-backed? containerized? replicated?) before flagging durability, infrastructure, or scaling concerns. False alarms waste founder time.
• Do not ask implementation-choice questions (which SDK mode, which framework, which protocol). Flag the NEED ('multi-turn is broken'), not the HOW ('use persistSession vs history injection'). Route HOW questions to the CTO.
• Do not propose features for a maturity stage the product has no plan to reach. However, if a later phase explicitly depends on a capability (e.g., Phase N activates Stripe live mode), the prerequisite features (pricing page, subscription management, invoice handling) ARE roadmap gaps even if the product is pre-beta today. Distinguish between premature features (no plan needs them) and prerequisite features (a planned phase requires them).

Context: {all Phase 0 findings}"

Wait for the CPO analysis to complete, then present it to the founder.

In headless mode: Use the CPO proposal as the final roadmap without interactive refinement (skip Phase 1 workshop).

Phase 1: Workshop (CPO-Facilitated)

The CPO's draft proposal is the starting point. The workshop refines it through multi-turn dialogue. The CPO role is to facilitate and challenge — not just present options, but push back on choices, identify gaps the founder may have missed, and advocate for the user's perspective.

1.1 Strategic Themes

Present the CPO's proposed themes. For each, show the rationale grounded in KB artifacts. Ask the founder which resonate and what to change. If the founder proposes a theme the CPO didn't include, the CPO should either support it with evidence or challenge it with a counter-argument.

###