# Roadmap View > Generate and update a visual, interactive product roadmap from a JSON data file. Produces a branded HTML swimlane view with quarters, sprints, and feature blocks — ready to share with stakeholders. Triggers on: "show roadmap", "update roadmap", "generate roadmap", "roadmap view", "visual roadmap", "sprint roadmap", "share the roadmap", "roadmap HTML", or any request to see or update the product roadmap. Also auto-prompts for roadmap placement when a new PRD or feature concept is created. - Skill: `talgacapri/roadmap-view` (Agent Skill) - Install (CLI): `npx skillmds@latest add talgacapri/roadmap-view` - Raw SKILL.md: https://api.skillmd.com/api/skills/talgacapri/roadmap-view/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: talgacapri (https://skillmd.com/u/talgacapri) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/talgacapri/roadmap-view --- # Roadmap View Skill Generate a visual, interactive product roadmap from a single JSON data file. The output is a branded HTML file that works in any browser, can be shared as a standalone file, and updates instantly when the data changes. --- ## Architecture ``` outputs/roadmaps/roadmap-data.json <-- Single source of truth (edit this) | /roadmap-view skill <-- Reads JSON, generates HTML | outputs/roadmaps/roadmap.html <-- Shareable visual output ``` **To update the roadmap:** Edit `roadmap-data.json`, then run `/roadmap-view` to regenerate. --- ## Step 1: Read the design system Before generating any output, read your product's design system for brand constants: - Read your design system file (typically in `context-library/design-system/` or wherever your team keeps brand constants) - Pull: backdrop color, surface color, primary text color, accent color, typography choice (heading + body fonts) - If no design system exists yet, use neutral defaults: backdrop `#F5F7FA`, surface `#FFFFFF`, text `#1A1A1A`, accent `#7C3AED`, font `Inter` --- ## Step 2: Read the roadmap data Read `outputs/roadmaps/roadmap-data.json`. This file contains: ```json { "product": "[Your product name]", "owner": "PM name", "lastUpdated": "2026-04-10", "todayMarkerLabel": "10 April Update", "quarters": [ { "id": "Q2-2026", "label": "Q2 2026", "color": "#7C3AED", "sprints": [ { "id": "sprint-5", "label": "Sprint 5", "dateRange": "31 Mar - 14 Apr", "startDate": "2026-03-31", "endDate": "2026-04-14", "features": [ { "name": "Feature Name", "status": "planned", "category": "feature", "phase": "design" } ] } ] } ], "parkingLot": [ { "name": "Unscheduled Feature", "category": "feature" } ], "statusConfig": { ... }, "categoryConfig": { ... }, "phaseConfig": { ... } } ``` ### Data model **Quarters** contain sprints. **Sprints** contain features. **Feature statuses:** `completed`, `in-progress`, `planned`, `at-risk`, `blocked` **Feature categories:** `feature`, `maintenance` (extend as needed for your team) **Feature phases** (optional, omit for maintenance): `design`, `dev`, `testing` **Parking lot:** Top-level `parkingLot` array for features not yet scheduled. Each entry has `name` and `category`. ### Design-to-Dev auto-rule When the PM adds a feature with `"phase": "design"` to a sprint, **automatically assume dev work starts the following sprint.** When generating or updating the roadmap: 1. If a feature appears with `phase: "design"` in Sprint N, offer to add it with `phase: "dev"` to Sprint N+1. 2. Ask the PM: "[Feature] is in design for Sprint 7. Should I add it to Sprint 8 as dev?" 3. If confirmed, add the entry to the next sprint automatically. This keeps the roadmap honest about the full lifecycle of each feature. --- ## Step 3: Generate the HTML roadmap Generate a single self-contained HTML file at `outputs/roadmaps/roadmap.html`. ### Layout structure The layout is a horizontal swimlane grid: ``` +------ Q1 2026 ------+------------ Q2 2026 ---------------+ | Sprint 3 | Sprint 4 | Sprint 5 | Sprint 6 | Sprint 7 | Sprint 8 | | 03-17 Mar| 17-31 Mar | 31 Mar- | 14-28 | 04-20 | 20 May- | | | | 14 Apr | Apr | May | 03 Jun | +-----------+-----------+----------+----------+----------+----------+ | Feature A | Feature D | Feature G| Feature J| Feature M| Feature P| | Feature B | Feature E | Feature H| Feature K| Feature N| Feature Q| | Feature C | Feature F | Feature I| Feature L| Feature O| Feature R| +-----------+-----------+----------+----------+----------+----------+ ^ Today marker ``` ### Required visual elements 1. **Quarter header row** — colored bar spanning all sprints in that quarter. Use the quarter's `color` field. White text. Full-width within that quarter's columns. 2. **Sprint header row** — below quarters. Each sprint gets a column with: - Sprint label (bold) - Date range (smaller, subtext color) 3. **Feature blocks** — cards within each sprint column: - White background with category-specific border-left accent (4px) - Feature name - Status indicator (colored dot + label) - Category pill badge - Subtle shadow on hover 4. **Today marker** — vertical dashed line positioned at today's date relative to the sprint timeline. Include a label at the top (e.g., "10 April Update") with a small downward arrow/triangle. 5. **Legend** — bottom of page showing status colors and category colors. 6. **Header** — Your logo, product name, last updated date, owner. 7. **Footer** — "Generated by PM-OS" with date. ### Visual specs (apply your design system tokens) ```css /* Page */ background: [your backdrop color]; font-family: [your heading font], sans-serif; /* Containers */ background: [your surface color]; border-radius: 16px; box-shadow: 0 4px 6px rgba(0,0,0,0.07); /* Quarter bars */ border-radius: 8px; padding: 8px 16px; color: #FFFFFF; font-weight: 700; /* Feature cards */ background: [your surface color]; border-radius: 12px; border-left: 4px solid [category color]; padding: 12px 16px; margin-bottom: 8px; transition: box-shadow 0.2s, transform 0.2s; /* Feature card hover */ box-shadow: 0 4px 12px rgba(0,0,0,0.12); transform: translateY(-1px); /* Status dot */ width: 8px; height: 8px; border-radius: 50%; background: [status color]; /* Today marker */ border-left: 2px dashed #EF4444; position spanning full height of the grid; ``` ### Responsive behavior - Horizontal scroll on small screens (roadmaps are inherently wide) - Minimum sprint column width: 200px - Maximum sprint column width: 280px - Cards stack vertically within each sprint column ### Interactive features (CSS/JS only, no frameworks) - **Hover on feature cards** — elevate with shadow, show category tooltip - **Click on feature card** — toggle expanded view showing full name (for long names) - **Filter by status** — clickable legend items toggle visibility - **Filter by category** — clickable category pills toggle visibility - **Print-friendly** — `@media print` styles that hide filters, show all items, fit to landscape ### HTML structure (reference) ```html [Your Product] Roadmap ``` --- ## Step 4: Validate output Before delivering, check: 1. All sprints from JSON appear as columns 2. All features appear in correct sprint columns 3. Status indicators match the data 4. Category borders/pills use correct colors 5. Today marker is positioned at the correct sprint (based on today's date vs sprint date ranges) 6. Your logo renders correctly 7. Your heading font loads 8. Horizontal scroll works for many sprints 9. Print layout produces a clean landscape view 10. File opens correctly in browser with no external dependencies (except Google Fonts) --- ## Step 5: Report to PM After generating, tell the PM: 1. **File location:** `outputs/roadmaps/roadmap.html` 2. **How to update:** Edit `outputs/roadmaps/roadmap-data.json`, then run `/roadmap-view` to regenerate 3. **How to share:** Open the HTML in a browser, screenshot or send the file directly 4. **Quick edits:** Describe what JSON fields to change for common operations: - Add a feature: add object to a sprint's `features` array - Move a feature: cut/paste between sprints - Change status: update the `status` field - Add a sprint: add sprint object to quarter's `sprints` array - Add a quarter: add quarter object to `quarters` array --- ## Trigger: New PRD or feature concept When this skill detects it's being called after `/prd-draft` or when a new feature concept is discussed, it should: 1. **Ask the PM:** "Where should this go on the roadmap? Which sprint or quarter?" 2. **Show current sprints** from `roadmap-data.json` with their date ranges 3. **Offer options:** - Add to an existing sprint (pick one) - Create a new sprint - Add to backlog (not yet scheduled) - Skip roadmap placement for now 4. **Update `roadmap-data.json`** with the new feature entry 5. **Regenerate the HTML** automatically ### Integration with /prd-draft At the end of any PRD draft, add this prompt: ``` This feature has been documented. Would you like to place it on the roadmap? Current sprints: - Sprint 5: [date range] ([features]) - Sprint 6: [date range] ([features]) - Sprint 7: [date range] ([features]) - Sprint 8: [date range] ([features]) Options: 1. Add to an existing sprint 2. Create a new sprint 3. Add to backlog 4. Skip for now ``` --- ## Maintaining the roadmap ### Common operations via natural language The PM can say: - **"Move [Feature] to Sprint 7"** — update JSON, regenerate - **"Mark [Feature] as completed"** — update status, regenerate - **"Add a new sprint 9 from June 3 to June 17"** — add sprint to the relevant quarter, regenerate - **"Remove [Feature] from the roadmap"** — delete from JSON, regenerate - **"Show the roadmap"** — regenerate from current JSON and open - **"Add Q3 2026 to the roadmap"** — add new quarter with empty sprints All operations follow the same pattern: update `roadmap-data.json`, then regenerate `roadmap.html`. --- ## Related skills - `frontend-design` — visual design patterns and component specs - `prd-draft` — PRD creation (triggers roadmap placement prompt) - `write-prod-strategy` — product strategy with roadmap horizons - `create-tickets` — engineering backlog (complementary to roadmap view)