Skip to main content

roadmap

Plan, maintain, review, and present outcome-oriented roadmaps using a configurable calendar and optional issue tracking.

Datos de origen

Repositorio
thisrohangupta/pmClaude-public
Última actividad en el origen
28 de agosto de 2026 a las 18:35
Idioma detectado de SKILL.md
inglés
Estrellas
0
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
roadmap
description
Plan, maintain, review, and present outcome-oriented roadmaps using a configurable calendar and optional issue tracking.
# Roadmap planning ## Usage ```text /roadmap <area> /roadmap deck <area> [period] /roadmap qbr <area> [period] ``` Use the user's calendar and naming convention. If none exists, use calendar quarters and label that assumption; never hard-code a fiscal year. Store artifacts under `workspace/<area>/roadmaps/`. ## Start or resume Inspect existing periods and `later.md`, then offer the relevant choices: resume the active period, plan the next period, review later items, or inspect history. Do not move work between statuses or periods without user confirmation. ## Plan a period Read `context/templates/roadmap_template.md` and create `<period>/roadmap-draft.md` with: - outcomes and the user or business problem behind each; - initiatives with confidence or commitment level; - success and guardrail measures; - dependencies, capacity constraints, and owners when known; - explicit trade-offs and deferred work; - risks and review dates. Use RICE, MoSCoW, value/effort, or theme grouping only when it helps the decision. Show inputs and uncertainty rather than presenting framework output as objective truth. ## Issue-tracker sync When a connector and project key are configured, search for matching epics and prepare status updates. Treat the issue tracker as authoritative only for fields it actually owns. Do not infer roadmap commitment from issue existence or update any issue without explicit confirmation. ## During the period For each addition, deferral, or commitment change, update the roadmap and add a dated entry to `movements.md`: ```markdown ## YYYY-MM-DD: [Item] moved from [old state] to [new state] **Reason:** [Evidence or constraint] **Impact:** [Outcome, dependency, or date implication] **Decision owner:** [Known owner or Unassigned] ``` Distinguish committed, planned, exploratory, shipped, and deferred work. Verify delivery before marking an item shipped. ## Period review Summarize outcomes achieved, measures versus targets, work not completed, reasons, learnings, and decisions for the next period. Avoid completion percentages that treat initiatives as equal-sized units unless the limitation is explicit. ## Decks Delegate roadmap and QBR presentation creation to `/deck`. Save output beside the roadmap and visually inspect the rendered deck before calling it complete.
Ver en GitHub