Skip to main content

roadmap

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

ソース情報

リポジトリ
thisrohangupta/pmClaude-public
ソースの最終更新活動
2026年8月28日 18:35
検出された SKILL.md の言語
英語
スター
0
フォーク
0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
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.
GitHubで見る