roadmap
Generates ROADMAP.md from project milestones, issues, and boards (GitHub, GitLab, or Bitbucket). Structures content with mission statement, current milestone progress, upcoming milestones, and community involvement section. Use when creating or updating a project roadmap.
Best use case
roadmap is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Generates ROADMAP.md from project milestones, issues, and boards (GitHub, GitLab, or Bitbucket). Structures content with mission statement, current milestone progress, upcoming milestones, and community involvement section. Use when creating or updating a project roadmap.
Teams using roadmap should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/roadmap/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How roadmap Compares
| Feature / Agent | roadmap | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Generates ROADMAP.md from project milestones, issues, and boards (GitHub, GitLab, or Bitbucket). Structures content with mission statement, current milestone progress, upcoming milestones, and community involvement section. Use when creating or updating a project roadmap.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Roadmap Generator ## ROADMAP.md Structure ```markdown # Roadmap > **Mission**: [One sentence describing the project's north star goal] This roadmap reflects our current plans and priorities. It's a living document — priorities shift based on community feedback and real-world usage. **Last updated**: [Date] ## Legend | Status | Meaning | |--------|---------| | :white_check_mark: Done | Shipped and available | | :construction: In Progress | Actively being worked on | | :dart: Planned | Committed for this milestone | | :thought_balloon: Exploring | Under consideration, feedback welcome | --- ## Current Milestone: v1.3 — [Milestone Title] **Target**: Q1 2026 · **Progress**: 6/10 items complete | Status | Feature | Issue | Notes | |--------|---------|-------|-------| | :white_check_mark: | Marketing-friendly README generation | #42 | Shipped in v1.2 | | :white_check_mark: | Changelog from conventional commits | #38 | Shipped in v1.2 | | :construction: | GitHub Projects integration | #45 | PR open | | :construction: | User-benefit language in changelogs | #44 | In review | | :dart: | Comparison table generator | #50 | Starting next sprint | | :dart: | CONTRIBUTING.md generator | #48 | Blocked on #45 | --- ## Upcoming ### v1.4 — [Milestone Title] (Q2 2026) | Status | Feature | Issue | |--------|---------|-------| | :dart: | Full docs suite audit command | #55 | | :dart: | GitHub issue template generator | #56 | | :thought_balloon: | Blog post generator from README | #60 | | :thought_balloon: | Multi-language README support | #62 | ### v2.0 — [Milestone Title] (Q3 2026) | Status | Feature | Issue | |--------|---------|-------| | :thought_balloon: | Interactive README builder | #70 | | :thought_balloon: | Auto-update on CI | #72 | --- ## Completed Milestones <details> <summary>v1.2 — Documentation Foundation (January 2026)</summary> - :white_check_mark: Basic README generation (#10) - :white_check_mark: Badge detection and generation (#12) - :white_check_mark: Package.json/pyproject.toml parsing (#15) - :white_check_mark: Quick start section generator (#18) </details> --- ## How to Get Involved We'd love your input on what to build next: - **Vote on features**: React with :+1: on issues you want prioritised - **Propose ideas**: [Open a discussion](link) - **Contribute**: See [CONTRIBUTING.md](CONTRIBUTING.md) for how to get started - **Report issues**: [File a bug](link) Items marked :thought_balloon: are especially open to community feedback. ``` ## Data Sources Data source commands below default to GitHub (`gh` CLI / `mcp__github__*`). For GitLab, use `glab` CLI. For Bitbucket, use REST API or Jira integration. Load the `platform-profiles` skill for CLI and API equivalents. ### Milestones (via platform CLI or MCP) ```bash # GitHub gh issue list --milestone "v1.3" --state all # GitLab glab issue list --milestone "v1.3" --all ``` Use milestones to group features into releases. Each milestone becomes a section. GitLab also supports Epics for higher-level grouping across milestones. ### Project Boards If the repo uses project boards (GitHub Projects v2, GitLab Boards, or Jira), pull items from there: 1. Get board items 2. Map columns/statuses to roadmap legend 3. Extract issue numbers and titles ### Git Tags ```bash git tag --sort=-v:refname | head -20 ``` Map tags to completed milestones. Include completion dates. ### Open Issues with Labels ```bash # GitHub gh issue list --label "enhancement" --state open --limit 50 gh issue list --label "feature" --state open --limit 50 # GitLab glab issue list --label "enhancement" --all --per-page 50 glab issue list --label "feature" --all --per-page 50 ``` ## Language Rules - **Mission statement**: One sentence, present tense, aspirational but concrete - **Feature descriptions**: Benefit-focused, not implementation-focused - **Status updates**: Factual, linked to issues/PRs - **Timeline**: Use quarters (Q1/Q2/Q3/Q4), not specific dates (they create pressure and disappointment) - **Tone**: Transparent, inviting, community-oriented ## Anti-Patterns - **Don't promise specific dates** — use quarters or "upcoming" - **Don't list every issue** — curate to significant features - **Don't include internal tasks** — roadmaps are for users - **Don't forget completed milestones** — they show momentum - **Don't make it static** — include "last updated" date - **Don't forget the "get involved" section** — roadmaps are conversation starters
Related Skills
pitchdocs
Generate marketing-quality repository documentation from codebase analysis. Scans 10 signal categories, extracts features with file-level evidence, and produces README, CHANGELOG, ROADMAP, and 15+ more docs. Zero runtime dependencies. For AI context file management, see ContextDocs.
visual-standards
Visual formatting standards for repository documentation — emoji heading prefixes, horizontal rules, TOC anchors, callouts, screenshots (device dimensions, HTML patterns, captions, shadows), and image optimisation. Load when generating READMEs with visual elements or working with screenshots.
user-guides
Generates task-oriented user guides and how-to documentation for a repository. Creates docs/guides/ with step-by-step instructions for common workflows, integrations, and advanced usage. Links guides into README.md and CONTRIBUTING.md. Use when a project needs user-facing how-to documentation beyond the README quickstart.
public-readme
Generates READMEs with the Daytona/Banesullivan marketing framework — hero section, benefit-driven features, quickstart, comparison tables, and compelling CTAs. Produces docs that sell as well as they inform. Use when creating or overhauling a project README.
platform-profiles
Platform-specific equivalents for GitLab and Bitbucket when generating repository documentation. Lookup tables for file paths, badges, Markdown rendering, CI/CD, and CLI tools. Load this skill when working on non-GitHub repos or generating cross-platform docs.
pitchdocs-suite
One-command generation and audit of the full public repository documentation set — README, CHANGELOG, ROADMAP, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, issue templates, PR template, and discussion templates. Use when setting up a new repo or auditing an existing one.
package-registry
Documentation guidance for projects published to npm and PyPI package registries. Covers metadata fields that affect registry pages, README cross-renderer compatibility, trusted publishing, provenance badges, and audit checks. Use when a project has package.json or pyproject.toml and is published publicly.
llms-txt
Generates llms.txt and llms-full.txt files following the llmstxt.org specification. Provides LLM-friendly content curation for AI coding assistants (Cursor, Windsurf, Claude Code) and AI search engines. Use when generating or updating llms.txt for a repository.
launch-artifacts
Transforms README and CHANGELOG into platform-specific launch content — Dev.to articles, Hacker News posts, Reddit posts, Twitter/X threads, and awesome list submission PRs. Keeps promotion tethered to code artifacts, not generic marketing. Use when launching or announcing a project release.
geo-optimisation
Generative Engine Optimisation (GEO) patterns for documentation that surfaces correctly in AI-generated answers — citation capsules, crisp definitions, atomic sections, comparison tables, statistics, and semantic scaffolding. Load when optimising docs for AI citation (ChatGPT, Perplexity, Google AI Overviews, Claude).
feature-benefits
Systematic codebase scanning for features and evidence-based feature-to-benefit translation. Extracts what a project does from its code and translates it into what users gain — generates features and benefits sections, "Why [Project]?" content, and feature audit reports. Use when writing a features table for a README, extracting features from code, auditing feature coverage, or answering "why should someone use this project?".
docs-verify
Validates documentation quality and freshness — checks for broken links, stale content, llms.txt sync, image issues, heading hierarchy, and badge URLs. Runs locally or in CI. Use to catch documentation decay before it reaches users.