Add files via upload
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: assumption-mapper
|
||||
description: Extract and risk-rate all hidden assumptions in a product brief or PRD
|
||||
tool_integration: Miro
|
||||
---
|
||||
# Assumption Mapping Skill
|
||||
|
||||
## Purpose
|
||||
Surface and prioritize the untested assumptions embedded in any product plan before development begins.
|
||||
|
||||
## Process
|
||||
1. Read the provided brief, PRD, or concept description
|
||||
2. Extract all assumptions across four categories:
|
||||
- **Desirability** (do users want this?)
|
||||
- **Feasibility** (can we build it?)
|
||||
- **Viability** (will it sustain the business?)
|
||||
- **Usability** (can users actually use it?)
|
||||
3. For each assumption, score:
|
||||
- Confidence (1-5): How sure are we this is true?
|
||||
- Impact (1-5): How badly does the plan fail if this assumption is wrong?
|
||||
- Priority = Impact minus Confidence (higher score = test this first)
|
||||
4. Output a ranked list with recommended validation methods
|
||||
|
||||
## Output Format
|
||||
|
||||
### Assumption Map: [Feature/Product Name]
|
||||
| Assumption | Category | Confidence | Impact | Priority Score | Recommended Validation |
|
||||
|------------|----------|------------|--------|----------------|----------------------|
|
||||
| [assumption] | [type] | [1-5] | [1-5] | [score] | [method] |
|
||||
|
||||
#### Top 3 Assumptions to Validate First
|
||||
[Detailed recommendations for highest-priority items]
|
||||
|
||||
## Notes
|
||||
- Flag any assumption that scores 4+ on Impact and 2 or below on Confidence as CRITICAL
|
||||
- Suggest specific research methods: usability test, survey, prototype test, data analysis
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: competitor-signal-tracker
|
||||
description: Analyse competitor moves and surface strategic implications for your product
|
||||
tool_integration: Notion
|
||||
---
|
||||
# Competitor Signal Tracker Skill
|
||||
|
||||
## Purpose
|
||||
Turn scattered competitor information into structured strategic intelligence — not just "what they did" but "what it means for us."
|
||||
|
||||
## Signal Categories to Track
|
||||
- **Product signals:** New features, removals, UX changes, beta programmes
|
||||
- **Pricing signals:** Changes to tiers, free limits, enterprise terms
|
||||
- **Hiring signals:** Job postings that reveal strategic bets (e.g., hiring ML engineers = AI investment)
|
||||
- **Partnership signals:** Integrations, acquisitions, ecosystem moves
|
||||
- **Messaging signals:** Changes in positioning, target audience, value proposition
|
||||
|
||||
## Process
|
||||
1. For each competitor update provided, categorise the signal type
|
||||
2. Assess: Is this reactive (responding to market) or proactive (setting direction)?
|
||||
3. Rate strategic threat level: High / Medium / Low / Watch
|
||||
4. Connect to your roadmap: does this accelerate, validate, or challenge any of your bets?
|
||||
5. Recommend a response: Accelerate existing initiative / Deprioritise / Monitor / Investigate further
|
||||
|
||||
## Output Format
|
||||
|
||||
### Competitive Intelligence Report — [Date]
|
||||
|
||||
#### [Competitor Name]
|
||||
**Signal:** [What they did]
|
||||
**Signal Type:** [Product / Pricing / Hiring / Partnership / Messaging]
|
||||
**Reactive or Proactive:** [assessment]
|
||||
**Threat Level:** [High / Medium / Low / Watch]
|
||||
**Implication for Us:** [Specific connection to our roadmap or strategy]
|
||||
**Recommended Response:** [Action + owner + timeline]
|
||||
|
||||
#### Strategic Summary
|
||||
[2-3 sentences on the overall competitive landscape shift this week/month]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: design-handoff-brief
|
||||
description: Transform feature briefs into structured design briefs that give designers the context they need
|
||||
tool_integration: Figma, Notion
|
||||
---
|
||||
# Design Handoff Brief Skill
|
||||
|
||||
## Purpose
|
||||
Produce a design brief that sets designers up for success — grounding them in user context and constraints before they open Figma, not after they've gone in the wrong direction.
|
||||
|
||||
## What Designers Actually Need (and PMs Often Skip)
|
||||
- The user's goal, not the feature name
|
||||
- The emotional state of the user at this moment in the journey
|
||||
- What success looks like — how will we know the design worked?
|
||||
- Constraints: technical, legal, brand, accessibility
|
||||
- Edge cases that must be handled
|
||||
- What we're explicitly NOT solving for
|
||||
|
||||
## Process
|
||||
1. Read the feature brief or PRD provided
|
||||
2. Extract user goal (reframe from feature language to user outcome language)
|
||||
3. Identify constraints — technical limitations, brand guidelines, accessibility requirements
|
||||
4. List edge cases the design must handle
|
||||
5. Define success criteria the design should be evaluated against
|
||||
6. Write a "not in scope" section to prevent scope creep in design
|
||||
|
||||
## Output Format
|
||||
|
||||
### Design Brief: [Feature Name]
|
||||
|
||||
**User Goal:** (in the user's words, not ours)
|
||||
"When I [situation], I want to [motivation] so that I can [outcome]."
|
||||
|
||||
**Context & Emotional State:**
|
||||
[Where is the user in their journey? What are they feeling? What just happened?]
|
||||
|
||||
**Design Success Criteria:**
|
||||
- [Criterion 1 — measurable where possible]
|
||||
- [Criterion 2]
|
||||
- [Criterion 3]
|
||||
|
||||
**Constraints:**
|
||||
- Technical: [limitations engineering has flagged]
|
||||
- Brand: [relevant brand guidelines]
|
||||
- Accessibility: [WCAG level required, any specific requirements]
|
||||
- Legal/Compliance: [if applicable]
|
||||
|
||||
**Edge Cases to Design For:**
|
||||
- [Edge case 1]
|
||||
- [Edge case 2]
|
||||
- [Edge case 3]
|
||||
|
||||
**Explicitly Out of Scope:**
|
||||
- [What we are NOT solving in this design iteration]
|
||||
|
||||
**Reference Material:**
|
||||
- User research: [link]
|
||||
- Existing patterns: [Figma component library link]
|
||||
- Competitor examples: [links if relevant]
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: executive-update
|
||||
description: Transform detailed product updates into concise executive briefings
|
||||
tool_integration: Slack, Microsoft Teams
|
||||
---
|
||||
# Executive Update Skill
|
||||
|
||||
## Purpose
|
||||
Produce a stakeholder update that busy executives will actually read — structured around what they care about: decisions, risks, and numbers.
|
||||
|
||||
## Executive Communication Principles
|
||||
- Lead with the headline, not the context
|
||||
- Every update should answer: "So what does this mean for the business?"
|
||||
- Flag decisions needed clearly — don't bury asks in paragraphs
|
||||
- Be honest about risks — executives hate surprises more than bad news
|
||||
|
||||
## Process
|
||||
1. Read the full product update provided
|
||||
2. Identify: key metric movements, decisions required, risks to flag, wins to celebrate
|
||||
3. Write in reverse pyramid style — most important first
|
||||
4. Limit to 250 words maximum for the main body
|
||||
5. Add a "Decisions Needed" section with clear options and your recommendation
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Update — [Date / Sprint / Month]
|
||||
**Headline:** [One sentence on the most important thing]
|
||||
|
||||
**By the Numbers:**
|
||||
- [Metric 1]: [value] ([vs. target / last period])
|
||||
- [Metric 2]: [value] ([vs. target / last period])
|
||||
- [Metric 3]: [value] ([vs. target / last period])
|
||||
|
||||
**Progress This Period:**
|
||||
[3-4 bullet points, outcome-focused not activity-focused]
|
||||
|
||||
**Risks & Watch Items:**
|
||||
[2-3 bullets — be direct, include mitigation]
|
||||
|
||||
**Decisions Needed:**
|
||||
1. [Decision] — Options: [A] or [B] — Recommendation: [your view] — Needed by: [date]
|
||||
|
||||
**What's Next:**
|
||||
[2-3 bullets on next period priorities]
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
name: launch-readiness
|
||||
description: Run a comprehensive pre-launch readiness assessment across all functions
|
||||
tool_integration: Notion, Jira, Slack
|
||||
---
|
||||
# Launch Readiness Skill
|
||||
|
||||
## Purpose
|
||||
Ensure nothing falls through the cracks before launch by systematically checking readiness across every function — and producing a clear, evidenced go/no-go recommendation.
|
||||
|
||||
## Readiness Checklist by Function
|
||||
|
||||
### Product & Engineering
|
||||
- [ ] Feature complete against launch spec
|
||||
- [ ] Performance benchmarks met
|
||||
- [ ] Accessibility standards checked
|
||||
- [ ] Edge cases documented and handled
|
||||
- [ ] Rollback plan defined
|
||||
|
||||
### Marketing & Comms
|
||||
- [ ] Launch messaging approved
|
||||
- [ ] Blog post / press release drafted
|
||||
- [ ] Social content prepared
|
||||
- [ ] Email campaigns scheduled
|
||||
- [ ] Landing page live and tested
|
||||
|
||||
### Support & Success
|
||||
- [ ] Support team trained on new feature
|
||||
- [ ] FAQ and help docs published
|
||||
- [ ] Escalation path defined for launch issues
|
||||
- [ ] Customer success briefed (if enterprise)
|
||||
|
||||
### Sales & Partnerships
|
||||
- [ ] Sales enablement materials ready
|
||||
- [ ] Pricing confirmed and communicated
|
||||
- [ ] Partner comms sent (if applicable)
|
||||
|
||||
### Data & Analytics
|
||||
- [ ] Tracking events implemented and verified
|
||||
- [ ] Launch metrics dashboard live
|
||||
- [ ] Baseline metrics captured pre-launch
|
||||
|
||||
## Process
|
||||
1. Review provided launch brief and checklist responses
|
||||
2. Flag any incomplete items as blockers (must fix) or risks (monitor)
|
||||
3. Assess overall readiness and produce go/no-go recommendation with rationale
|
||||
4. If no-go, specify exactly what must be completed and by when
|
||||
|
||||
## Output Format
|
||||
|
||||
### Launch Readiness Assessment: [Feature/Product Name]
|
||||
**Launch Date:** [date]
|
||||
**Overall Status:** ✅ Go / ⚠️ Conditional Go / 🛑 No-Go
|
||||
|
||||
**Blockers (must resolve before launch):**
|
||||
- [item + owner + resolution required by]
|
||||
|
||||
**Risks (monitor closely):**
|
||||
- [item + mitigation plan]
|
||||
|
||||
**Ready Areas:**
|
||||
- [function]: ✅ Ready
|
||||
|
||||
**Recommendation:**
|
||||
[Clear go/no-go with rationale — 3-5 sentences]
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: product-health-analysis
|
||||
description: Interpret product metrics against goals and surface actionable signals
|
||||
tool_integration: Google Analytics, Mixpanel
|
||||
---
|
||||
# Product Health Dashboard Skill
|
||||
|
||||
## Purpose
|
||||
Transform raw metrics data into a clear health narrative — what's working, what's not, and what needs immediate attention.
|
||||
|
||||
## Metrics Framework
|
||||
Analyse across four layers:
|
||||
1. **Acquisition** — new users, source quality, CAC trends
|
||||
2. **Activation** — time to first value, onboarding completion rates
|
||||
3. **Engagement** — DAU/MAU, feature adoption, session depth
|
||||
4. **Retention** — D1/D7/D30 retention, churn rate, resurrection rate
|
||||
|
||||
## Process
|
||||
1. For each metric, compare: current period vs. previous period, current vs. target
|
||||
2. Flag anything more than 10% off target as requiring investigation
|
||||
3. Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
|
||||
4. Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
|
||||
5. Recommend top 3 areas for immediate investigation with suggested diagnostic steps
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Health Report — [Period]
|
||||
**Overall Health:** 🟢 On Track / 🟡 Watch / 🔴 Action Required
|
||||
|
||||
| Metric | Current | Target | vs. Last Period | Status |
|
||||
|--------|---------|--------|-----------------|--------|
|
||||
| [metric] | [value] | [target] | [+/-%] | [🟢/🟡/🔴] |
|
||||
|
||||
**Key Observations:**
|
||||
[3-5 bullet observations written in plain English]
|
||||
|
||||
**Areas Requiring Investigation:**
|
||||
1. [Metric + hypothesis + suggested diagnostic]
|
||||
2. [Metric + hypothesis + suggested diagnostic]
|
||||
3. [Metric + hypothesis + suggested diagnostic]
|
||||
|
||||
**Recommended Actions:**
|
||||
[Specific next steps with owners and timelines]
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
description: Analyse sprint delivery data and produce a structured retrospective brief
|
||||
tool_integration: Jira, Miro
|
||||
---
|
||||
# Retrospective Analysis Skill
|
||||
|
||||
## Purpose
|
||||
Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint tickets: planned vs. completed
|
||||
- Carry-over tickets and reasons
|
||||
- Tickets reopened after closing
|
||||
- Any incidents or unplanned work
|
||||
- Sprint velocity vs. historical average
|
||||
|
||||
## Process
|
||||
1. Calculate: completion rate, carry-over rate, unplanned work percentage
|
||||
2. Identify patterns: which ticket types were most likely to carry over? Which caused blockers?
|
||||
3. Note any process or communication breakdowns visible in the data
|
||||
4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
|
||||
5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [Number] Retrospective Brief
|
||||
|
||||
**By the Numbers:**
|
||||
- Planned: [n] tickets | Completed: [n] | Carry-over: [n] | Completion rate: [%]
|
||||
- Unplanned work: [n] tickets ([%] of capacity)
|
||||
- Velocity: [points] vs. [average] average
|
||||
|
||||
**What the Data Suggests:**
|
||||
[2-3 observations grounded in the numbers above]
|
||||
|
||||
**Discussion Prompts:**
|
||||
- Start: [specific prompt]
|
||||
- Stop: [specific prompt]
|
||||
- Continue: [specific prompt]
|
||||
|
||||
**Suggested Experiment for Next Sprint:**
|
||||
[One concrete, testable process change]
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: rice-impact-matrix
|
||||
description: Score features using RICE and plot against strategic alignment for nuanced prioritisation
|
||||
tool_integration: Miro, Jira
|
||||
---
|
||||
# RICE + Strategic Alignment Skill
|
||||
|
||||
## Purpose
|
||||
Produce a prioritisation output that balances quantitative RICE scoring with qualitative strategic fit — because the highest RICE score isn't always the right next bet.
|
||||
|
||||
## Two-Stage Process
|
||||
|
||||
### Stage 1: RICE Scoring
|
||||
- Reach: Users affected per quarter
|
||||
- Impact: 3/2/1/0.5/0.25 scale
|
||||
- Confidence: 100% / 80% / 50%
|
||||
- Effort: Person-months
|
||||
- RICE = (R × I × C) / E
|
||||
|
||||
### Stage 2: Strategic Alignment Score
|
||||
Rate each initiative against your current strategic priorities (provide these as input):
|
||||
- Directly supports top OKR: +3
|
||||
- Supports secondary OKR: +2
|
||||
- Neutral: +1
|
||||
- Contradicts strategic direction: -1
|
||||
|
||||
### Final Priority Score
|
||||
Combined Score = RICE Score + (Strategic Alignment × 10)
|
||||
|
||||
## Output Format
|
||||
|
||||
### Priority Matrix — [Quarter]
|
||||
| Initiative | RICE Score | Strategic Alignment | Combined Score | Quadrant | Recommendation |
|
||||
|------------|------------|--------------------|--------------------|----------|----------------|
|
||||
| [name] | [score] | [score] | [combined] | [Now/Next/Later/Drop] | [action] |
|
||||
|
||||
#### Quadrant Definitions
|
||||
- **Now:** High RICE + High Strategic Alignment → Build this quarter
|
||||
- **Next:** High RICE + Lower Alignment → Queue for next quarter
|
||||
- **Later:** Lower RICE + High Alignment → Revisit when capacity allows
|
||||
- **Drop:** Low RICE + Low Alignment → Remove from backlog
|
||||
|
||||
#### Recommendations
|
||||
[Top 5 initiatives with rationale for sequencing]
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: rice-prioritisation
|
||||
description: Score and rank product initiatives using the RICE framework
|
||||
tool_integration: Jira
|
||||
---
|
||||
# RICE Prioritisation Skill
|
||||
|
||||
## Purpose
|
||||
Apply consistent, criteria-based RICE scoring to a list of features or initiatives to produce an objective prioritisation ranking.
|
||||
|
||||
## RICE Definitions (adapt to your context)
|
||||
- **Reach:** Number of users affected per quarter (use actual DAU/MAU data where available)
|
||||
- **Impact:** Effect on your primary metric — use scale: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
|
||||
- **Confidence:** How certain are we about R and I estimates? 100%=high, 80%=medium, 50%=low
|
||||
- **Effort:** Person-months required across all functions
|
||||
|
||||
## RICE Formula
|
||||
RICE Score = (Reach × Impact × Confidence) / Effort
|
||||
|
||||
## Process
|
||||
1. For each initiative provided, gather or estimate R, I, C, E values
|
||||
2. Flag where estimates are weak and note what data would improve them
|
||||
3. Calculate RICE score for each
|
||||
4. Rank highest to lowest
|
||||
5. Flag any "quick wins" (high RICE score, low effort) and "moonshots" (high impact, high effort)
|
||||
6. Note dependencies between items that affect sequencing
|
||||
|
||||
## Output Format
|
||||
|
||||
### RICE Prioritisation: [Backlog/Quarter]
|
||||
| Initiative | Reach | Impact | Confidence | Effort | RICE Score | Notes |
|
||||
|------------|-------|--------|------------|--------|------------|-------|
|
||||
| [name] | [n] | [score] | [%] | [months] | [score] | [flags] |
|
||||
|
||||
#### Recommended Sequence
|
||||
[Top 5 initiatives with rationale]
|
||||
|
||||
#### Data Gaps to Address
|
||||
[What information would most improve scoring accuracy]
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: roadmap-narrative
|
||||
description: Transform a prioritised initiative list into a compelling strategic roadmap narrative
|
||||
tool_integration: Notion, Miro
|
||||
---
|
||||
# Roadmap Narrative Skill
|
||||
|
||||
## Purpose
|
||||
Convert a ranked list of product initiatives into a clear, strategic narrative that connects individual items to company goals and communicates a coherent product direction.
|
||||
|
||||
## Process
|
||||
1. Review the prioritised initiative list and company OKRs provided
|
||||
2. Identify 2-3 strategic themes that group the initiatives naturally
|
||||
3. For each theme, articulate: the problem it addresses, the customer it serves, the metric it moves
|
||||
4. Write a quarter-level narrative that shows progression — how does H1 set up H2?
|
||||
5. Draft an executive summary (3-4 sentences max) that non-technical stakeholders can repeat
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Roadmap: [Quarter/Half/Year]
|
||||
**Strategic Context:** [1 paragraph: market moment, key challenge, our response]
|
||||
|
||||
#### Theme 1: [Theme Name]
|
||||
- Strategic rationale
|
||||
- Initiatives included
|
||||
- Primary metric impacted
|
||||
- Dependencies
|
||||
|
||||
[Repeat for each theme]
|
||||
|
||||
**Executive Summary (shareable):**
|
||||
[3-4 sentences that could be shared in an all-hands or board update]
|
||||
|
||||
## Tone Guidelines
|
||||
- Avoid jargon — write for a CFO, not an engineer
|
||||
- Lead with customer outcomes, not features
|
||||
- Be honest about what's NOT on the roadmap and why
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: sprint-brief
|
||||
description: Generate a structured sprint brief from Jira sprint data and goals
|
||||
tool_integration: Jira, Slack
|
||||
---
|
||||
# Sprint Brief Skill
|
||||
|
||||
## Purpose
|
||||
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint name and number
|
||||
- Sprint goal (1-2 sentences)
|
||||
- Ticket list with owners
|
||||
- Known dependencies or blockers
|
||||
- Carry-over items from previous sprint
|
||||
|
||||
## Process
|
||||
1. Read sprint goal and check it's specific and measurable — flag if it's too vague
|
||||
2. Group tickets by theme or feature area
|
||||
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
|
||||
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
|
||||
5. Note carry-over items and whether they affect this sprint's goal
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [Number] Brief — [Dates]
|
||||
**Sprint Goal:** [1-2 sentences]
|
||||
**Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
|
||||
|
||||
**What We're Building:**
|
||||
- [Theme 1]: [tickets and owners]
|
||||
- [Theme 2]: [tickets and owners]
|
||||
|
||||
**Critical Path:** [The 2-3 tickets everything else depends on]
|
||||
|
||||
**Risks to Flag:**
|
||||
- [Risk 1 + mitigation]
|
||||
- [Risk 2 + mitigation]
|
||||
|
||||
**Carry-over from Last Sprint:** [List + impact on current goal]
|
||||
|
||||
**Definition of Done:** [Specific, agreed criteria for sprint success]
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: user-interview-synthesis
|
||||
description: Synthesise user interview transcripts into structured research findings
|
||||
tool_integration: Notion
|
||||
---
|
||||
# User Interview Synthesis Skill
|
||||
|
||||
## Purpose
|
||||
Transform raw interview transcripts into a structured synthesis document that surfaces themes, pain points, and actionable insights.
|
||||
|
||||
## Process
|
||||
1. Read all provided transcripts fully before drawing conclusions
|
||||
2. Identify recurring themes (minimum 3 mentions to qualify as a theme)
|
||||
3. Categorize findings into: Pain Points, Workflow Insights, Feature Requests, Delight Moments
|
||||
4. Select 2-3 verbatim quotes per theme that best represent the pattern
|
||||
5. Draft "So What" implications for each theme — what does this mean for the product?
|
||||
|
||||
## Output Format
|
||||
|
||||
### Research Synthesis: [Study Name]
|
||||
**Participants:** [n]
|
||||
**Date Range:** [dates]
|
||||
**Research Questions:** [list]
|
||||
|
||||
#### Theme 1: [Theme Name]
|
||||
- Summary (2-3 sentences)
|
||||
- Supporting quotes
|
||||
- Implication for product
|
||||
|
||||
[Repeat for each theme]
|
||||
|
||||
#### Recommended Next Steps
|
||||
[Specific, actionable recommendations based on findings]
|
||||
|
||||
## Quality Checks
|
||||
- Every theme must be supported by quotes from at least 3 participants
|
||||
- Implications must connect to product decisions, not just observations
|
||||
- Avoid researcher bias — let the data lead
|
||||
Reference in New Issue
Block a user