opencode-knowledge-work 0.0.0-stage → 0.1.1

package/content/product-management/skills/product-management-roadmap-update/SKILL.md

@@ -0,0 +1,266 @@
+---
+name: roadmap-update
+description: Update, create, or reprioritize your product roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from scratch.
+argument-hint: "<update description>"
+---
+
+# Roadmap Update
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Update, create, or reprioritize a product roadmap.
+
+## Usage
+
+```
+/roadmap-update $ARGUMENTS
+```
+
+## Workflow
+
+### 1. Understand Current State
+
+If **~~project tracker** is connected:
+- Pull current roadmap items with their statuses, assignees, and dates
+- Identify items that are overdue, at risk, or recently completed
+- Surface any items without clear owners or dates
+
+If no project management tool is connected:
+- Ask the user to describe their current roadmap or paste/upload it
+- Accept any format: list, table, spreadsheet, screenshot, or prose description
+
+### 2. Determine the Operation
+
+Ask what the user wants to do:
+
+**Add item**: New feature, initiative, or work item to the roadmap
+- Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies
+- Suggest where it fits based on current priorities and capacity
+
+**Update status**: Change status of existing items
+- Options: not started, in progress, at risk, blocked, completed, cut
+- For "at risk" or "blocked": ask for the blocker and mitigation plan
+
+**Reprioritize**: Change the order or priority of items
+- Ask what changed (new information, strategy shift, resource change, customer feedback)
+- Apply a prioritization framework if helpful — see **Prioritization Frameworks** below for RICE, MoSCoW, ICE, and value-vs-effort
+- Show before/after comparison
+
+**Move timeline**: Shift dates for items
+- Ask why (scope change, dependency slip, resource constraint)
+- Identify downstream impacts on dependent items
+- Flag items that move past hard deadlines
+
+**Create new roadmap**: Build a roadmap from scratch
+- Ask about timeframe (quarter, half, year)
+- Ask about format preference (Now/Next/Later, quarterly columns, OKR-aligned) — see **Roadmap Frameworks** below
+- Gather the list of initiatives to include
+
+### 3. Generate Roadmap Summary
+
+Produce a roadmap view with:
+
+#### Status Overview
+Quick summary: X items in progress, Y completed this period, Z at risk.
+
+#### Roadmap Items
+For each item, show:
+- Name and one-line description
+- Status indicator (on track / at risk / blocked / completed / not started)
+- Target timeframe or date
+- Owner
+- Key dependencies
+
+Group items by:
+- Timeframe (Now / Next / Later) or quarter, depending on format
+- Or by theme/goal if the user prefers
+
+#### Risks and Dependencies
+- Items that are blocked or at risk, with details
+- Cross-team dependencies and their status
+- Items approaching hard deadlines
+
+#### Changes This Update
+If this is an update to an existing roadmap, summarize what changed:
+- Items added, removed, or reprioritized
+- Timeline shifts
+- Status changes
+
+### 4. Follow Up
+
+After generating the roadmap:
+- Offer to format for a specific audience (executive summary, engineering detail, customer-facing)
+- Offer to draft communication about roadmap changes
+- If project management tool is connected, offer to update ticket statuses
+
+## Roadmap Frameworks
+
+### Now / Next / Later
+The simplest and often most effective roadmap format:
+
+- **Now** (current sprint/month): Committed work. High confidence in scope and timeline. These are the things the team is actively building.
+- **Next** (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.
+- **Later** (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.
+
+When to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.
+
+### Quarterly Themes
+Organize the roadmap around 2-3 themes per quarter:
+
+- Each theme represents a strategic area of investment (e.g., "Enterprise readiness", "Activation improvements", "Platform extensibility")
+- Under each theme, list the specific initiatives planned
+- Themes should map to company or team OKRs
+- This format makes it easy to explain WHY you are building what you are building
+
+When to use: When you need to show strategic alignment. Good for planning meetings and executive communication.
+
+### OKR-Aligned Roadmap
+Map roadmap items directly to Objectives and Key Results:
+
+- Start with the team's OKRs for the period
+- Under each Key Result, list the initiatives that will move that metric
+- Include the expected impact of each initiative on the Key Result
+- This creates clear accountability between what you build and what you measure
+
+When to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear "why" tied to measurable outcomes.
+
+### Timeline / Gantt View
+Calendar-based view with items on a timeline:
+
+- Shows start dates, end dates, and durations
+- Visualizes parallelism and sequencing
+- Good for identifying resource conflicts
+- Shows dependencies between items
+
+When to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).
+
+## Prioritization Frameworks
+
+### RICE Score
+Score each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) / Effort
+
+- **Reach**: How many users/customers will this affect in a given time period? Use concrete numbers (e.g., "500 users per quarter").
+- **Impact**: How much will this move the needle for each person reached? Score on a scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal.
+- **Confidence**: How confident are we in the reach and impact estimates? 100% = high confidence (backed by data), 80% = medium (some evidence), 50% = low (gut feel).
+- **Effort**: How many person-months of work? Include engineering, design, and any other functions.
+
+When to use: When you need a quantitative, defensible prioritization. Good for comparing a large backlog of initiatives. Less good for strategic bets where impact is hard to estimate.
+
+### MoSCoW
+Categorize items into Must have, Should have, Could have, Won't have:
+
+- **Must have**: The roadmap is a failure without these. Non-negotiable commitments.
+- **Should have**: Important and expected, but delivery is viable without them.
+- **Could have**: Desirable but clearly lower priority. Include only if capacity allows.
+- **Won't have**: Explicitly out of scope for this period. Important to list for clarity.
+
+When to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.
+
+### ICE Score
+Simpler than RICE. Score each item 1-10 on three dimensions:
+
+- **Impact**: How much will this move the target metric?
+- **Confidence**: How confident are we in the impact estimate?
+- **Ease**: How easy is this to implement? (Inverse of effort — higher = easier)
+
+ICE Score = Impact x Confidence x Ease
+
+When to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.
+
+### Value vs Effort Matrix
+Plot initiatives on a 2x2 matrix:
+
+- **High value, Low effort** (Quick wins): Do these first.
+- **High value, High effort** (Big bets): Plan these carefully. Worth the investment but need proper scoping.
+- **Low value, Low effort** (Fill-ins): Do these when you have spare capacity.
+- **Low value, High effort** (Money pits): Do not do these. Remove from the backlog.
+
+When to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.
+
+## Dependency Mapping
+
+### Identifying Dependencies
+Look for dependencies across these categories:
+
+- **Technical dependencies**: Feature B requires infrastructure work from Feature A
+- **Team dependencies**: Feature requires work from another team (design, platform, data)
+- **External dependencies**: Waiting on a vendor, partner, or third-party integration
+- **Knowledge dependencies**: Need research or investigation results before starting
+- **Sequential dependencies**: Must ship Feature A before starting Feature B (shared code, user flow)
+
+### Managing Dependencies
+- List all dependencies explicitly in the roadmap
+- Assign an owner to each dependency (who is responsible for resolving it)
+- Set a "need by" date: when does the depending item need this resolved
+- Build buffer around dependencies — they are the highest-risk items on any roadmap
+- Flag dependencies that cross team boundaries early — these require coordination
+- Have a contingency plan: what do you do if the dependency slips?
+
+### Reducing Dependencies
+- Can you build a simpler version that avoids the dependency?
+- Can you parallelize by using an interface contract or mock?
+- Can you sequence differently to move the dependency earlier?
+- Can you absorb the work into your team to remove the cross-team coordination?
+
+## Capacity Planning
+
+### Estimating Capacity
+- Start with the number of engineers and the time period
+- Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO
+- A common rule of thumb: engineers spend 60-70% of time on planned feature work
+- Factor in team ramp time for new members
+
+### Allocating Capacity
+A healthy allocation for most product teams:
+
+- **70% planned features**: Roadmap items that advance strategic goals
+- **20% technical health**: Tech debt, reliability, performance, developer experience
+- **10% unplanned**: Buffer for urgent issues, quick wins, and requests from other teams
+
+Adjust ratios based on team context:
+- New product: more feature work, less tech debt
+- Mature product: more tech debt and reliability investment
+- Post-incident: more reliability, less features
+- Rapid growth: more scalability and performance
+
+### Capacity vs Ambition
+- If roadmap commitments exceed capacity, something must give
+- Do not solve capacity problems by pretending people can do more — solve by cutting scope
+- When adding to the roadmap, always ask: "What comes off?"
+- Better to commit to fewer things and deliver reliably than to overcommit and disappoint
+
+## Communicating Roadmap Changes
+
+### When the Roadmap Changes
+Common triggers for roadmap changes:
+- New strategic priority from leadership
+- Customer feedback or research that changes priorities
+- Technical discovery that changes estimates
+- Dependency slip from another team
+- Resource change (team grows or shrinks, key person leaves)
+- Competitive move that requires response
+
+### How to Communicate Changes
+1. **Acknowledge the change**: Be direct about what is changing and why
+2. **Explain the reason**: What new information drove this decision?
+3. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping?
+4. **Show the new plan**: Updated roadmap with the changes reflected
+5. **Acknowledge impact**: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.
+
+### Avoiding Roadmap Whiplash
+- Do not change the roadmap for every piece of new information. Have a threshold for change.
+- Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.
+- Distinguish between "roadmap change" (strategic reprioritization) and "scope adjustment" (normal execution refinement).
+- Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.
+
+## Output Format
+
+Use a clear, scannable format. Tables work well for roadmap items. Use text status labels: **Done**, **On Track**, **At Risk**, **Blocked**, **Not Started**.
+
+## Tips
+
+- A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.
+- When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.
+- Flag capacity issues early. If the roadmap has more work than the team can handle, say so.
+- Dependencies are the biggest risk to roadmaps. Surface them explicitly.
+- If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.

package/content/product-management/skills/product-management-sprint-planning/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: sprint-planning
+description: Plan a sprint — scope work, estimate capacity, set goals, and draft a sprint plan. Use when kicking off a new sprint, sizing a backlog against team availability (accounting for PTO and meetings), deciding what's P0 vs. stretch, or handling carryover from the last sprint.
+argument-hint: "[sprint name or date range]"
+---
+
+# /sprint-planning
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Plan a sprint by scoping work, estimating capacity, and setting clear goals.
+
+## Usage
+
+```
+/sprint-planning $ARGUMENTS
+```
+
+## How It Works
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                    SPRINT PLANNING                                 │
+├─────────────────────────────────────────────────────────────────┤
+│  STANDALONE (always works)                                       │
+│  ✓ Define sprint goals and success criteria                     │
+│  ✓ Estimate team capacity (accounting for PTO, meetings)        │
+│  ✓ Scope and prioritize backlog items                           │
+│  ✓ Identify dependencies and risks                              │
+│  ✓ Generate sprint plan document                                │
+├─────────────────────────────────────────────────────────────────┤
+│  SUPERCHARGED (when you connect your tools)                      │
+│  + Project tracker: Pull backlog, create sprint, assign items   │
+│  + Calendar: Account for PTO and meetings in capacity           │
+│  + Chat: Share sprint plan with the team                        │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## What I Need From You
+
+- **Team**: Who's on the team and their availability this sprint?
+- **Sprint length**: How many days/weeks?
+- **Backlog**: What's prioritized? (Pull from tracker, paste, or describe)
+- **Carryover**: Anything unfinished from last sprint?
+- **Dependencies**: Anything blocked on other teams?
+
+## Output
+
+```markdown
+## Sprint Plan: [Sprint Name]
+**Dates:** [Start] — [End] | **Team:** [X] engineers
+**Sprint Goal:** [One clear sentence about what success looks like]
+
+### Capacity
+| Person | Available Days | Allocation | Notes |
+|--------|---------------|------------|-------|
+| [Name] | [X] of [Y] | [X] points/hours | [PTO, on-call, etc.] |
+| **Total** | **[X]** | **[X] points** | |
+
+### Sprint Backlog
+| Priority | Item | Estimate | Owner | Dependencies |
+|----------|------|----------|-------|--------------|
+| P0 | [Must ship] | [X] pts | [Person] | [None / Blocked by X] |
+| P1 | [Should ship] | [X] pts | [Person] | [None] |
+| P2 | [Stretch] | [X] pts | [Person] | [None] |
+
+### Planned Capacity: [X] points | Sprint Load: [X] points ([X]% of capacity)
+
+### Risks
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| [Risk] | [What happens] | [What to do] |
+
+### Definition of Done
+- [ ] Code reviewed and merged
+- [ ] Tests passing
+- [ ] Documentation updated (if applicable)
+- [ ] Product sign-off
+
+### Key Dates
+| Date | Event |
+|------|-------|
+| [Date] | Sprint start |
+| [Date] | Mid-sprint check-in |
+| [Date] | Sprint end / Demo |
+| [Date] | Retro |
+```
+
+## Tips
+
+1. **Leave buffer** — Plan to 70-80% capacity. You will get interrupts.
+2. **One clear sprint goal** — If you can't state it in one sentence, the sprint is unfocused.
+3. **Identify stretch items** — Know what to cut if things take longer than expected.
+4. **Carry over honestly** — If something didn't ship, understand why before re-committing.