product-roadmap

Codex compatibility note:

• Invoke $skill-name: load the registered .agents/skills/<name>/SKILL.md and execute it with Codex tools; no separate Skill tool or Claude mode switch is needed. Author .claude/**; mirrors are generated.
• Track steps before execution and keep progress/evidence current. Explicit skill requests execute their protocol. Use the native question tool for required questions.
• Map foreign tool names to available host capabilities. A name mismatch needs no approval; an actually unavailable required capability stops with its step/evidence and a user question before adaptation.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Preserve protocol order unless the user approves a deviation. Workflows use $start-workflow: gates stay fixed; other steps may flex with logged reasons and evidence.

[BLOCKING] Execute phases in order; update todo tracking before and after each phase. [BLOCKING] Every completed or skipped phase needs concise evidence or a reason.

Quick Summary

Goal: When explicitly requested, turn a product vision into an approved, outcome-based roadmap and one selected milestone—or route a genuinely isolated change through an explicit EXEMPT boundary—without making the roadmap artifact a prerequisite for ordinary initiative, task, spec, presentation, or mock-up work.

Summary:

• Detect create/update/select/exempt only after confirming that the user explicitly requested this standalone skill. Read the shared contract and existing roadmap before writing. A large or ambiguous idea alone is not an invocation; its decomposition belongs in the owning task/spec/presentation/mock-up artifacts.
• Define the product outcome, actors, business truth, and 3–8 outcome milestones; each milestone names user outcome, risk retired, non-goals, human decisions, dependencies, and evidence.
• Ask the owner to confirm ambiguous terms and select one milestone; write the roadmap document (default docs/product-roadmap.md; a docsRoots.productRoadmap.path entry in docs/project-config.json overrides the path) and a linked scope-brief.md incrementally.
• Hand off only an approved milestone, or an explicitly accepted EXEMPT scope, to $scenario; implementation planning remains blocked until the applicable Plan Gate is satisfied.
• Main steps: explicit-route confirmation → context/contract load → outcome framing → milestone design → owner decision gate → roadmap/scope-brief write → selected milestone or EXEMPT handoff → scenario/Plan Gate.

Workflow: 0) route and context → 1) outcome framing → 2) milestone design → 3) decision gate → 4) write roadmap → 5) select milestone/scope brief → 6) handoff.

Key Rules:

• Product roadmap answers outcomes and boundaries; it is not a timeline or implementation plan.
• Do not choose frameworks, database schemas, endpoints, screens, or code in this skill.
• Never silently reinterpret ready, published, delivered, paid, refunded, or equivalent lifecycle terms.
• A roadmap is canonical at one path — default docs/product-roadmap.md, overridden by a docsRoots.productRoadmap.path entry in docs/project-config.json; update that file rather than creating competing roadmap files.