[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7ERRED634STGD5H630RG2N2":3,"skill-same:01M7ERRED634STGD5H630RG2N2":53},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M7ERRED634STGD5H630RG2N2","roadmap-update",null,"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\u002FNext\u002FLater view from scratch.","TanNhatCMS\u002Fjarvis","TanNhatCMS","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113796420?v=4","01M753MV17KG5CD3152G3WQEQY","KietNT","01M7EKEDYVYQ6PWVJJMZ911VMX",0,"MIT","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fams-kw-roadmap-update\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: roadmap-update\ndescription: 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\u002FNext\u002FLater view from scratch.\nargument-hint: \"\u003Cupdate description>\"\n---\n\n\u003C!-- Provenance: adapted from anthropics\u002Fknowledge-work-plugins (Apache-2.0, (c) Anthropic).\nOriginal skill: https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Ftree\u002Fmain\u002Fproduct-management\u002Fskills\u002Froadmap-update. Changes for Muse AI: Claude\u002FCowork product refs -> Muse AI; MCP -> connector; CLAUDE.md -> MUSE.md; ${CLAUDE_PLUGIN_ROOT} -> this skill's directory; \u002Fplugin:command refs -> skill refs. -->\n\n\n# Roadmap Update\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](.\u002FCONNECTORS.md).\n\nUpdate, create, or reprioritize a product roadmap.\n\n## Usage\n\n```\n\u002Froadmap-update $ARGUMENTS\n```\n\n## Workflow\n\n### 1. Understand Current State\n\nIf **~~project tracker** is connected:\n- Pull current roadmap items with their statuses, assignees, and dates\n- Identify items that are overdue, at risk, or recently completed\n- Surface any items without clear owners or dates\n\nIf no project management tool is connected:\n- Ask the user to describe their current roadmap or paste\u002Fupload it\n- Accept any format: list, table, spreadsheet, screenshot, or prose description\n\n### 2. Determine the Operation\n\nAsk what the user wants to do:\n\n**Add item**: New feature, initiative, or work item to the roadmap\n- Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies\n- Suggest where it fits based on current priorities and capacity\n\n**Update status**: Change status of existing items\n- Options: not started, in progress, at risk, blocked, completed, cut\n- For \"at risk\" or \"blocked\": ask for the blocker and mitigation plan\n\n**Reprioritize**: Change the order or priority of items\n- Ask what changed (new information, strategy shift, resource change, customer feedback)\n- Apply a prioritization framework if helpful — see **Prioritization Frameworks** below for RICE, MoSCoW, ICE, and value-vs-effort\n- Show before\u002Fafter comparison\n\n**Move timeline**: Shift dates for items\n- Ask why (scope change, dependency slip, resource constraint)\n- Identify downstream impacts on dependent items\n- Flag items that move past hard deadlines\n\n**Create new roadmap**: Build a roadmap from scratch\n- Ask about timeframe (quarter, half, year)\n- Ask about format preference (Now\u002FNext\u002FLater, quarterly columns, OKR-aligned) — see **Roadmap Frameworks** below\n- Gather the list of initiatives to include\n\n### 3. Generate Roadmap Summary\n\nProduce a roadmap view with:\n\n#### Status Overview\nQuick summary: X items in progress, Y completed this period, Z at risk.\n\n#### Roadmap Items\nFor each item, show:\n- Name and one-line description\n- Status indicator (on track \u002F at risk \u002F blocked \u002F completed \u002F not started)\n- Target timeframe or date\n- Owner\n- Key dependencies\n\nGroup items by:\n- Timeframe (Now \u002F Next \u002F Later) or quarter, depending on format\n- Or by theme\u002Fgoal if the user prefers\n\n#### Risks and Dependencies\n- Items that are blocked or at risk, with details\n- Cross-team dependencies and their status\n- Items approaching hard deadlines\n\n#### Changes This Update\nIf this is an update to an existing roadmap, summarize what changed:\n- Items added, removed, or reprioritized\n- Timeline shifts\n- Status changes\n\n### 4. Follow Up\n\nAfter generating the roadmap:\n- Offer to format for a specific audience (executive summary, engineering detail, customer-facing)\n- Offer to draft communication about roadmap changes\n- If project management tool is connected, offer to update ticket statuses\n\n## Roadmap Frameworks\n\n### Now \u002F Next \u002F Later\nThe simplest and often most effective roadmap format:\n\n- **Now** (current sprint\u002Fmonth): Committed work. High confidence in scope and timeline. These are the things the team is actively building.\n- **Next** (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.\n- **Later** (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.\n\nWhen to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.\n\n### Quarterly Themes\nOrganize the roadmap around 2-3 themes per quarter:\n\n- Each theme represents a strategic area of investment (e.g., \"Enterprise readiness\", \"Activation improvements\", \"Platform extensibility\")\n- Under each theme, list the specific initiatives planned\n- Themes should map to company or team OKRs\n- This format makes it easy to explain WHY you are building what you are building\n\nWhen to use: When you need to show strategic alignment. Good for planning meetings and executive communication.\n\n### OKR-Aligned Roadmap\nMap roadmap items directly to Objectives and Key Results:\n\n- Start with the team's OKRs for the period\n- Under each Key Result, list the initiatives that will move that metric\n- Include the expected impact of each initiative on the Key Result\n- This creates clear accountability between what you build and what you measure\n\nWhen to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear \"why\" tied to measurable outcomes.\n\n### Timeline \u002F Gantt View\nCalendar-based view with items on a timeline:\n\n- Shows start dates, end dates, and durations\n- Visualizes parallelism and sequencing\n- Good for identifying resource conflicts\n- Shows dependencies between items\n\nWhen to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).\n\n## Prioritization Frameworks\n\n### RICE Score\nScore each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) \u002F Effort\n\n- **Reach**: How many users\u002Fcustomers will this affect in a given time period? Use concrete numbers (e.g., \"500 users per quarter\").\n- **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.\n- **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).\n- **Effort**: How many person-months of work? Include engineering, design, and any other functions.\n\nWhen 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.\n\n### MoSCoW\nCategorize items into Must have, Should have, Could have, Won't have:\n\n- **Must have**: The roadmap is a failure without these. Non-negotiable commitments.\n- **Should have**: Important and expected, but delivery is viable without them.\n- **Could have**: Desirable but clearly lower priority. Include only if capacity allows.\n- **Won't have**: Explicitly out of scope for this period. Important to list for clarity.\n\nWhen to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.\n\n### ICE Score\nSimpler than RICE. Score each item 1-10 on three dimensions:\n\n- **Impact**: How much will this move the target metric?\n- **Confidence**: How confident are we in the impact estimate?\n- **Ease**: How easy is this to implement? (Inverse of effort — higher = easier)\n\nICE Score = Impact x Confidence x Ease\n\nWhen to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.\n\n### Value vs Effort Matrix\nPlot initiatives on a 2x2 matrix:\n\n- **High value, Low effort** (Quick wins): Do these first.\n- **High value, High effort** (Big bets): Plan these carefully. Worth the investment but need proper scoping.\n- **Low value, Low effort** (Fill-ins): Do these when you have spare capacity.\n- **Low value, High effort** (Money pits): Do not do these. Remove from the backlog.\n\nWhen to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.\n\n## Dependency Mapping\n\n### Identifying Dependencies\nLook for dependencies across these categories:\n\n- **Technical dependencies**: Feature B requires infrastructure work from Feature A\n- **Team dependencies**: Feature requires work from another team (design, platform, data)\n- **External dependencies**: Waiting on a vendor, partner, or third-party integration\n- **Knowledge dependencies**: Need research or investigation results before starting\n- **Sequential dependencies**: Must ship Feature A before starting Feature B (shared code, user flow)\n\n### Managing Dependencies\n- List all dependencies explicitly in the roadmap\n- Assign an owner to each dependency (who is responsible for resolving it)\n- Set a \"need by\" date: when does the depending item need this resolved\n- Build buffer around dependencies — they are the highest-risk items on any roadmap\n- Flag dependencies that cross team boundaries early — these require coordination\n- Have a contingency plan: what do you do if the dependency slips?\n\n### Reducing Dependencies\n- Can you build a simpler version that avoids the dependency?\n- Can you parallelize by using an interface contract or mock?\n- Can you sequence differently to move the dependency earlier?\n- Can you absorb the work into your team to remove the cross-team coordination?\n\n## Capacity Planning\n\n### Estimating Capacity\n- Start with the number of engineers and the time period\n- Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO\n- A common rule of thumb: engineers spend 60-70% of time on planned feature work\n- Factor in team ramp time for new members\n\n### Allocating Capacity\nA healthy allocation for most product teams:\n\n- **70% planned features**: Roadmap items that advance strategic goals\n- **20% technical health**: Tech debt, reliability, performance, developer experience\n- **10% unplanned**: Buffer for urgent issues, quick wins, and requests from other teams\n\nAdjust ratios based on team context:\n- New product: more feature work, less tech debt\n- Mature product: more tech debt and reliability investment\n- Post-incident: more reliability, less features\n- Rapid growth: more scalability and performance\n\n### Capacity vs Ambition\n- If roadmap commitments exceed capacity, something must give\n- Do not solve capacity problems by pretending people can do more — solve by cutting scope\n- When adding to the roadmap, always ask: \"What comes off?\"\n- Better to commit to fewer things and deliver reliably than to overcommit and disappoint\n\n## Communicating Roadmap Changes\n\n### When the Roadmap Changes\nCommon triggers for roadmap changes:\n- New strategic priority from leadership\n- Customer feedback or research that changes priorities\n- Technical discovery that changes estimates\n- Dependency slip from another team\n- Resource change (team grows or shrinks, key person leaves)\n- Competitive move that requires response\n\n### How to Communicate Changes\n1. **Acknowledge the change**: Be direct about what is changing and why\n2. **Explain the reason**: What new information drove this decision?\n3. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping?\n4. **Show the new plan**: Updated roadmap with the changes reflected\n5. **Acknowledge impact**: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.\n\n### Avoiding Roadmap Whiplash\n- Do not change the roadmap for every piece of new information. Have a threshold for change.\n- Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.\n- Distinguish between \"roadmap change\" (strategic reprioritization) and \"scope adjustment\" (normal execution refinement).\n- Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.\n\n## Output Format\n\nUse a clear, scannable format. Tables work well for roadmap items. Use text status labels: **Done**, **On Track**, **At Risk**, **Blocked**, **Not Started**.\n\n## Tips\n\n- A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.\n- When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.\n- Flag capacity issues early. If the roadmap has more work than the team can handle, say so.\n- Dependencies are the biggest risk to roadmaps. Surface them explicitly.\n- If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.\n","\u003C!-- Provenance: adapted from anthropics\u002Fknowledge-work-plugins (Apache-2.0, (c) Anthropic).\nOriginal skill: https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Ftree\u002Fmain\u002Fproduct-management\u002Fskills\u002Froadmap-update. Changes for Muse AI: Claude\u002FCowork product refs -> Muse AI; MCP -> connector; CLAUDE.md -> MUSE.md; ${CLAUDE_PLUGIN_ROOT} -> this skill's directory; \u002Fplugin:command refs -> skill refs. -->\n\n\n# Roadmap Update\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](.\u002FCONNECTORS.md).\n\nUpdate, create, or reprioritize a product roadmap.\n\n## Usage\n\n```\n\u002Froadmap-update $ARGUMENTS\n```\n\n## Workflow\n\n### 1. Understand Current State\n\nIf **~~project tracker** is connected:\n- Pull current roadmap items with their statuses, assignees, and dates\n- Identify items that are overdue, at risk, or recently completed\n- Surface any items without clear owners or dates\n\nIf no project management tool is connected:\n- Ask the user to describe their current roadmap or paste\u002Fupload it\n- Accept any format: list, table, spreadsheet, screenshot, or prose description\n\n### 2. Determine the Operation\n\nAsk what the user wants to do:\n\n**Add item**: New feature, initiative, or work item to the roadmap\n- Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies\n- Suggest where it fits based on current priorities and capacity\n\n**Update status**: Change status of existing items\n- Options: not started, in progress, at risk, blocked, completed, cut\n- For \"at risk\" or \"blocked\": ask for the blocker and mitigation plan\n\n**Reprioritize**: Change the order or priority of items\n- Ask what changed (new information, strategy shift, resource change, customer feedback)\n- Apply a prioritization framework if helpful — see **Prioritization Frameworks** below for RICE, MoSCoW, ICE, and value-vs-effort\n- Show before\u002Fafter comparison\n\n**Move timeline**: Shift dates for items\n- Ask why (scope change, dependency slip, resource constraint)\n- Identify downstream impacts on dependent items\n- Flag items that move past hard deadlines\n\n**Create new roadmap**: Build a roadmap from scratch\n- Ask about timeframe (quarter, half, year)\n- Ask about format preference (Now\u002FNext\u002FLater, quarterly columns, OKR-aligned) — see **Roadmap Frameworks** below\n- Gather the list of initiatives to include\n\n### 3. Generate Roadmap Summary\n\nProduce a roadmap view with:\n\n#### Status Overview\nQuick summary: X items in progress, Y completed this period, Z at risk.\n\n#### Roadmap Items\nFor each item, show:\n- Name and one-line description\n- Status indicator (on track \u002F at risk \u002F blocked \u002F completed \u002F not started)\n- Target timeframe or date\n- Owner\n- Key dependencies\n\nGroup items by:\n- Timeframe (Now \u002F Next \u002F Later) or quarter, depending on format\n- Or by theme\u002Fgoal if the user prefers\n\n#### Risks and Dependencies\n- Items that are blocked or at risk, with details\n- Cross-team dependencies and their status\n- Items approaching hard deadlines\n\n#### Changes This Update\nIf this is an update to an existing roadmap, summarize what changed:\n- Items added, removed, or reprioritized\n- Timeline shifts\n- Status changes\n\n### 4. Follow Up\n\nAfter generating the roadmap:\n- Offer to format for a specific audience (executive summary, engineering detail, customer-facing)\n- Offer to draft communication about roadmap changes\n- If project management tool is connected, offer to update ticket statuses\n\n## Roadmap Frameworks\n\n### Now \u002F Next \u002F Later\nThe simplest and often most effective roadmap format:\n\n- **Now** (current sprint\u002Fmonth): Committed work. High confidence in scope and timeline. These are the things the team is actively building.\n- **Next** (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.\n- **Later** (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.\n\nWhen to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.\n\n### Quarterly Themes\nOrganize the roadmap around 2-3 themes per quarter:\n\n- Each theme represents a strategic area of investment (e.g., \"Enterprise readiness\", \"Activation improvements\", \"Platform extensibility\")\n- Under each theme, list the specific initiatives planned\n- Themes should map to company or team OKRs\n- This format makes it easy to explain WHY you are building what you are building\n\nWhen to use: When you need to show strategic alignment. Good for planning meetings and executive communication.\n\n### OKR-Aligned Roadmap\nMap roadmap items directly to Objectives and Key Results:\n\n- Start with the team's OKRs for the period\n- Under each Key Result, list the initiatives that will move that metric\n- Include the expected impact of each initiative on the Key Result\n- This creates clear accountability between what you build and what you measure\n\nWhen to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear \"why\" tied to measurable outcomes.\n\n### Timeline \u002F Gantt View\nCalendar-based view with items on a timeline:\n\n- Shows start dates, end dates, and durations\n- Visualizes parallelism and sequencing\n- Good for identifying resource conflicts\n- Shows dependencies between items\n\nWhen to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).\n\n## Prioritization Frameworks\n\n### RICE Score\nScore each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) \u002F Effort\n\n- **Reach**: How many users\u002Fcustomers will this affect in a given time period? Use concrete numbers (e.g., \"500 users per quarter\").\n- **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.\n- **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).\n- **Effort**: How many person-months of work? Include engineering, design, and any other functions.\n\nWhen 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.\n\n### MoSCoW\nCategorize items into Must have, Should have, Could have, Won't have:\n\n- **Must have**: The roadmap is a failure without these. Non-negotiable commitments.\n- **Should have**: Important and expected, but delivery is viable without them.\n- **Could have**: Desirable but clearly lower priority. Include only if capacity allows.\n- **Won't have**: Explicitly out of scope for this period. Important to list for clarity.\n\nWhen to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.\n\n### ICE Score\nSimpler than RICE. Score each item 1-10 on three dimensions:\n\n- **Impact**: How much will this move the target metric?\n- **Confidence**: How confident are we in the impact estimate?\n- **Ease**: How easy is this to implement? (Inverse of effort — higher = easier)\n\nICE Score = Impact x Confidence x Ease\n\nWhen to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.\n\n### Value vs Effort Matrix\nPlot initiatives on a 2x2 matrix:\n\n- **High value, Low effort** (Quick wins): Do these first.\n- **High value, High effort** (Big bets): Plan these carefully. Worth the investment but need proper scoping.\n- **Low value, Low effort** (Fill-ins): Do these when you have spare capacity.\n- **Low value, High effort** (Money pits): Do not do these. Remove from the backlog.\n\nWhen to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.\n\n## Dependency Mapping\n\n### Identifying Dependencies\nLook for dependencies across these categories:\n\n- **Technical dependencies**: Feature B requires infrastructure work from Feature A\n- **Team dependencies**: Feature requires work from another team (design, platform, data)\n- **External dependencies**: Waiting on a vendor, partner, or third-party integration\n- **Knowledge dependencies**: Need research or investigation results before starting\n- **Sequential dependencies**: Must ship Feature A before starting Feature B (shared code, user flow)\n\n### Managing Dependencies\n- List all dependencies explicitly in the roadmap\n- Assign an owner to each dependency (who is responsible for resolving it)\n- Set a \"need by\" date: when does the depending item need this resolved\n- Build buffer around dependencies — they are the highest-risk items on any roadmap\n- Flag dependencies that cross team boundaries early — these require coordination\n- Have a contingency plan: what do you do if the dependency slips?\n\n### Reducing Dependencies\n- Can you build a simpler version that avoids the dependency?\n- Can you parallelize by using an interface contract or mock?\n- Can you sequence differently to move the dependency earlier?\n- Can you absorb the work into your team to remove the cross-team coordination?\n\n## Capacity Planning\n\n### Estimating Capacity\n- Start with the number of engineers and the time period\n- Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO\n- A common rule of thumb: engineers spend 60-70% of time on planned feature work\n- Factor in team ramp time for new members\n\n### Allocating Capacity\nA healthy allocation for most product teams:\n\n- **70% planned features**: Roadmap items that advance strategic goals\n- **20% technical health**: Tech debt, reliability, performance, developer experience\n- **10% unplanned**: Buffer for urgent issues, quick wins, and requests from other teams\n\nAdjust ratios based on team context:\n- New product: more feature work, less tech debt\n- Mature product: more tech debt and reliability investment\n- Post-incident: more reliability, less features\n- Rapid growth: more scalability and performance\n\n### Capacity vs Ambition\n- If roadmap commitments exceed capacity, something must give\n- Do not solve capacity problems by pretending people can do more — solve by cutting scope\n- When adding to the roadmap, always ask: \"What comes off?\"\n- Better to commit to fewer things and deliver reliably than to overcommit and disappoint\n\n## Communicating Roadmap Changes\n\n### When the Roadmap Changes\nCommon triggers for roadmap changes:\n- New strategic priority from leadership\n- Customer feedback or research that changes priorities\n- Technical discovery that changes estimates\n- Dependency slip from another team\n- Resource change (team grows or shrinks, key person leaves)\n- Competitive move that requires response\n\n### How to Communicate Changes\n1. **Acknowledge the change**: Be direct about what is changing and why\n2. **Explain the reason**: What new information drove this decision?\n3. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping?\n4. **Show the new plan**: Updated roadmap with the changes reflected\n5. **Acknowledge impact**: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.\n\n### Avoiding Roadmap Whiplash\n- Do not change the roadmap for every piece of new information. Have a threshold for change.\n- Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.\n- Distinguish between \"roadmap change\" (strategic reprioritization) and \"scope adjustment\" (normal execution refinement).\n- Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.\n\n## Output Format\n\nUse a clear, scannable format. Tables work well for roadmap items. Use text status labels: **Done**, **On Track**, **At Risk**, **Blocked**, **Not Started**.\n\n## Tips\n\n- A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.\n- When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.\n- Flag capacity issues early. If the roadmap has more work than the team can handle, say so.\n- Dependencies are the biggest risk to roadmaps. Surface them explicitly.\n- If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.\n",{"name":5,"description":7,"argument-hint":24},"\u003Cupdate description>","main","af388a77c2fe5e0b4fd879cca4300a0ffa9a6579","skills\u002Fams-kw-roadmap-update",1,"https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis","https:\u002F\u002Fgithub.com\u002FTanNhatCMS","https:\u002F\u002Fmrkiet.name.vn","2026-11-07 14:23:08",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add TanNhatCMS\u002Fjarvis --skill roadmap-update",{"tool":39,"command":40},"bunx","bunx skills add TanNhatCMS\u002Fjarvis --skill roadmap-update",{"tool":42,"command":43},"pnpm","pnpm dlx skills add TanNhatCMS\u002Fjarvis --skill roadmap-update","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fams-kw-roadmap-update\u002FSKILL.md",true,[47],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"CONNECTORS.md","REFERENCE","参考文档",1432,"https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fams-kw-roadmap-update\u002FCONNECTORS.md",[54,61,69,76,83,90],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M7EWYJR0J8DARY7E59Z6Y9MV","web-scrape","Turn web pages into LLM-ready markdown via the Firecrawl API (renders JS, anti-bot handling). Use when browser_open\u002Ffetch fails on JS-heavy pages, or when you need clean markdown\u002Fstructured extraction from a site. Requires FIRECRAWL_API_KEY.","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fweb-scrape\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":65,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7EWYBN5P6F2AJG3FR24T9BP","design-taste-frontend","tasteskill v2, the anti-slop frontend skill. Art direction for websites, distilled from a study of 247 curated gallery sites (One Page Love, Awwwards Sites of the Day). Deals researched directions (idea, composition, type, palette, photographs, section blueprints) from a library, enforces a strict no-slop house style with a real-browser inspector, and runs a look-and-fix loop on screenshots. Use this whenever you build, design, redesign, restyle, polish or review a landing page, marketing site, portfolio, product page, one-pager, hero or any public-facing web page, in any stack (HTML\u002FCSS, React, Next.js, Vue, Svelte, Astro, Tailwind) — also when the user says a page looks generic, templated, \"AI-made\", sloppy, or asks to make it look designed, premium, award-level or less like every other site. Not for dashboards or app screens.","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Ftaste-design\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Ftaste-design\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7EWY8FQFNQ2GB7NZZWGSSDX","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-tdd\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7EWY5SHBFRH1HDHVWM9K7TV","systematic-debugging","Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-debugging\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7EWY3NM0Z0JAKS7HDZ24K66","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-code-review\u002FSKILL.md",[],[],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M7EWY0WRMWX4M9ZFY0WKC593","brainstorming","You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-brainstorming\u002FSKILL.md",[],[]]