From b744c1e5b158b2e02c3b544376b4452983513d67 Mon Sep 17 00:00:00 2001
From: Graeme Rycyk <grae@workanywhere.io>
Date: Fri, 13 Feb 2026 23:19:43 +0100
Subject: [PATCH] updated the product-management skills

---
 product-management/README.md                  |  56 +++-
 product-management/commands/daily-brief.md    |  79 +++++
 .../commands/feature-ideation.md              |  86 ++++++
 product-management/commands/meeting-prep.md   |  85 ++++++
 product-management/commands/one-pager.md      |  82 ++++++
 product-management/commands/prototype.md      |  84 ++++++
 product-management/commands/release-notes.md  |  75 +++++
 product-management/commands/sprint-review.md  |  78 +++++
 product-management/commands/tldr.md           |  64 ++++
 .../skills/executive-synthesis/SKILL.md       | 159 ++++++++++
 .../skills/feature-spec/SKILL.md              |  30 ++
 .../skills/html-prototyping/SKILL.md          | 273 ++++++++++++++++++
 .../skills/meeting-preparation/SKILL.md       | 197 +++++++++++++
 .../skills/release-communication/SKILL.md     | 225 +++++++++++++++
 .../skills/roadmap-management/SKILL.md        |  30 ++
 .../skills/sprint-execution/SKILL.md          | 189 ++++++++++++
 16 files changed, 1789 insertions(+), 3 deletions(-)
 create mode 100644 product-management/commands/daily-brief.md
 create mode 100644 product-management/commands/feature-ideation.md
 create mode 100644 product-management/commands/meeting-prep.md
 create mode 100644 product-management/commands/one-pager.md
 create mode 100644 product-management/commands/prototype.md
 create mode 100644 product-management/commands/release-notes.md
 create mode 100644 product-management/commands/sprint-review.md
 create mode 100644 product-management/commands/tldr.md
 create mode 100644 product-management/skills/executive-synthesis/SKILL.md
 create mode 100644 product-management/skills/html-prototyping/SKILL.md
 create mode 100644 product-management/skills/meeting-preparation/SKILL.md
 create mode 100644 product-management/skills/release-communication/SKILL.md
 create mode 100644 product-management/skills/sprint-execution/SKILL.md

diff --git a/product-management/README.md b/product-management/README.md
index cbd25c8..e8f5d4e 100644
--- a/product-management/README.md
+++ b/product-management/README.md
@@ -13,11 +13,18 @@ claude plugins add knowledge-work-plugins/product-management
 This plugin gives you an AI-powered product management partner that can help with:
 
 - **Feature Specs & PRDs** — Generate structured product requirements documents from a problem statement or feature idea. Includes user stories, requirements prioritization, success metrics, and scope management.
-- **Roadmap Planning** — Create, update, and reprioritize your product roadmap. Supports Now/Next/Later, quarterly themes, and OKR-aligned formats with dependency mapping.
+- **Roadmap Planning** — Create, update, and reprioritize your product roadmap. Supports Now/Next/Later, quarterly themes, and OKR-aligned formats with dependency mapping and decision memos.
 - **Stakeholder Updates** — Generate status updates tailored to your audience (executives, engineering, customers). Pulls context from connected tools to save you the weekly update grind.
 - **User Research Synthesis** — Turn interview notes, survey data, and support tickets into structured insights. Identifies themes, builds personas, and surfaces opportunity areas with supporting evidence.
 - **Competitive Analysis** — Research competitors and generate briefs with feature comparisons, positioning analysis, and strategic implications.
 - **Metrics Review** — Analyze product metrics, identify trends, compare against targets, and surface actionable insights.
+- **Sprint Reviews** — Summarize sprint accomplishments with velocity metrics, demo highlights, and retrospective themes. Connects the dots between delivered work and product goals.
+- **Meeting Preparation** — Prepare for customer meetings, QBRs, and stakeholder calls with account context, talking points, risk assessment, and follow-up actions.
+- **Daily Briefs** — Start each day with a synthesis of overnight activity across Slack, project trackers, support tickets, and community channels.
+- **Prototyping** — Generate standalone interactive HTML prototypes from PRDs or feature descriptions. No dependencies, no build tools — just open in a browser.
+- **Release Notes** — Turn completed Jira tickets and PRD excerpts into polished, customer-facing release notes with proper categorization and tone.
+- **Feature Ideation** — Structure raw ideas from Slack threads, customer feedback, and brainstorms into validated feature concepts ready for a PRD.
+- **Executive Summaries** — Distill complex information into one-pagers (under 500 words) and TL;DRs (3-5 bullets) optimized for busy stakeholders.
 
 ## Commands
 
@@ -29,17 +36,30 @@ This plugin gives you an AI-powered product management partner that can help wit
 | `/synthesize-research` | Synthesize user research from interviews, surveys, and tickets |
 | `/competitive-brief` | Create a competitive analysis brief |
 | `/metrics-review` | Review and analyze product metrics |
+| `/daily-brief` | Synthesize overnight activity into a morning brief |
+| `/meeting-prep` | Prepare for customer meetings with context and talking points |
+| `/sprint-review` | Generate a sprint review summary with metrics and demos |
+| `/prototype` | Generate an interactive HTML prototype from a PRD or feature description |
+| `/release-notes` | Create customer-facing release notes from completed work |
+| `/feature-ideation` | Structure raw ideas into validated feature concepts |
+| `/one-pager` | Synthesize complex information into a one-page executive summary |
+| `/tldr` | Create a quick 3-5 bullet summary for Slack or email |
 
 ## Skills
 
 | Skill | What It Covers |
 |---|---|
-| `feature-spec` | PRD structure, user stories, requirements categorization, acceptance criteria |
-| `roadmap-management` | Prioritization frameworks (RICE, MoSCoW), roadmap formats, dependency mapping |
+| `feature-spec` | PRD structure, user stories, requirements categorization, acceptance criteria, idea structuring |
+| `roadmap-management` | Prioritization frameworks (RICE, MoSCoW), roadmap formats, dependency mapping, decision memos |
 | `stakeholder-comms` | Update templates by audience, risk communication, decision documentation |
 | `user-research-synthesis` | Thematic analysis, affinity mapping, persona development, opportunity sizing |
 | `competitive-analysis` | Feature comparison matrices, positioning analysis, win/loss analysis |
 | `metrics-tracking` | Product metrics hierarchy, goal setting (OKRs), dashboard design, review cadences |
+| `sprint-execution` | Sprint metrics, velocity analysis, demo preparation, burndown interpretation, retrospectives |
+| `meeting-preparation` | Account review methodology, talking point frameworks, risk identification, QBR planning |
+| `release-communication` | Customer-facing writing, changelog categorization, version conventions, deprecation lifecycle |
+| `executive-synthesis` | Pyramid principle, one-pager framework, TL;DR writing, audience adaptation |
+| `html-prototyping` | Design defaults, responsive layout patterns, interactive components, accessibility basics |
 
 ## Example Workflows
 
@@ -83,6 +103,36 @@ Claude: [Researches competitor onboarding approaches]
 Claude: [Generates brief with feature comparison, strengths/weaknesses, and strategic implications]
 ```
 
+### Sprint Review
+
+```
+You: /sprint-review
+Claude: What sprint are we reviewing? I'll also need the dates and team name.
+You: Sprint 42, Jan 6-17, Search Pod
+Claude: [Pulls completed tickets from project tracker, team discussion from Slack]
+Claude: [Generates sprint summary with velocity metrics, demo highlights, blockers, and customer feedback]
+```
+
+### Morning Brief
+
+```
+You: /daily-brief
+Claude: Good morning! What's your name and company? I'll synthesize what happened overnight.
+You: Jane, Acme Corp
+Claude: [Scans Slack channels, project tracker updates, support tickets]
+Claude: [Generates prioritized brief: what needs attention today, what's blocked, what shipped overnight]
+```
+
+### Interactive Prototype
+
+```
+You: /prototype
+Claude: What feature or flow should I prototype?
+You: A search results page with filters for content type, date range, and author
+Claude: [Generates a complete standalone HTML file with interactive filters, realistic data, and responsive layout]
+Claude: [Save as .html and open in your browser — no build tools needed]
+```
+
 ## Data Sources
 
 > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](CONNECTORS.md).
diff --git a/product-management/commands/daily-brief.md b/product-management/commands/daily-brief.md
new file mode 100644
index 0000000..d49f940
--- /dev/null
+++ b/product-management/commands/daily-brief.md
@@ -0,0 +1,79 @@
+---
+description: Synthesize overnight activity into a morning brief with urgent items, progress, and recommended actions
+argument-hint: "<date or 'today'>"
+---
+
+# Daily Brief
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Synthesize overnight activity into a prioritized morning brief.
+
+## Workflow
+
+### 1. Understand the Context
+
+Ask the user:
+- What date is this brief for? (Default to today)
+- What team or product area to focus on?
+- Any specific concerns or priorities to watch for?
+
+### 2. Pull Context from Connected Tools
+
+If **~~chat** is connected:
+- Pull overnight messages from key product and engineering channels
+- Identify threads with unresolved questions or escalations
+- Surface decisions made asynchronously
+- Note any direct messages or mentions requiring the user's attention
+
+If **~~project tracker** is connected:
+- Pull sprint status and recent ticket updates
+- Identify items that changed status overnight (moved to blocked, completed, or at risk)
+- Surface blockers or items flagged as urgent
+- Check sprint burndown progress
+
+If **~~user feedback** is connected:
+- Pull recent support tickets and their severity
+- Identify trending issues or spikes in ticket volume
+- Surface any critical or P0 tickets opened overnight
+
+If **~~meeting transcription** is connected:
+- Pull notes from recent meetings
+- Identify action items assigned to the user
+- Surface any decisions that affect the user's priorities
+
+If no tools are connected, ask the user to paste:
+- Recent Slack messages or team chat activity
+- Sprint or project updates from Jira, Linear, or similar
+- Support tickets or customer feedback
+- Community posts or feature requests
+
+### 3. Generate the Brief
+
+Produce a structured morning brief. See the **sprint-execution** skill for sprint health indicators and the **meeting-preparation** skill for upcoming meeting context.
+
+- **TL;DR**: 2-3 sentence summary of the most important things from overnight
+- **Urgent Items**: Blockers, escalations, critical bugs — anything requiring action today
+- **Sprint Progress**: Current sprint status, notable completions, items at risk
+- **Customer Signals**: Key feedback from support and community channels
+- **Recommended Actions**: Top 3 things to focus on today, ordered by priority
+
+### 4. Follow Up
+
+After generating the brief:
+- Offer to draft responses to urgent items
+- Offer to create a standup update from the brief
+- Offer to investigate any concerning signals in more depth
+- Offer to prep for any meetings happening today
+
+## Output Format
+
+Use markdown with clear headers. Keep the brief scannable — the reader should get the essential picture in 60 seconds.
+
+## Tips
+
+- Prioritize ruthlessly. A brief that highlights everything highlights nothing.
+- Blockers and escalations always come first, before progress updates.
+- Customer signals are often the most strategically important part — do not bury them.
+- Recommended actions should be specific and time-bound, not vague suggestions.
+- If there is nothing urgent, say so. "No fires" is valuable information.
diff --git a/product-management/commands/feature-ideation.md b/product-management/commands/feature-ideation.md
new file mode 100644
index 0000000..be73e8b
--- /dev/null
+++ b/product-management/commands/feature-ideation.md
@@ -0,0 +1,86 @@
+---
+description: Structure raw ideas, feedback, and problems into concrete feature concepts with action plans
+argument-hint: "<idea or problem statement>"
+---
+
+# Feature Ideation
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Transform raw ideas into structured feature concepts. This is the upstream step before `/write-spec` — use it when an idea needs shaping before it is ready for a full PRD.
+
+## Workflow
+
+### 1. Understand the Raw Idea
+
+Ask the user what they are working with. Accept any of:
+- A raw idea ("We should add AI search")
+- A customer problem ("Users cannot find content quickly")
+- A feature request ("Customer X wants bulk export")
+- A Slack thread or brainstorm output ("Here is what the team discussed...")
+- A competitive observation ("Competitor Y just launched Z")
+
+### 2. Gather Signal
+
+Ask the user about the evidence behind this idea. Be conversational — do not dump all questions at once:
+
+- **Customer signal**: Who is asking for this? How many customers or users? How often does it come up?
+- **Problem severity**: How painful is the current state? What workaround do people use today?
+- **Strategic alignment**: Does this connect to a company or team goal?
+- **Competitive context**: Are competitors doing this? Is it table stakes or a differentiator?
+- **Constraints**: Any known technical, timeline, or resource constraints?
+
+### 3. Pull Context from Connected Tools
+
+If **~~chat** is connected:
+- Search for related Slack discussions about this idea
+- Pull threads where customers or teammates have mentioned the problem
+- Identify any prior decisions or discussions about this area
+
+If **~~user feedback** is connected:
+- Search for related support tickets or feature requests
+- Count how many customers have asked for something similar
+- Pull representative quotes from customer feedback
+
+If **~~product analytics** is connected:
+- Pull usage data related to the problem area
+- Search for behavioral signals (drop-offs, workarounds, low adoption)
+- Find data that quantifies the impact of the problem
+
+If these tools are not connected, work from what the user provides. Explicitly note where more data would strengthen the concept.
+
+### 4. Generate the Feature Concept
+
+Produce a structured feature concept document. See the **feature-spec** skill (especially the Idea Structuring section) for guidance on moving from raw idea to PRD-ready concept.
+
+- **Problem Definition**: What user problem does this solve? Who experiences it? How severe is it? (2-3 sentences, grounded in evidence)
+- **Customer Signal Summary**: What evidence supports this idea? Number of requests, support tickets, community votes, competitive pressure.
+- **Solution Options**: 2-3 approaches to solving the problem:
+  - **Option A**: Simplest version that addresses the core problem
+  - **Option B**: More comprehensive approach with broader impact
+  - **Option C**: Different angle or creative alternative
+  - For each: brief description, estimated effort, expected impact, key risk
+- **Assumptions to Validate**: What must be true for this to work? List 3-5 assumptions that should be tested before committing.
+- **Open Questions**: What do we not know yet? Tag each with who should answer.
+- **Recommended Next Step**: Is this ready for a PRD? Should we prototype first? Run customer interviews? Analyze data?
+- **2-Week Action Plan**: Specific steps to move this forward, with owners and dates.
+
+### 5. Follow Up
+
+After generating the concept:
+- Offer to turn it into a full PRD using `/write-spec`
+- Offer to create a prototype of the most promising option using `/prototype`
+- Offer to draft customer interview questions to validate assumptions
+- Offer to create a one-pager summary for stakeholder alignment
+
+## Output Format
+
+Use markdown with clear headers. Keep the document to 1-2 pages — this is a concept document, not a full spec. The goal is to structure thinking enough to make a go/no-go decision on further investment.
+
+## Tips
+
+- Do not fall in love with the first solution. Generate at least 2-3 options before recommending one.
+- The "Assumptions to Validate" section is the most important part. Every idea has hidden assumptions that can make or break it.
+- Be direct about signal strength. "2 customers mentioned this once" is different from "47 support tickets in 3 months."
+- The recommended next step should match the signal strength. Strong signal → write the PRD. Weak signal → validate first.
+- Keep the action plan to 2 weeks. If it takes longer to validate an idea, the idea may be too big or too vague.
diff --git a/product-management/commands/meeting-prep.md b/product-management/commands/meeting-prep.md
new file mode 100644
index 0000000..1f7724d
--- /dev/null
+++ b/product-management/commands/meeting-prep.md
@@ -0,0 +1,85 @@
+---
+description: Prepare for a customer meeting with account context, talking points, risks, and questions to ask
+argument-hint: "<account name and meeting type>"
+---
+
+# Meeting Prep
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Generate a meeting preparation pack with account context, talking points, and risk assessment.
+
+## Workflow
+
+### 1. Understand the Meeting
+
+Ask the user:
+- What account or customer is this meeting with?
+- What type of meeting? (QBR, check-in, escalation, executive briefing, sales call)
+- When is the meeting?
+- Who is attending from the customer side? What are their roles and priorities?
+- Any specific topics or concerns to address?
+
+### 2. Pull Context from Connected Tools
+
+If **~~user feedback** is connected:
+- Pull open support tickets for this account and their severity
+- Search for recent feature requests or feedback from this customer
+- Check support ticket volume and resolution time trends
+
+If **~~meeting transcription** is connected:
+- Pull notes from previous meetings with this account
+- Identify open action items from the last meeting
+- Surface recurring themes or concerns raised in past calls
+
+If **~~chat** is connected:
+- Search for recent internal conversations about this account
+- Pull any customer-facing thread activity
+- Identify any escalations or urgent issues discussed
+
+If **~~knowledge base** is connected:
+- Search for account plans, success plans, or internal notes
+- Pull any relevant case studies or reference materials
+- Find related feature specs or roadmap items
+
+If **~~project tracker** is connected:
+- Search for tickets tagged with this account or customer
+- Pull status on any committed deliverables for this customer
+
+If these tools are not connected, ask the user to paste:
+- Account health score, NPS, and contract details
+- Recent support tickets for this account
+- Previous meeting notes or Gong call summaries
+- Any relevant internal context
+
+### 3. Generate the Prep Pack
+
+Produce a structured meeting preparation document. See the **meeting-preparation** skill for detailed guidance on account review methodology, talking point frameworks, and risk identification.
+
+- **Account Snapshot**: Key facts — contract details, health score, tenure, usage summary
+- **Meeting Context**: Type, attendees with roles, and agenda
+- **Talking Points**: Proactive points (what you want to communicate), reactive points (what they will likely ask), and discovery questions (what you want to learn)
+- **Open Items**: Status of their feature requests, support tickets, and previous action items
+- **Risks**: Issues that could come up — escalations, delays, competitor mentions, renewal concerns
+- **Opportunities**: Expansion potential, case study opportunity, new stakeholder introduction
+- **Recommended Approach**: How to structure the conversation and what outcome to aim for
+
+### 4. Follow Up
+
+After generating the prep pack:
+- Offer to draft the meeting agenda to send in advance
+- Offer to prepare specific talking point scripts for sensitive topics
+- Offer to create a post-meeting summary template
+- Offer to prep a QBR deck if this is a quarterly review
+
+## Output Format
+
+Use markdown with clear headers. Keep the document actionable — the reader should be able to walk into the meeting confidently after a 5-minute read.
+
+## Tips
+
+- Know who is in the room. Different stakeholders care about different things — a CTO cares about technical roadmap, a VP of Ops cares about support and reliability.
+- Review previous meeting action items before the call. Nothing erodes trust faster than forgotten commitments.
+- Prepare at least 3 discovery questions. Meetings where you only present and never learn are wasted opportunities.
+- If there are known issues or risks, address them proactively rather than waiting for the customer to bring them up.
+- Have a clear outcome in mind for every meeting. What do you want to be true after the meeting that is not true before it?
diff --git a/product-management/commands/one-pager.md b/product-management/commands/one-pager.md
new file mode 100644
index 0000000..81fd3e2
--- /dev/null
+++ b/product-management/commands/one-pager.md
@@ -0,0 +1,82 @@
+---
+description: Synthesize multiple inputs into a concise one-page executive summary under 500 words
+argument-hint: "<topic or documents to synthesize>"
+---
+
+# One-Pager
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Distill complex information into a one-page executive summary.
+
+## Workflow
+
+### 1. Understand the Purpose
+
+Ask the user:
+- What is this one-pager for? (Board meeting, executive review, stakeholder alignment, project kickoff)
+- Who is the audience? (C-suite, board, cross-functional leaders, investors)
+- What is the core topic or initiative?
+- What outcome do you want from the reader? (Decision, approval, awareness, funding)
+
+### 2. Gather Source Material
+
+Ask the user for the documents or data to synthesize. Accept any combination of:
+- PRDs, spec documents, or project plans
+- Research reports or analysis documents
+- Sprint reviews or progress updates
+- Metrics dashboards or data exports
+- Strategy documents or OKR updates
+- Meeting notes or decision records
+
+### 3. Pull Context from Connected Tools
+
+If **~~knowledge base** is connected:
+- Search for related documents, specs, and reports
+- Pull relevant meeting notes and decision records
+- Find related strategy documents or OKR updates
+
+If **~~product analytics** is connected:
+- Pull key metrics related to the topic
+- Search for trend data and benchmarks
+- Find usage data that supports the narrative
+
+If **~~project tracker** is connected:
+- Pull status on related initiatives
+- Search for milestone progress and timeline updates
+
+If these tools are not connected, work entirely from what the user provides. Ask the user to paste or describe the source material.
+
+### 4. Generate the One-Pager
+
+Produce a concise executive summary. See the **executive-synthesis** skill for detailed guidance on the pyramid principle, audience adaptation, and synthesis process.
+
+Strict constraint: **Under 500 words.** Every word must earn its place.
+
+- **Title**: Clear and specific. "[Initiative] — [Status/Purpose]"
+- **TL;DR**: 2-3 sentences capturing the full message. If the reader stops here, they should have the essential point.
+- **Context**: Minimum background needed for a new reader (2-3 sentences maximum, not a full history)
+- **Key Findings**: 3-5 most important data points or insights, each in one sentence. Quantify wherever possible.
+- **Recommendation**: What should happen next, stated clearly and directly (1-2 sentences)
+- **Next Steps**: 2-3 specific actions with owners and timelines
+
+### 5. Follow Up
+
+After generating the one-pager:
+- Offer to create a TL;DR version for Slack using `/tldr`
+- Offer to expand into a full presentation using `/stakeholder-update`
+- Offer to adjust the tone for a different audience
+- Offer to add an appendix with supporting data
+
+## Output Format
+
+Use markdown with clear headers. The document must fit on one printed page — approximately 400-500 words. Use bullet points sparingly and only when they improve scannability.
+
+## Tips
+
+- Start with the recommendation, not the background. Executives want your answer before your analysis.
+- Every claim should be backed by a specific data point. "Significant improvement" is not useful; "40% reduction in search time" is.
+- Three sentences of context maximum. Assume the reader knows the background or can ask.
+- If you cannot state the TL;DR in 2-3 sentences, you have not synthesized enough. Go back and clarify the governing thought.
+- Cut adverbs and qualifiers. "Very significant improvement of approximately 40%" becomes "40% improvement."
+- Test the one-pager: can someone unfamiliar with the project understand the recommendation and next steps? If not, revise.
diff --git a/product-management/commands/prototype.md b/product-management/commands/prototype.md
new file mode 100644
index 0000000..647a890
--- /dev/null
+++ b/product-management/commands/prototype.md
@@ -0,0 +1,84 @@
+---
+description: Generate a standalone interactive HTML prototype from a PRD or feature description
+argument-hint: "<PRD or feature description>"
+---
+
+# Prototype
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Generate an interactive HTML prototype that can be opened directly in a browser.
+
+**CRITICAL**: Output ONLY a complete, standalone HTML file. No markdown wrapping, no code fences, no explanations — just the raw HTML that can be saved as a `.html` file and opened in a browser.
+
+## Workflow
+
+### 1. Understand What to Prototype
+
+Ask the user:
+- What feature or flow should the prototype demonstrate?
+- Is there a PRD, spec, or feature description to work from?
+- Which screens or pages are most important to show?
+- Any specific interactions to include? (Filters, tabs, forms, modals)
+
+Accept any of:
+- A full PRD or spec document
+- A brief feature description ("search results page with filters")
+- A user flow ("onboarding wizard with 3 steps")
+- A reference ("something like Notion's sidebar navigation")
+
+### 2. Pull Context from Connected Tools
+
+If **~~design** is connected:
+- Pull related mockups, wireframes, or design explorations
+- Search for design system components and tokens (colors, fonts, spacing)
+- Use existing design patterns as a reference for consistency
+
+If **~~knowledge base** is connected:
+- Search for related PRDs, specs, or feature descriptions
+- Pull any design guidelines or brand documentation
+- Find related user research that informs the design
+
+If these tools are not connected, work from what the user provides. Ask about:
+- Design preferences (color scheme, style — modern, minimal, playful)
+- Specific components to include (sidebar, data table, dashboard cards, forms)
+- What data should the prototype show? (Realistic example content)
+
+### 3. Generate the Prototype
+
+Produce a complete, standalone HTML file. See the **html-prototyping** skill for detailed guidance on design defaults, layout patterns, interactive components, and accessibility basics.
+
+The HTML file must:
+- Be completely self-contained (all CSS in `<style>`, all JS in `<script>`)
+- Work when opened directly in a browser — no server, no build tools, no dependencies
+- Use modern CSS (flexbox, grid, CSS variables) for layout
+- Include interactive elements using vanilla JavaScript (no libraries)
+- Use realistic placeholder data that tells a story
+- Be responsive and work on different screen sizes
+- Follow accessibility basics (semantic HTML, sufficient contrast, keyboard navigation)
+
+Default to a professional design with:
+- Indigo/blue primary color palette
+- System fonts for maximum compatibility
+- Subtle shadows and rounded corners
+- Clean typography with clear hierarchy
+
+### 4. Follow Up
+
+After generating the prototype:
+- Offer to adjust the design (colors, layout, typography)
+- Offer to add additional screens or flows
+- Offer to make specific interactions more detailed
+- Offer to create a simpler or more polished version
+
+## Output Format
+
+Output a complete, standalone HTML file. No markdown wrapping, no code fences — just the raw HTML content that can be saved and opened in a browser.
+
+## Tips
+
+- Prototype the core user flow first, then add details. The happy path matters most.
+- Use realistic data. "Acme Corp, 47 users, $12,400 MRR" is more convincing than "Company A, N users, $X MRR".
+- Interactive elements make the difference. A prototype where you can click tabs, filter a list, or fill a form is far more useful than a static mockup.
+- Do not over-prototype. Focus on the screens and interactions that answer the key design questions.
+- If the user asks for changes, regenerate the entire HTML file with the updates. Do not provide code snippets.
diff --git a/product-management/commands/release-notes.md b/product-management/commands/release-notes.md
new file mode 100644
index 0000000..9d1b496
--- /dev/null
+++ b/product-management/commands/release-notes.md
@@ -0,0 +1,75 @@
+---
+description: Generate customer-facing release notes from completed engineering work
+argument-hint: "<version number or list of completed items>"
+---
+
+# Release Notes
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Generate customer-facing release notes from completed work.
+
+## Workflow
+
+### 1. Understand the Release
+
+Ask the user:
+- What version or release is this for?
+- What product or product area?
+- What is the release date?
+- Is there a specific audience? (All customers, enterprise only, beta users)
+- Any previous release notes to match the format of?
+
+### 2. Pull Context from Connected Tools
+
+If **~~project tracker** is connected:
+- Pull all tickets completed since the last release
+- Group by epic or theme for logical organization
+- Identify bug fixes, new features, and improvements
+- Flag any breaking changes or deprecations
+- Pull ticket descriptions for context on each change
+
+If **~~knowledge base** is connected:
+- Search for related PRDs or spec documents
+- Pull documentation updates that correspond to the release
+- Find any migration guides or upgrade instructions
+
+If these tools are not connected, ask the user to paste:
+- List of completed Jira tickets, Linear issues, or GitHub PRs
+- Brief descriptions of each change
+- Any breaking changes or deprecations to flag
+- Epic or theme summaries if available
+
+### 3. Generate Release Notes
+
+Produce customer-facing release notes. See the **release-communication** skill for detailed guidance on writing principles, changelog categorization, and audience adaptation.
+
+- **Headline**: One compelling sentence about the most impactful change in this release
+- **Highlights**: 2-3 most significant changes — the items most customers will care about
+- **New Features**: New capabilities, each described in terms of what the user can now do
+- **Improvements**: Enhancements to existing features — what got better and how
+- **Bug Fixes**: Issues resolved, described specifically enough for affected users to recognize
+- **Breaking Changes**: Anything requiring customer action, with migration guidance (if applicable)
+- **Deprecations**: Features being phased out, with timeline and alternatives (if applicable)
+- **Coming Soon**: Brief preview of what is next — builds anticipation and shows momentum
+
+### 4. Follow Up
+
+After generating the release notes:
+- Offer to create a shorter version for email or social media
+- Offer to create a TL;DR version for Slack
+- Offer to draft a detailed blog post for major features
+- Offer to adjust the tone for a different audience (technical, business, end-user)
+
+## Output Format
+
+Use markdown with clear headers. Lead with user value, not technical implementation details. Write in active voice and address the user directly ("You can now..." not "The ability to... has been added").
+
+## Tips
+
+- Translate engineering language to customer language. "Migrated to Elasticsearch" becomes "Search is now 3x faster."
+- Combine related tickets into single entries. Five tickets about search improvements become one "Search Improvements" section.
+- Skip internal changes with no user-visible impact (refactoring, dependency updates, CI changes).
+- Breaking changes must be called out prominently — do not bury them in the middle of a list.
+- Include links to documentation, guides, or help articles where relevant.
+- The "Coming Soon" section is optional but powerful. It builds excitement and shows the product is actively improving.
diff --git a/product-management/commands/sprint-review.md b/product-management/commands/sprint-review.md
new file mode 100644
index 0000000..5d669c2
--- /dev/null
+++ b/product-management/commands/sprint-review.md
@@ -0,0 +1,78 @@
+---
+description: Generate a sprint review summary with accomplishments, metrics, demos, and next sprint preview
+argument-hint: "<sprint name or number>"
+---
+
+# Sprint Review
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Generate a stakeholder-ready sprint review summary.
+
+## Workflow
+
+### 1. Understand the Sprint
+
+Ask the user:
+- Which sprint? (name or number)
+- Sprint dates (start and end)
+- What was the sprint goal?
+- Which team is this for?
+
+### 2. Pull Context from Connected Tools
+
+If **~~project tracker** is connected:
+- Pull all stories completed this sprint with point values
+- Identify carried-over items and their reasons
+- Calculate velocity: planned vs completed points
+- Pull bug counts: opened, closed, and remaining
+- Identify any scope changes made mid-sprint
+
+If **~~chat** is connected:
+- Search for sprint-related discussions and decisions
+- Identify any blockers discussed in team channels
+- Surface any customer reactions to recently shipped features
+
+If **~~user feedback** is connected:
+- Pull customer feedback related to features shipped this sprint
+- Search for support ticket changes related to completed work
+- Identify any new issues introduced by sprint deliverables
+
+If these tools are not connected, ask the user to paste:
+- List of completed stories with point values
+- Sprint metrics (planned vs completed, velocity, bug count)
+- Blockers encountered and how they were resolved
+- Customer feedback received during the sprint
+
+### 3. Generate the Sprint Summary
+
+Produce a structured sprint review document. See the **sprint-execution** skill for detailed guidance on sprint metrics, demo preparation, and health indicators.
+
+- **Sprint Overview**: Sprint name, dates, team, and goal — was the goal met?
+- **Key Accomplishments**: Top 3-5 completed items with brief descriptions of user value delivered
+- **Metrics Dashboard**: Velocity (planned vs completed), completion rate, bug count, carry-over items
+- **Demo Highlights**: Features worth demonstrating, with a brief description of the user scenario
+- **Blockers and Learnings**: Issues encountered, how they were resolved, and what the team learned
+- **Customer Feedback**: Relevant customer reactions to shipped features or ongoing work
+- **Next Sprint Preview**: What the team plans to work on next, with key items listed
+
+### 4. Follow Up
+
+After generating the summary:
+- Offer to prepare a demo script for the sprint review meeting
+- Offer to generate a TL;DR version for Slack
+- Offer to create talking points for specific accomplishments
+- Offer to draft a retrospective agenda based on the blockers and learnings
+
+## Output Format
+
+Use markdown with clear headers. Include a metrics summary table for easy scanning. Keep the document under 2 pages — sprint reviews should be digestible, not exhaustive.
+
+## Tips
+
+- Lead with what was shipped and the value it delivers, not the process of how it was built.
+- Be honest about what did not get done. Carry-over is normal; hiding it is not.
+- Metrics tell a story. If velocity dropped, explain why. If bugs spiked, explain the root cause.
+- Demo highlights should tell a user story, not walk through a feature list.
+- Customer feedback is the most valuable section for stakeholders. Include direct quotes when possible.
+- The "Next Sprint Preview" builds confidence that the team has a clear plan ahead.
diff --git a/product-management/commands/tldr.md b/product-management/commands/tldr.md
new file mode 100644
index 0000000..beb49af
--- /dev/null
+++ b/product-management/commands/tldr.md
@@ -0,0 +1,64 @@
+---
+description: Create a quick 3-5 bullet summary optimized for Slack, email, or async communication
+argument-hint: "<content to summarize>"
+---
+
+# TL;DR
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../CONNECTORS.md).
+
+Create a 30-second summary optimized for Slack, email, and mobile reading.
+
+## Workflow
+
+### 1. Understand What to Summarize
+
+Ask the user:
+- What content should be summarized? (Paste a document, describe a topic, or reference a previous conversation)
+- Who is the audience? (Team, leadership, stakeholders, customers)
+- What should the reader do after reading this? (Review, approve, discuss, FYI only)
+
+Accept any of:
+- A full document (sprint review, PRD, meeting notes, report)
+- A long Slack thread or email chain
+- A verbal description of what happened
+- Output from another command (sprint review, one-pager, competitive brief)
+
+### 2. Generate the TL;DR
+
+Produce a 3-5 bullet summary. See the **executive-synthesis** skill for detailed guidance on TL;DR writing rules and Slack formatting.
+
+Strict constraints:
+- **3-5 bullets** (never more — if you need more, suggest a one-pager instead)
+- **Under 100 words total**
+- **Each bullet is one clear point** (not a paragraph)
+- **Includes a call-to-action** on a separate line at the end
+
+Writing rules:
+- Start each bullet with the key fact, not context
+- Use numbers over adjectives ("40% faster" not "significantly faster")
+- Active voice ("We shipped" not "Was shipped")
+- Cut qualifiers ("basically", "essentially", "somewhat")
+- One idea per bullet — if it has "and", consider splitting it
+- Bold the most important words for quick scanning
+- Use emoji sparingly as visual markers (one per bullet maximum)
+
+### 3. Follow Up
+
+After generating the TL;DR:
+- Offer to create a longer one-pager using `/one-pager` if the topic needs more depth
+- Offer to adjust the tone for a different audience
+- Offer to create a Slack-formatted version ready to copy-paste
+- Offer to add more context to any specific bullet
+
+## Output Format
+
+Plain text optimized for pasting into Slack or email. Use emoji sparingly for visual scanning. Bold key words. End with a clear call-to-action on its own line.
+
+## Tips
+
+- If you cannot fit the summary in 5 bullets, the source material covers too many topics. Ask which topic to focus on, or suggest a one-pager instead.
+- The call-to-action is not optional. Every summary should tell the reader what to do next, even if it is just "FYI, no action needed."
+- Test on mobile. If the TL;DR requires scrolling on a phone screen, it is too long.
+- Lead with what changed or what matters, not with context. "Search NPS: 3.2 → 4.1" is better than "After the Q3 search initiative, our NPS score improved from 3.2 to 4.1."
+- Match the audience's language. Engineering teams want technical specifics. Executives want business impact. Customers want user value.
diff --git a/product-management/skills/executive-synthesis/SKILL.md b/product-management/skills/executive-synthesis/SKILL.md
new file mode 100644
index 0000000..7eb78a0
--- /dev/null
+++ b/product-management/skills/executive-synthesis/SKILL.md
@@ -0,0 +1,159 @@
+---
+name: executive-synthesis
+description: Write concise executive summaries, one-pagers, and TL;DRs from complex source material. Use when distilling multiple documents into a one-pager, writing a TL;DR for Slack or email, preparing a board pre-read, summarizing a meeting or report, or creating an executive brief.
+---
+
+# Executive Synthesis Skill
+
+You are an expert at distilling complex information into clear, actionable executive communication. You help product managers create one-pagers, TL;DRs, and executive summaries that busy stakeholders can absorb quickly and act on.
+
+## The Pyramid Principle
+
+### Structure for Executive Communication
+Start with the answer, then provide supporting evidence. Executives read top-down and stop when they have enough information.
+
+**Pyramid structure**:
+1. **Governing thought**: The single most important point (1 sentence)
+2. **Key supporting points**: 2-4 points that support the governing thought (1 sentence each)
+3. **Evidence**: Data, examples, and analysis that back up each supporting point
+
+**Example**:
+- Governing thought: "We should invest in AI search for Q2 — it is our highest-impact opportunity based on customer demand and competitive urgency."
+- Supporting point 1: "47 support tickets and 89 community votes for better search in the last quarter"
+- Supporting point 2: "Two direct competitors launched AI search in Q4"
+- Supporting point 3: "Current search-to-click time is 45s, well above the 15s industry benchmark"
+- Evidence: [detailed data behind each point]
+
+### Why Pyramid Works
+- Busy readers get the answer immediately, even if they stop reading after one sentence
+- Supporting readers can go deeper into the evidence they care about
+- The structure forces the writer to clarify their own thinking before writing
+- If you cannot state your governing thought in one sentence, you have not synthesized enough
+
+## One-Pager Framework
+
+### What is a One-Pager
+A one-pager is a single-page document (400-500 words) that synthesizes complex information into an executive-ready summary. It is the written equivalent of "if you only have 2 minutes, here is what you need to know."
+
+### One-Pager Structure
+
+**Title**: Clear and specific. "Q1 Search Initiative Results" not "Product Update"
+
+**TL;DR** (2-3 sentences): The governing thought. If the reader stops here, they should have the essential message.
+
+**Context** (2-3 sentences): Minimum background needed to understand the rest. Do not rehash known history — just enough for a new reader to follow.
+
+**Key Findings** (3-5 bullets): The most important data points or insights, each in one sentence. Quantify wherever possible.
+
+**Recommendation** (1-2 sentences): What you think should happen next, stated clearly and directly.
+
+**Next Steps** (2-3 bullets): Specific actions with owners and timelines. Make it easy to say "yes, go."
+
+### One-Pager Quality Checklist
+- [ ] Under 500 words (strict — every word must earn its place)
+- [ ] Can be read in under 2 minutes
+- [ ] TL;DR captures the full message in 2-3 sentences
+- [ ] All claims are backed by specific data, not vague assertions
+- [ ] Recommendation is clear and actionable
+- [ ] Next steps have owners and timelines
+- [ ] No jargon that the audience would not understand
+- [ ] A new reader can follow without prior context
+
+### Common One-Pager Mistakes
+- **Too long**: If it is more than one page, you have not synthesized enough. Cut ruthlessly.
+- **No recommendation**: A summary without a recommendation is just information. Add your point of view.
+- **Burying the lead**: Do not build up to the conclusion. State it first, then explain.
+- **Vague data**: "Significant increase" is not useful. "40% increase from 15s to 21s average session time" is useful.
+- **Too much context**: Assume the reader knows the background. Three sentences of context maximum.
+- **No "so what"**: Every data point should answer "so what does this mean for us?"
+
+## TL;DR Framework
+
+### What is a Good TL;DR
+A TL;DR is a 3-5 bullet summary that can be consumed in 30 seconds. Optimized for Slack, email, and mobile reading.
+
+### TL;DR Structure
+- **3-5 bullets** (never more — if you need more, you need a one-pager instead)
+- **Under 100 words total**
+- **Each bullet is one clear point** (not a paragraph disguised as a bullet)
+- **Includes a call-to-action**: What should the reader do? (Review, approve, discuss, FYI)
+
+### Writing Rules for TL;DRs
+- **Start each bullet with the key fact**: "Search NPS improved from 3.2 to 4.1" not "After implementing the changes we discussed in the Q3 planning session, the search NPS score has shown improvement, going from 3.2 to 4.1"
+- **Use numbers over adjectives**: "40% faster" not "significantly faster"
+- **Active voice**: "We shipped search filters" not "Search filters were shipped"
+- **Cut qualifiers**: Remove "basically", "essentially", "somewhat", "relatively", "slightly"
+- **One idea per bullet**: If a bullet has "and", consider splitting it
+
+### TL;DR Formatting for Slack
+- Use emoji as visual markers (sparingly): ship for shipping, chart for metrics, warning for risks, check for completions
+- Bold the most important words in each bullet
+- Include the call-to-action on a separate line at the end
+- Keep the whole message visible without scrolling on mobile
+
+**Example**:
+```
+TL;DR: Sprint 42
+
+- Shipped search filters (8 pts) — now live for all users
+- Search NPS: 3.2 → 4.1 since last sprint
+- Redis connection pool issue blocked 2 stories (resolved Friday)
+- Globex Corp: "Filters are game-changing" — first customer feedback
+- Next sprint: AI-powered search suggestions (12 pts committed)
+
+→ Review the full sprint summary and share feedback by Friday
+```
+
+## Audience Adaptation
+
+### Writing for C-Suite
+- Lead with business impact (revenue, cost, risk), not product details
+- Use financial language: ROI, CAC, LTV, market share, competitive position
+- Keep it under 300 words. Executives scan, they do not read.
+- Include a clear decision or action item. Do not present information without a recommendation.
+- Anticipate the "why should I care?" question for every point
+
+### Writing for Board Members
+- Provide strategic context: market position, competitive dynamics, industry trends
+- Use comparative language: "up from X", "versus target of Y", "compared to competitor Z"
+- Include forward-looking statements: what you expect to happen and why
+- Flag risks proactively — boards appreciate candor and preparedness
+- Quarterly cadence: focus on trends, not individual data points
+
+### Writing for Cross-Functional Leaders
+- Translate product metrics into their language (engineering: throughput, velocity; marketing: pipeline, conversion; sales: win rate, deal size)
+- Highlight cross-functional dependencies and needs
+- Be explicit about what you need from them
+- Include enough detail for them to brief their own teams
+
+### Writing for Your Own Team
+- Can be more detailed and technical
+- Include the "how" and "what is next" in addition to the "what"
+- Celebrate wins — team morale matters
+- Be candid about challenges — trust builds on transparency
+
+## Synthesis Process
+
+### Step-by-Step Synthesis
+When you have multiple sources to synthesize:
+
+1. **Collect**: Gather all source materials (documents, data, notes, feedback)
+2. **Extract**: Pull out the key facts, data points, and insights from each source
+3. **Cluster**: Group related points together. What themes emerge?
+4. **Prioritize**: Rank the themes by importance to your audience. What matters most to them?
+5. **Formulate**: Write your governing thought — the single most important takeaway
+6. **Draft**: Write the one-pager or TL;DR using the pyramid structure
+7. **Cut**: Remove everything that does not directly support the governing thought. Be ruthless.
+8. **Test**: Can someone who did not read the sources understand your summary? If not, revise.
+
+### Dealing with Conflicting Information
+When sources disagree:
+- State the discrepancy explicitly ("Support data shows X, but usage data shows Y")
+- Explain the likely reason for the disagreement
+- State which source you find more reliable and why
+- Recommend how to resolve the ambiguity (more research, specific analysis, customer interviews)
+
+### When to Synthesize vs. When to Present Raw Data
+- **Synthesize**: When the audience needs to make a decision or understand the big picture
+- **Present raw data**: When the audience is doing their own analysis or when the data speaks for itself
+- **Both**: Include the synthesis as the main document, with raw data as an appendix or link
diff --git a/product-management/skills/feature-spec/SKILL.md b/product-management/skills/feature-spec/SKILL.md
index d9efe2c..0d39d11 100644
--- a/product-management/skills/feature-spec/SKILL.md
+++ b/product-management/skills/feature-spec/SKILL.md
@@ -157,6 +157,36 @@ Example:
 - Each criterion should be independently testable
 - Avoid ambiguous words: "fast", "user-friendly", "intuitive" — define what these mean concretely
 
+## Idea Structuring
+
+### From Raw Idea to PRD-Ready Concept
+Before writing a full PRD, raw ideas need to be structured. This is the bridge between "someone said we should do X" and a formal spec. Use this when ideas come from Slack threads, customer conversations, brainstorms, or stakeholder requests.
+
+### Idea Structuring Process
+1. **Define the problem**: What user problem does this idea address? If you cannot state the problem clearly, the idea is not ready for a spec.
+2. **Identify the customer signal**: Where did this idea come from? Customer feedback, support tickets, Slack discussion, competitive pressure, internal observation? Stronger signals (many customers, recurring theme) deserve more investment.
+3. **Explore solution options**: Generate 2-3 approaches, not just the first idea. Consider:
+   - Option A: Simplest version that solves the core problem
+   - Option B: More comprehensive approach with broader impact
+   - Option C: Different angle entirely (reframe the problem)
+4. **List assumptions**: What must be true for each option to work? Customer behavior assumptions, technical feasibility assumptions, market assumptions.
+5. **Identify what you do not know**: What would you need to learn before committing? Can you validate quickly (survey, prototype, data analysis)?
+6. **Recommend next step**: Is this ready for a full PRD? Or does it need validation first (customer interviews, prototype, experiment)?
+
+### When an Idea is Ready for a PRD
+- The problem is clearly defined and backed by evidence
+- At least one viable solution approach has been identified
+- Critical assumptions have been validated (or a validation plan exists)
+- The idea has a plausible path to measurable impact
+- A PM is willing to own the spec and drive it forward
+
+### When an Idea Needs More Work
+- The problem is vague ("users want it to be better")
+- No customer evidence beyond one person's opinion
+- The solution is prescribed without understanding the problem ("build a dashboard")
+- Critical assumptions are untested and high-risk
+- Nobody can articulate what success looks like
+
 ## Scope Management
 
 ### Recognizing Scope Creep
diff --git a/product-management/skills/html-prototyping/SKILL.md b/product-management/skills/html-prototyping/SKILL.md
new file mode 100644
index 0000000..8391894
--- /dev/null
+++ b/product-management/skills/html-prototyping/SKILL.md
@@ -0,0 +1,273 @@
+---
+name: html-prototyping
+description: Generate interactive HTML prototypes from PRDs or feature descriptions with embedded CSS and JavaScript. Use when creating a clickable prototype, visualizing a feature concept, demonstrating a UI flow, or building a proof-of-concept for stakeholder feedback.
+---
+
+# HTML Prototyping Skill
+
+You are an expert UI/UX engineer who creates interactive HTML prototypes from product requirements. You produce standalone HTML files with embedded CSS and JavaScript that can be opened directly in a browser — no build tools, no dependencies, no server required.
+
+## Core Principles
+
+### Standalone HTML Files
+Every prototype must be a single, self-contained HTML file:
+
+- All CSS embedded in `<style>` tags (no external stylesheets)
+- All JavaScript embedded in `<script>` tags (no external dependencies)
+- No CDN links, no frameworks, no build steps
+- Works when double-clicked to open in any modern browser
+- No server required — purely client-side
+
+### Why HTML Prototypes
+- **Zero friction**: Anyone can open an HTML file. No setup, no accounts, no tools.
+- **Interactive**: Unlike screenshots or mockups, users can click, type, and explore.
+- **Shareable**: Attach to an email, drop in Slack, or commit to a repo.
+- **Fast to iterate**: Quick to modify and regenerate.
+- **Honest fidelity**: Looks good enough to evaluate UX, rough enough that stakeholders know it is not production.
+
+## Design System Defaults
+
+### Color Palette
+When no design system is specified, use a professional, neutral palette:
+
+**Primary colors**:
+- Primary: `#4F46E5` (indigo-600) — buttons, links, active states
+- Primary hover: `#4338CA` (indigo-700)
+- Primary light: `#EEF2FF` (indigo-50) — backgrounds, highlights
+
+**Neutral colors**:
+- Text primary: `#111827` (gray-900)
+- Text secondary: `#6B7280` (gray-500)
+- Text muted: `#9CA3AF` (gray-400)
+- Border: `#E5E7EB` (gray-200)
+- Background: `#F9FAFB` (gray-50)
+- Surface: `#FFFFFF` (white)
+
+**Semantic colors**:
+- Success: `#059669` (emerald-600)
+- Warning: `#D97706` (amber-600)
+- Error: `#DC2626` (red-600)
+- Info: `#2563EB` (blue-600)
+
+### Typography
+Use system fonts for maximum compatibility:
+
+```css
+font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
+```
+
+**Type scale**:
+- Page title: 24px, font-weight 700
+- Section header: 18px, font-weight 600
+- Body: 14px, font-weight 400, line-height 1.5
+- Small/caption: 12px, font-weight 400
+- Label: 12px, font-weight 500, text-transform uppercase, letter-spacing 0.05em
+
+### Spacing System
+Use a consistent 4px base unit:
+
+- `4px` — tight spacing (between related elements)
+- `8px` — default spacing (between form elements)
+- `12px` — comfortable spacing (padding inside components)
+- `16px` — section padding (cards, panels)
+- `24px` — section gaps (between content blocks)
+- `32px` — major section separation
+- `48px` — page-level padding
+
+### Component Defaults
+
+**Buttons**:
+```css
+padding: 8px 16px;
+border-radius: 6px;
+font-size: 14px;
+font-weight: 500;
+cursor: pointer;
+transition: all 0.15s ease;
+```
+
+**Cards**:
+```css
+background: white;
+border: 1px solid #E5E7EB;
+border-radius: 8px;
+padding: 16px;
+box-shadow: 0 1px 2px rgba(0, 0, 0, 0.05);
+```
+
+**Inputs**:
+```css
+padding: 8px 12px;
+border: 1px solid #D1D5DB;
+border-radius: 6px;
+font-size: 14px;
+width: 100%;
+outline: none;
+transition: border-color 0.15s ease;
+```
+
+**Tables**:
+```css
+width: 100%;
+border-collapse: collapse;
+font-size: 14px;
+/* Rows */
+border-bottom: 1px solid #E5E7EB;
+padding: 12px 16px;
+/* Header */
+background: #F9FAFB;
+font-weight: 600;
+text-align: left;
+```
+
+## Layout Patterns
+
+### Page Layouts
+
+**Sidebar + Content** (most common for dashboards and admin panels):
+```
+┌──────┬──────────────────────────┐
+│      │                          │
+│ Nav  │      Main Content        │
+│      │                          │
+│      │                          │
+└──────┴──────────────────────────┘
+```
+- Sidebar: 240px fixed width
+- Content: flexible, fills remaining space
+- Use CSS flexbox: `display: flex;`
+
+**Top Nav + Content** (marketing pages, simpler apps):
+```
+┌─────────────────────────────────┐
+│           Navigation            │
+├─────────────────────────────────┤
+│                                 │
+│          Main Content           │
+│                                 │
+└─────────────────────────────────┘
+```
+
+**Dashboard Grid** (metrics, overview pages):
+```
+┌──────┬──────┬──────┬──────┐
+│ Stat │ Stat │ Stat │ Stat │
+├──────┴──────┼──────┴──────┤
+│   Chart     │    Table    │
+│             │             │
+└─────────────┴─────────────┘
+```
+- Use CSS Grid: `display: grid; grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));`
+
+### Responsive Considerations
+- Use `max-width: 1200px; margin: 0 auto;` for content containers
+- Use flexbox `flex-wrap: wrap` for card grids
+- Use `min-width` in grid to prevent columns from getting too narrow
+- Test at 1440px (desktop), 1024px (tablet), and 375px (mobile)
+
+## Interactive Patterns
+
+### Common Interactions to Implement
+
+**Tab switching**:
+```javascript
+// Show/hide content panels based on tab selection
+document.querySelectorAll('.tab').forEach(tab => {
+  tab.addEventListener('click', () => {
+    // Remove active from all tabs and panels
+    // Add active to clicked tab and corresponding panel
+  });
+});
+```
+
+**Filter and search**:
+```javascript
+// Filter a list based on input value
+input.addEventListener('input', (e) => {
+  const query = e.target.value.toLowerCase();
+  items.forEach(item => {
+    item.style.display = item.textContent.toLowerCase().includes(query)
+      ? '' : 'none';
+  });
+});
+```
+
+**Modal dialogs**:
+```javascript
+// Show modal on button click, close on backdrop or X
+openBtn.addEventListener('click', () => modal.classList.add('active'));
+closeBtn.addEventListener('click', () => modal.classList.remove('active'));
+```
+
+**Dropdown menus**: Use `<details>` and `<summary>` elements for zero-JS dropdowns, or JavaScript for custom positioning.
+
+**Form validation**: Show inline error messages on blur, highlight invalid fields with border color change.
+
+**Toast notifications**: Fixed-position elements that auto-dismiss after 3-5 seconds.
+
+### State Management in Prototypes
+Keep state simple — use DOM manipulation and CSS classes, not complex state management:
+
+- Use `classList.toggle('active')` for show/hide
+- Use `data-*` attributes to store component state
+- Use CSS `:checked` pseudo-class for toggles
+- Keep all state in the DOM — no need for a state library in a prototype
+
+### Realistic Placeholder Data
+Use realistic data that tells a story:
+
+- **Names**: Use diverse, realistic names (not "User 1", "User 2")
+- **Numbers**: Use plausible business metrics (not round numbers like 1000, 2000)
+- **Dates**: Use recent, relative dates ("2 hours ago", "Yesterday")
+- **Text**: Use realistic content length (not lorem ipsum for key text)
+- **Status values**: Use a mix of states (not all "Active" or all "Pending")
+
+## Prototype Scope Guidelines
+
+### What to Prototype
+- The core user flow (happy path)
+- Key decision points and branching
+- Data-heavy screens (tables, dashboards, forms)
+- Novel interactions that are hard to describe in a spec
+
+### What NOT to Prototype
+- Authentication flows (login, signup) — unless that IS the feature
+- Settings pages — unless settings are the feature
+- Error pages — mention them in the spec instead
+- Loading states — unless async behavior is the key UX question
+- Mobile layouts — unless mobile is the primary use case
+
+### Fidelity Levels
+
+**Low fidelity** (wireframe-like):
+- Grayscale palette
+- Placeholder boxes for images
+- Simple labels instead of real content
+- Focus: layout, flow, information hierarchy
+
+**Medium fidelity** (recommended for most prototypes):
+- Color palette applied
+- Real typography
+- Realistic placeholder data
+- Interactive elements (clicks, tabs, filters)
+- Focus: user experience, interaction patterns
+
+**High fidelity** (pixel-perfect):
+- Exact colors, fonts, spacing from design system
+- Animations and transitions
+- Complete realistic data
+- Edge cases handled
+- Focus: visual validation, stakeholder sign-off
+
+Default to medium fidelity unless the user requests otherwise.
+
+## Accessibility Basics
+
+Even in prototypes, follow basic accessibility:
+
+- Use semantic HTML (`<nav>`, `<main>`, `<button>`, `<table>`) instead of all `<div>`
+- Add `alt` text to images
+- Ensure sufficient color contrast (4.5:1 ratio for text)
+- Make interactive elements focusable and keyboard-accessible
+- Use `<label>` elements properly for form inputs
+- Do not rely on color alone to convey information (add icons or text)
diff --git a/product-management/skills/meeting-preparation/SKILL.md b/product-management/skills/meeting-preparation/SKILL.md
new file mode 100644
index 0000000..f8fa5ea
--- /dev/null
+++ b/product-management/skills/meeting-preparation/SKILL.md
@@ -0,0 +1,197 @@
+---
+name: meeting-preparation
+description: Prepare for customer meetings, QBRs, and stakeholder reviews with structured talking points, risk assessment, and account context. Use when preparing for a customer call, QBR, executive review, sales call, or any meeting where you need organized context and talking points.
+---
+
+# Meeting Preparation Skill
+
+You are an expert at helping product managers prepare for meetings. You help compile account context, build talking points, identify risks and opportunities, and structure meeting agendas so PMs walk in confident and prepared.
+
+## Account Review Methodology
+
+### Building Account Context
+Before any customer meeting, gather context across these dimensions:
+
+**Relationship History**:
+- When did this customer start using the product?
+- What was their original use case or buying motivation?
+- Key milestones in the relationship (expansion, escalation, renewal, champion change)
+- Who are the key stakeholders and what does each one care about?
+- Has there been any executive sponsor change recently?
+
+**Product Usage**:
+- Which features are they using heavily? Which are they ignoring?
+- Any changes in usage patterns (increase, decrease, new feature adoption)
+- Are they on the latest version? Using any deprecated features?
+- How does their usage compare to similar accounts?
+
+**Health Indicators**:
+- Account health score and recent trend (improving, stable, declining)
+- NPS score or most recent satisfaction data
+- Support ticket volume and severity — any open critical issues?
+- Time to resolution on their recent support tickets
+- Contract details: renewal date, contract value, expansion potential
+
+**Recent Interactions**:
+- Last meeting notes and action items — were they completed?
+- Recent support conversations and their outcomes
+- Any recent product feedback or feature requests
+- Sales team notes or CRM updates
+
+### Account Health Assessment
+Rate the account across key dimensions:
+
+| Dimension | Healthy | At Risk | Critical |
+|-----------|---------|---------|----------|
+| Usage | Stable or growing | Declining | Minimal or stopped |
+| Satisfaction | NPS 8+ or positive sentiment | NPS 6-7 or mixed | NPS 0-5 or escalation |
+| Support | Low ticket volume, fast resolution | Increasing tickets or slow resolution | Open critical issues or escalation |
+| Relationship | Regular engagement, strong champion | Infrequent contact or champion at risk | No champion, executive escalation |
+| Commercial | Expansion potential, on-time renewal | Renewal at risk, budget concerns | Active churn discussion |
+
+## Talking Point Frameworks
+
+### Structuring Talking Points
+For each meeting, prepare three types of talking points:
+
+**Proactive points** (what you want to communicate):
+- Product updates relevant to this customer
+- Roadmap items that address their known needs
+- Success metrics or wins to highlight
+- Strategic direction they should know about
+
+**Reactive points** (what they will likely ask about):
+- Status of their open feature requests
+- Progress on known issues or bugs
+- Competitive questions (why did competitor X launch Y?)
+- Timeline or pricing questions
+
+**Discovery questions** (what you want to learn):
+- How are they using the product today versus when they started?
+- What are their biggest pain points right now?
+- What is changing in their business that might affect their needs?
+- Who else in their organization could benefit from the product?
+- What would make them a reference customer or case study?
+
+### The PREP Framework for Talking Points
+For important points you need to make:
+
+- **P**oint: State the key message clearly (1 sentence)
+- **R**eason: Explain why this matters to them specifically (1-2 sentences)
+- **E**xample: Provide a concrete example or data point (1-2 sentences)
+- **P**oint: Restate the key message (1 sentence)
+
+### Handling Difficult Topics
+Some talking points address sensitive areas:
+
+**Price increases**: Lead with value delivered, show ROI, explain what is improving, offer to discuss options
+**Feature delays**: Acknowledge the delay, explain why, share the new timeline, offer alternatives
+**Bug or outage**: Own it, explain root cause and fix, share what you are doing to prevent recurrence
+**Competitor features**: Acknowledge awareness, explain your strategic approach, highlight your strengths
+**Churn signals**: Address directly, ask what would need to change, propose a specific action plan
+
+## Meeting Type Playbooks
+
+### QBR (Quarterly Business Review)
+
+**Purpose**: Review the quarter, demonstrate value, align on priorities for next quarter
+
+**Typical agenda** (60 min):
+1. Relationship check-in (5 min)
+2. Their business update (10 min) — let them share first
+3. Usage and value review (15 min) — metrics, adoption, ROI
+4. Support review (5 min) — ticket trends, resolution times
+5. Product roadmap preview (10 min) — what is coming that matters to them
+6. Success planning (10 min) — goals for next quarter
+7. Open discussion (5 min)
+
+**QBR preparation checklist**:
+- [ ] Usage data pulled and visualized (trends, not just snapshots)
+- [ ] ROI calculation prepared (time saved, revenue impact, cost reduction)
+- [ ] Support ticket summary with resolution times
+- [ ] Feature requests status update (shipped, planned, under review, declined)
+- [ ] Roadmap items relevant to this customer identified
+- [ ] Previous QBR action items reviewed (what was done, what was not)
+- [ ] Attendee list confirmed with roles and known priorities
+- [ ] Agenda sent in advance (at least 2 business days)
+
+### Check-in Call
+
+**Purpose**: Regular touchpoint to maintain relationship and catch issues early
+
+**Typical agenda** (30 min):
+1. How are things going? (5 min) — open-ended, let them lead
+2. Product updates (10 min) — recent releases relevant to them
+3. Open items (10 min) — feature requests, support issues
+4. Next steps (5 min) — action items for both sides
+
+### Executive Briefing
+
+**Purpose**: Align with senior stakeholders on strategic direction
+
+**Preparation**:
+- Keep it high-level. Executives want strategy and outcomes, not feature details.
+- Lead with business impact. Translate product metrics into business language.
+- Be ready to answer "so what?" for every point you make.
+- Have a clear ask — what do you want from them? (Budget, prioritization, introduction, decision)
+
+### Escalation Meeting
+
+**Purpose**: Address a critical issue or relationship risk
+
+**Preparation**:
+- Acknowledge the problem clearly and specifically
+- Prepare a root cause analysis
+- Have a concrete remediation plan with dates
+- Identify what you need from them (information, access, patience, decision)
+- Set clear success criteria — how will both sides know the issue is resolved?
+
+## Risk and Opportunity Identification
+
+### Pre-Meeting Risk Assessment
+Before every customer meeting, identify:
+
+**Risks to address**:
+- Open critical support issues
+- Missed commitments from previous meetings
+- Usage decline or adoption stagnation
+- Upcoming renewal with unresolved concerns
+- Competitive evaluation in progress
+- Key stakeholder departure or role change
+- Budget pressure or organizational change
+
+**Opportunities to explore**:
+- Expansion to new teams or use cases
+- Upgrade potential (plan, features, seats)
+- Case study or reference potential
+- Product advisory board participation
+- Introduction to other stakeholders
+- Co-development or beta program participation
+
+### Opportunity Qualification (BANT)
+When you identify an expansion opportunity:
+
+- **Budget**: Do they have budget for additional investment?
+- **Authority**: Are you talking to the person who can approve it?
+- **Need**: Is there a real business need driving this?
+- **Timeline**: When would they need this by?
+
+## Post-Meeting Best Practices
+
+### Meeting Notes Structure
+After every meeting, document:
+
+- **Date, attendees, meeting type**
+- **Key takeaways**: 3-5 bullet summary of the most important points
+- **Action items**: Who, what, by when — for both sides
+- **Sentiment**: How did the customer seem? (enthusiastic, neutral, frustrated, concerned)
+- **Risks identified**: Any new risks or changes in existing risk level
+- **Opportunities identified**: Any new expansion or deepening opportunities
+- **Follow-up needed**: Emails to send, internal escalations, materials to share
+
+### Action Item Tracking
+- Send action items within 24 hours of the meeting
+- Assign clear owners to every item
+- Set specific due dates (not "soon" or "ASAP")
+- Review action items at the start of the next meeting
+- Escalate items that are overdue or blocked
diff --git a/product-management/skills/release-communication/SKILL.md b/product-management/skills/release-communication/SKILL.md
new file mode 100644
index 0000000..39214f3
--- /dev/null
+++ b/product-management/skills/release-communication/SKILL.md
@@ -0,0 +1,225 @@
+---
+name: release-communication
+description: Write customer-facing release notes, changelogs, and product announcements. Use when publishing release notes, writing a changelog, announcing a new feature, communicating a deprecation, or preparing a product update for customers.
+---
+
+# Release Communication Skill
+
+You are an expert at writing customer-facing product communications. You help product managers translate completed engineering work into clear, compelling release notes and product announcements that customers actually want to read.
+
+## Release Notes Structure
+
+### Standard Release Notes Format
+A well-structured release note includes:
+
+- **Headline**: One sentence that captures the most important change. Lead with user value, not technical detail. ("Search is now 3x faster" not "Migrated search indexer to Elasticsearch")
+- **Highlights**: 2-3 most significant changes with brief descriptions. These should be the items most customers will care about.
+- **New Features**: Capabilities that did not exist before. Describe what users can now do, not how it was built.
+- **Improvements**: Enhancements to existing features. Describe what got better and how it affects the user experience.
+- **Bug Fixes**: Issues that were resolved. Be specific about what was broken and that it is now fixed, but do not over-explain root causes.
+- **Breaking Changes**: Anything that requires customer action. These MUST be called out prominently with migration guidance.
+- **Deprecations**: Features or APIs being phased out, with timeline and alternatives.
+- **Coming Soon**: Brief preview of what is next. Builds anticipation and shows momentum.
+
+### Writing Principles for Release Notes
+
+**Lead with user value, not technical implementation**:
+- Good: "You can now export reports as PDF with one click"
+- Bad: "Added PDF generation library and exposed export endpoint"
+
+**Be specific about what changed**:
+- Good: "Dashboard loading time reduced from 4 seconds to under 1 second"
+- Bad: "Improved performance"
+
+**Use active voice and plain language**:
+- Good: "Search now finds results across all your workspaces"
+- Bad: "Cross-workspace search functionality has been implemented"
+
+**Address the user directly**:
+- Good: "You can now set custom notification schedules"
+- Bad: "Custom notification scheduling capability has been added to the platform"
+
+**Group related changes**:
+- Group by theme or user need, not by engineering team or component
+- "Collaboration improvements" is better than "Backend team changes"
+
+## Changelog Best Practices
+
+### Categorization
+Use consistent categories across every release:
+
+- **Added**: New features or capabilities
+- **Changed**: Modifications to existing features
+- **Fixed**: Bug fixes
+- **Deprecated**: Features marked for removal
+- **Removed**: Features that have been removed
+- **Security**: Security-related changes
+
+This follows the [Keep a Changelog](https://keepachangelog.com) convention, which most developers and technical users recognize.
+
+### Version Numbering
+Follow Semantic Versioning (SemVer) conventions:
+
+- **Major version** (X.0.0): Breaking changes that require customer action
+- **Minor version** (x.Y.0): New features that are backward-compatible
+- **Patch version** (x.y.Z): Bug fixes and small improvements
+
+Include the release date in ISO format (YYYY-MM-DD) alongside the version number.
+
+### Changelog Entry Quality
+
+**Good entry**:
+> **Added**: Team admins can now configure SSO using SAML 2.0. Supports Okta, Azure AD, and OneLogin. See the [SSO setup guide](link) to get started.
+
+**Bad entry**:
+> Added SSO
+
+The good entry tells the user: what was added, what providers are supported, and how to use it. The bad entry is too vague to be useful.
+
+## Translating Jira Tickets to Release Notes
+
+### The Translation Process
+Engineering tickets are written for developers. Release notes are written for customers. Translation is the key skill.
+
+**From Jira ticket**:
+> ACME-342: Implement search filters using faceted search with Elasticsearch aggregations. Add filter UI components for date range, content type, and author. Update search API to accept filter parameters.
+
+**To release note**:
+> **Search Filters**: You can now filter search results by date, content type, and author. Narrow down results quickly instead of scrolling through everything.
+
+### Translation Guidelines
+- **Strip internal terminology**: Remove ticket numbers, component names, and technical references
+- **Focus on the user outcome**: What can the user now DO that they could not before?
+- **Add context**: Why does this matter? How should the user use it?
+- **Include links**: Link to documentation, guides, or blog posts for features that need explanation
+- **Combine related tickets**: Multiple tickets often represent one user-facing change. Combine them into a single release note entry.
+
+### What NOT to Include
+- Internal refactoring with no user-visible change
+- Dependency updates (unless they fix a user-facing issue)
+- CI/CD pipeline changes
+- Internal tool improvements
+- Changes to internal dashboards or admin panels (unless customer-facing)
+
+## Communicating Breaking Changes
+
+### Breaking Change Communication Checklist
+Breaking changes require extra care:
+
+1. **Announce early**: Communicate at least 2 weeks before the change. For major changes, 30-90 days.
+2. **Explain why**: Help customers understand the reason for the change (security, performance, simplification)
+3. **Provide migration path**: Step-by-step instructions for what customers need to do
+4. **Offer help**: Provide support resources, migration scripts, or office hours
+5. **Set deadlines**: Be clear about when the old behavior will stop working
+6. **Follow up**: Send reminders as the deadline approaches (30 days, 7 days, 1 day)
+
+### Breaking Change Template
+```
+## Breaking Change: [Name of Change]
+
+**What is changing**: [Clear description of what will be different]
+**When**: [Effective date]
+**Why**: [Brief explanation of why this change is necessary]
+
+**What you need to do**:
+1. [Step-by-step migration instructions]
+2. [Step-by-step migration instructions]
+
+**Timeline**:
+- [Date]: Announcement (today)
+- [Date]: New behavior available (opt-in)
+- [Date]: Old behavior deprecated (warning)
+- [Date]: Old behavior removed
+
+**Need help?** [Contact support / join migration office hours / see guide]
+```
+
+## Feature Announcement Best Practices
+
+### Launch Tiers
+Not every feature deserves the same level of announcement:
+
+**Tier 1 — Major launch** (new product, major feature, platform change):
+- Blog post with detailed walkthrough
+- Email to all customers
+- In-app announcement or banner
+- Social media posts
+- Press release (if relevant)
+- Customer webinar or demo session
+
+**Tier 2 — Significant feature** (meaningful new capability):
+- In-app notification
+- Mention in release notes
+- Short blog post or section in product update email
+- Social media mention
+
+**Tier 3 — Improvement** (enhancement, quality of life fix):
+- Release notes entry
+- Changelog update
+- No separate announcement
+
+**Tier 4 — Maintenance** (bug fix, performance, internal):
+- Changelog entry only
+
+### Feature Announcement Structure
+For Tier 1 and Tier 2 features:
+
+1. **Hook**: What user problem does this solve? Start with empathy.
+2. **Solution**: What did you build? Show it in action (screenshots, GIFs, video).
+3. **Benefits**: What is better now? Be specific with numbers when possible.
+4. **How to use it**: Quick start instructions or link to documentation.
+5. **What is next**: What comes after this? Build momentum.
+
+## Deprecation Communication
+
+### Deprecation Lifecycle
+1. **Announce deprecation**: Feature is marked as deprecated. Still works, but no longer receives updates.
+2. **Migration period**: Provide alternatives and migration guidance. Help customers move.
+3. **End-of-life warning**: Final reminder before removal. Escalate communication.
+4. **Removal**: Feature is removed. Support migration issues.
+
+### Deprecation Notice Template
+```
+## Deprecation Notice: [Feature Name]
+
+**Status**: Deprecated — will be removed on [date]
+**Replacement**: [Alternative feature or approach]
+
+**Why**: [Brief explanation — security, performance, simplification, low usage]
+
+**Migration guide**:
+1. [Step-by-step instructions]
+
+**Timeline**:
+- Today: Feature deprecated (still works, no longer updated)
+- [Date]: Migration support available
+- [Date]: Final warning
+- [Date]: Feature removed
+```
+
+## Audience Adaptation
+
+### Writing for Different Audiences
+
+**Technical users (developers, engineers)**:
+- Include API changes, endpoint modifications, SDK updates
+- Use technical terminology they understand
+- Link to API docs and migration guides
+- Mention breaking changes prominently
+
+**Business users (managers, executives)**:
+- Lead with business impact and workflow improvements
+- Use plain language, avoid jargon
+- Include screenshots showing the new experience
+- Focus on time saved, efficiency gained, problems solved
+
+**End users (daily product users)**:
+- Keep it simple and visual
+- Focus on what they can now do differently
+- Include quick tips for getting started
+- Use in-app announcements with contextual guidance
+
+**Mixed audience** (most release notes):
+- Lead with user value (works for everyone)
+- Include a technical details section at the bottom for those who want depth
+- Use progressive disclosure — summary first, details available for those who want them
diff --git a/product-management/skills/roadmap-management/SKILL.md b/product-management/skills/roadmap-management/SKILL.md
index 35817ef..9686c2e 100644
--- a/product-management/skills/roadmap-management/SKILL.md
+++ b/product-management/skills/roadmap-management/SKILL.md
@@ -143,6 +143,36 @@ Adjust ratios based on team context:
 - When adding to the roadmap, always ask: "What comes off?"
 - Better to commit to fewer things and deliver reliably than to overcommit and disappoint
 
+## Decision Memos
+
+### When to Write a Decision Memo
+Write a decision memo when the team faces a strategic choice with meaningful trade-offs — which initiative to prioritize, build vs buy, which approach to take. A decision memo structures the conversation and creates a record of the reasoning.
+
+### Decision Memo Structure
+Present 2-3 options with a clear recommendation:
+
+**Context** (2-3 sentences): What decision needs to be made and why now?
+
+**Options** — for each option (2-3 maximum):
+- **Description**: What does this option involve? (2-3 sentences)
+- **Evidence for**: Customer demand data, strategic alignment, competitive pressure
+- **Evidence against**: Risks, costs, opportunity cost, technical concerns
+- **Resource requirements**: Team size, duration, dependencies
+- **Expected impact**: Quantified where possible (revenue, adoption, retention)
+
+**Recommendation**: State clearly which option you recommend and why. The recommendation should follow logically from the evidence.
+
+**Trade-offs acknowledged**: What are you giving up by choosing the recommended option? Showing you have considered the downsides builds credibility.
+
+**Next steps**: If approved, what happens next? Who does what by when?
+
+### Decision Memo Tips
+- Keep it under 2 pages. If you need more space, the decision may need to be broken down.
+- Lead with the recommendation. Busy stakeholders want your answer before the analysis.
+- Be honest about uncertainty. "We believe X based on Y evidence, but Z is unclear" is more credible than false confidence.
+- Include a "reversibility" assessment. One-way doors (hard to undo) deserve more deliberation than two-way doors (easy to reverse).
+- Present genuinely different options, not straw men. If one option is obviously bad, it should not be in the memo.
+
 ## Communicating Roadmap Changes
 
 ### When the Roadmap Changes
diff --git a/product-management/skills/sprint-execution/SKILL.md b/product-management/skills/sprint-execution/SKILL.md
new file mode 100644
index 0000000..de76970
--- /dev/null
+++ b/product-management/skills/sprint-execution/SKILL.md
@@ -0,0 +1,189 @@
+---
+name: sprint-execution
+description: Run sprint reviews, track velocity, prepare demos, interpret burndown charts, and facilitate retrospectives. Use when running a sprint review, preparing a sprint summary, analyzing sprint metrics, facilitating a retrospective, or communicating sprint progress to stakeholders.
+---
+
+# Sprint Execution Skill
+
+You are an expert at sprint execution, review, and continuous improvement for product teams. You help product managers run effective sprint ceremonies, communicate progress clearly, and use sprint data to improve team performance.
+
+## Sprint Review Structure
+
+### Purpose
+The sprint review is a working session where the team demonstrates what was built and gets feedback from stakeholders. It is NOT a status meeting. The goal is to inspect the increment and adapt the backlog based on feedback.
+
+### Sprint Review Agenda
+1. **Sprint Goal Recap** (2 min): Remind everyone what the team set out to accomplish this sprint
+2. **Key Accomplishments** (10 min): Demonstrate completed work — live demos preferred over slide decks
+3. **Metrics Dashboard** (5 min): Show sprint-level metrics (velocity, completion rate, bug count)
+4. **Blockers and Learnings** (5 min): What got in the way, what the team learned
+5. **Customer Feedback** (5 min): Any relevant customer reactions to recent releases
+6. **Next Sprint Preview** (5 min): What the team plans to work on next
+7. **Q&A and Feedback** (10 min): Stakeholder questions and input
+
+### Sprint Summary Document
+A written sprint summary should cover:
+
+- **TL;DR**: 2-3 sentence summary of the sprint's outcome
+- **Sprint Goal**: What was the goal and was it met (fully, partially, or missed)
+- **Completed Work**: List of stories/tasks completed with point values
+- **Carried Over**: Items that did not complete, with brief explanation
+- **Metrics**: Velocity, planned vs completed, bug count, quality indicators
+- **Demo Highlights**: Key features to showcase, with screenshots or links
+- **Blockers**: Issues encountered and how they were resolved (or not)
+- **Customer Signal**: Relevant customer feedback received during the sprint
+- **Next Sprint**: Preview of planned work
+
+## Sprint Metrics
+
+### Velocity
+Velocity measures the amount of work completed per sprint, typically in story points.
+
+**How to use velocity**:
+- Track as a 3-5 sprint rolling average, not individual sprint values
+- Use for capacity planning, not performance evaluation
+- Velocity naturally varies sprint-to-sprint by 15-30%. This is normal.
+- Velocity is only meaningful within a single team — never compare velocity across teams
+
+**Velocity anti-patterns**:
+- Using velocity as a performance metric (incentivizes point inflation)
+- Comparing velocity between teams (different teams estimate differently)
+- Expecting velocity to increase continuously (teams reach a natural plateau)
+- Reacting to single-sprint velocity drops (look at the trend, not the data point)
+
+### Planned vs Completed
+Track the ratio of planned story points to completed story points each sprint.
+
+- **90-100% completion**: Team is estimating well and committing appropriately
+- **70-90% completion**: Normal range. Some variation is expected.
+- **Below 70%**: Pattern suggests over-commitment, poor estimation, or external disruptions
+- **Consistently 100%+**: Team may be under-committing or sandbagging estimates
+
+### Sprint Burndown
+
+**How to read a burndown chart**:
+- **Ideal**: Smooth downward line from total points to zero
+- **Plateau then cliff**: Work is being completed in big batches, not continuously. May indicate large stories that need breaking down.
+- **Flat then drops off**: Late starts or blocked work. Investigate what caused the delay.
+- **Scope increase (line goes up)**: Work was added mid-sprint. Track how often this happens and why.
+- **Ends above zero**: Sprint goal not fully met. Understand what happened before next planning.
+
+**Burndown vs burnup**:
+- Burndown shows remaining work (goes down over time)
+- Burnup shows completed work AND total scope (both go up). Burnup makes scope changes visible.
+- Use burnup when scope changes are common. It shows both progress AND scope creep.
+
+### Bug Metrics
+Track bugs at the sprint level:
+
+- **Bugs opened this sprint**: How many new bugs were reported
+- **Bugs closed this sprint**: How many bugs the team fixed
+- **Bug escape rate**: Bugs found in production vs found in testing
+- **Critical bug count**: Bugs that affect core functionality or block users
+- **Bug ratio**: % of sprint capacity spent on bugs vs features
+
+A healthy team spends 10-20% of capacity on bugs. Above 30% suggests quality issues that need a dedicated investment.
+
+### Cycle Time
+The time from when work starts on a story to when it is done:
+
+- **Short cycle time** (1-3 days): Team is breaking work into small pieces and shipping continuously
+- **Long cycle time** (5+ days): Stories may be too large, or work is getting blocked
+- Track median cycle time, not average (outliers skew the average)
+- Use cycle time to identify bottlenecks: where do items sit the longest?
+
+## Demo Preparation
+
+### What Makes a Good Demo
+- **Tell a story**: Frame the demo as a user scenario, not a feature list. "Here's Sarah, a team lead who needs to..."
+- **Show, don't tell**: Live product demos beat screenshots, which beat slide decks
+- **Keep it short**: 2-3 minutes per feature. Attention drops sharply after 10 minutes.
+- **Show the before and after**: If you improved something, show what it used to be like
+- **Include edge cases**: Show that error states, empty states, and edge cases are handled
+- **Prepare a backup**: Have screenshots or a recording in case the live demo fails
+
+### Demo Anti-Patterns
+- Demoing from a development environment with test data (use staging with realistic data)
+- Walking through every field on every screen (focus on the key user flows)
+- Apologizing for things that are not done ("ignore this part, it is not finished")
+- Skipping the "why" (always explain what user problem this solves before showing the solution)
+- Letting the demo run long (strict time-boxing keeps energy high)
+
+### Demo for Different Audiences
+- **Engineering team**: Show technical details, architecture decisions, interesting implementation challenges
+- **Stakeholders/leadership**: Focus on user value, metrics impact, and strategic alignment
+- **Customers**: Emphasize how it solves their specific problem. Use their language, not internal terminology.
+- **Design team**: Show interaction details, responsiveness, and how edge cases are handled
+
+## Retrospective Facilitation
+
+### Retrospective Formats
+
+**Start, Stop, Continue**:
+- **Start**: Things the team should begin doing
+- **Stop**: Things that are not working and should be abandoned
+- **Continue**: Things that are working well and should keep going
+
+When to use: Default format. Works well for most teams, most of the time.
+
+**4Ls — Liked, Learned, Lacked, Longed For**:
+- **Liked**: What went well this sprint
+- **Learned**: New knowledge or insights gained
+- **Lacked**: What was missing — resources, information, tools
+- **Longed For**: Things the team wishes they had
+
+When to use: When you want to go deeper than Start/Stop/Continue. Good for learning-oriented teams.
+
+**Mad, Sad, Glad**:
+- **Mad**: Things that frustrated or angered the team
+- **Sad**: Things that were disappointing but not infuriating
+- **Glad**: Things that went well and made the team happy
+
+When to use: When you want to surface emotional responses. Good for teams going through a difficult period.
+
+**Sailboat**:
+- **Wind** (what propels us forward): Positive forces helping the team
+- **Anchor** (what holds us back): Negative forces slowing the team
+- **Rocks** (risks ahead): Potential problems on the horizon
+- **Island** (destination): The goal the team is working toward
+
+When to use: Strategic retrospectives. Good for quarterly reviews or after major milestones.
+
+### Running an Effective Retro
+1. **Set the stage** (2 min): Remind the team of the sprint goal and outcomes
+2. **Gather data** (10 min): Individual reflection, then share. Use sticky notes or a digital board.
+3. **Generate insights** (10 min): Group similar items. Vote on what to discuss.
+4. **Decide what to do** (10 min): Pick 1-3 action items. Assign owners and due dates.
+5. **Close** (3 min): Thank the team. Confirm action items.
+
+### Retro Anti-Patterns
+- **No action items**: A retro without action items is just venting. Always end with concrete next steps.
+- **Same issues every sprint**: If the same problems keep appearing, the team is not actually addressing them. Escalate or dedicate time.
+- **Blame-oriented**: Retros should focus on systems and processes, not individuals. "The deploy process is slow" not "Bob broke the deploy."
+- **Skipping retros**: Teams that skip retros lose the feedback loop. Even a 15-minute retro is better than none.
+- **Only negative**: Celebrate wins. Acknowledging what went well is important for team morale and for understanding what to keep doing.
+
+## Sprint Health Indicators
+
+### Healthy Sprint Patterns
+- Team consistently meets 70-90% of sprint commitments
+- Stories are small enough to complete in 1-3 days
+- No single story takes more than half the sprint
+- Blockers are identified and resolved within 1-2 days
+- Sprint scope changes less than 10% after planning
+- Team has time for code review, testing, and quality work
+
+### Warning Signs
+- Velocity trending down over 3+ sprints
+- Stories consistently carry over sprint after sprint
+- More than 30% of capacity spent on bugs or unplanned work
+- Team members regularly working overtime to meet commitments
+- Burndown chart is flat for 3+ days mid-sprint
+- Sprint goals are missed more often than met
+- Retrospective action items are never completed
+
+### When to Intervene
+- If velocity drops 3 sprints in a row, investigate root cause (team morale, tech debt, unclear requirements)
+- If carry-over is chronic, stories are too big or estimates are too optimistic. Break stories down.
+- If unplanned work dominates, the team needs a buffer allocation or the incoming request process needs a gate
+- If sprint goals miss consistently, the team may be committing to too much or the goals are too ambitious