Skip to main content

roadmap

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

معلومات المصدر

المستودع
thisrohangupta/pmClaude-public
آخر نشاط في المصدر
٢٨ أغسطس ٢٠٢٦ في ١٨:٣٥
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٠
التفرعات
٠

خيارات التثبيت

يُحدَّد 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