Roadmap

Use this skill to produce a high-signal implementation plan that can be executed step by step and updated during execution.

Reference:

OpenAI Cookbook: https://developers.openai.com/cookbook/articles/codex_exec_plans

When to Use

Complex feature work touching multiple modules
Large refactor with rollout risk
Ambiguous requirement that needs explicit assumptions
Work requiring milestone tracking and acceptance gates

When NOT to Use

Tiny one-file fixes with obvious scope
Pure brainstorming with no execution intent

Core Rules

Write the plan as a living document
- Keep plan status current as work proceeds.
- Update milestones, decisions, and risks when reality changes.
Prefer verifiable checkpoints
- Every milestone must include explicit validation.
- Validation should include concrete commands or checks when possible.
Separate scope from non-scope
- State what is in scope and out of scope.
- Avoid hidden scope expansion.
Surface uncertainty early
- List assumptions and open questions.
- Ask clarifying questions if blockers prevent a credible plan.

Output Format

# Roadmap: <short title>

## Objective
<what outcome this plan achieves>

## Why Now
<why this work is needed now>

## Scope
### In Scope
- ...

### Out of Scope
- ...

## Context
- Current architecture/code paths:
- Existing constraints:
- Reusable components/patterns:

## Plan
### Milestone 1: <name> [status: pending|in_progress|done]
- Deliverables:
  - ...
- Validation:
  - Command/check:
  - Expected result:
- Risks:
  - ...

### Milestone 2: <name> [status: pending|in_progress|done]
- Deliverables:
  - ...
- Validation:
  - Command/check:
  - Expected result:
- Risks:
  - ...

## Validation Gates
- Unit/integration/e2e/perf/security checks (only as applicable)
- Exit criteria for completion:

## Risks and Mitigations
- Risk:
  - Mitigation:
  - Contingency/Rollback:

## Open Questions
- [ ] ...

## Decision Log
- <date> <decision> <reason>

Execution Follow-up

After user confirms implementation:

Keep this plan updated as milestones progress.
Record deviations and why they changed.
Mark completed milestones and unresolved follow-ups.

Handoff Quality Bar

A completed plan should let another engineer execute the work without guessing:

clear file/module targets
explicit ordering and dependencies
concrete validation gates
known risks + fallback path