Skip to main content

roadmap

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

Informations de source

Dépôt
thisrohangupta/pmClaude-public
Dernière activité de la source
28 août 2026 à 18:35
Langue détectée de SKILL.md
anglais
Étoiles
0
Forks
0

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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.
Voir sur GitHub