v1.0

2026-03-02 00:36:23 +01:00
parent 61004d0c4e
commit 77dbdfa1b9
118 changed files with 11087 additions and 0 deletions
@@ -0,0 +1,82 @@
+---
+description: Generate realistic dummy datasets for testing — CSV, JSON, SQL inserts, or Python scripts
+argument-hint: "<description of the data you need>"
+---
+
+# /generate-data -- Test Data Generator
+
+Create realistic dummy datasets for development, testing, demos, or prototyping. Outputs as ready-to-use files in your preferred format.
+
+## Invocation
+
+```
+/generate-data 1000 users with names, emails, plan tier, signup date, and activity score
+/generate-data E-commerce orders dataset: products, customers, timestamps, amounts
+/generate-data Sample data matching this schema: [paste table definition]
+```
+
+## Workflow
+
+### Step 1: Define the Dataset
+
+Understand:
+- What entities? (users, orders, events, products, etc.)
+- What columns? (with data types and constraints)
+- How many rows?
+- Any relationships between tables?
+- Any specific distributions? (e.g., "80% should be on the free plan")
+- Any realistic constraints? (emails should be unique, dates should be chronological)
+
+### Step 2: Generate the Data
+
+Apply the **dummy-dataset** skill:
+
+- Create a Python script that generates the dataset
+- Use realistic-looking data (not random strings): proper names, valid email formats, real-seeming dates
+- Respect constraints: unique IDs, foreign key relationships, chronological ordering
+- Apply specified distributions
+- Execute the script and produce the output file
+
+### Step 3: Deliver
+
+Output in the requested format (or ask):
+- **CSV**: Most common, works everywhere
+- **JSON**: For API testing or frontend development
+- **SQL INSERT**: For populating test databases
+- **Python script**: For reproducible generation (user can tweak and re-run)
+
+```
+## Generated Dataset: [Description]
+
+**Rows**: [count]
+**Columns**: [list]
+**Format**: [CSV / JSON / SQL / Python]
+
+### Schema
+| Column | Type | Constraints | Distribution |
+|--------|------|-----------|-------------|
+
+### Sample (first 5 rows)
+[Preview of the data]
+
+### Files
+- [data file]
+- [generator script, if applicable]
+```
+
+Save data file and generator script to the user's workspace.
+
+### Step 4: Offer Follow-ups
+
+- "Want me to **add more columns** or **increase the dataset size**?"
+- "Should I **create related tables** (e.g., orders for these users)?"
+- "Want me to **write test scenarios** that use this data?"
+- "Should I **create SQL queries** to analyze this dataset?"
+
+## Notes
+
+- Always provide the generator script so the user can regenerate with different parameters
+- For demo datasets, make the data tell a story (e.g., seasonal trends, a retention problem, a power user segment)
+- Respect realistic cardinality: 1000 users don't have 1000 unique cities
+- For financial data, use realistic price distributions — not uniform random
+- Never include real personal data — all names, emails, and identifiers must be fake
@@ -0,0 +1,89 @@
+---
+description: Summarize a meeting transcript into structured notes with decisions, action items, and follow-ups
+argument-hint: "<transcript or meeting notes>"
+---
+
+# /meeting-notes -- Meeting Summary
+
+Transform a raw meeting transcript or rough notes into clear, structured meeting minutes with decisions captured and action items assigned.
+
+## Invocation
+
+```
+/meeting-notes [paste transcript]
+/meeting-notes [upload transcript file, audio summary, or notes]
+```
+
+## Workflow
+
+### Step 1: Accept the Transcript
+
+Accept in any format:
+- Full transcript (from Otter, Fireflies, Google Meet, Zoom, etc.)
+- Rough notes taken during the meeting
+- Audio summary or meeting recap from a transcription tool
+- Multiple inputs (e.g., transcript + the user's own notes)
+
+If the input is sparse, work with what's available and flag gaps.
+
+### Step 2: Extract and Structure
+
+Apply the **summarize-meeting** skill:
+
+Parse the content to identify:
+- **Participants**: Who was present (from introductions, speaker labels, or mentions)
+- **Topics discussed**: Major agenda items or conversation threads
+- **Decisions made**: Explicit agreements or conclusions reached
+- **Action items**: Tasks assigned, with owner and deadline if mentioned
+- **Open questions**: Unresolved items that need follow-up
+- **Key quotes**: Important statements worth preserving verbatim
+- **Context**: Meeting type, project, and background
+
+### Step 3: Generate Meeting Summary
+
+```
+## Meeting Summary
+
+**Date**: [date if known]
+**Participants**: [names/roles]
+**Meeting type**: [standup, planning, review, 1:1, stakeholder, etc.]
+**Topic**: [primary subject]
+
+### Summary
+[3-5 sentence overview of what was discussed and concluded]
+
+### Key Decisions
+1. **[Decision]** — [context and rationale]
+2. ...
+
+### Action Items
+| # | Action | Owner | Deadline | Status |
+|---|--------|-------|----------|--------|
+
+### Discussion Highlights
+**[Topic 1]**: [key points, different perspectives, conclusion]
+**[Topic 2]**: [key points, different perspectives, conclusion]
+
+### Open Questions
+- [Question] — needs input from [person/team]
+
+### Next Steps
+- [What happens next]
+- Next meeting: [if mentioned]
+```
+
+Save as markdown.
+
+### Step 4: Offer Follow-ups
+
+- "Want me to **email these notes** to participants?"
+- "Should I **create tickets** from the action items?"
+- "Want me to **draft a stakeholder update** based on the decisions made?"
+
+## Notes
+
+- Decisions are the most valuable output — make sure every decision is captured clearly
+- Action items without owners are useless — if no owner was mentioned, flag it
+- Keep the summary concise — people who weren't in the meeting should get the gist in 30 seconds
+- If the transcript is very long (60+ min meeting), offer a TL;DR before the full summary
+- Distinguish between "discussed" and "decided" — many topics are explored without reaching a conclusion
@@ -0,0 +1,98 @@
+---
+description: Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results
+argument-hint: "<team, product area, or company objective>"
+---
+
+# /plan-okrs -- Team OKR Planning
+
+Generate well-structured OKRs that connect team work to company strategy. Produces 3 OKR sets with qualitative objectives and quantitative key results.
+
+## Invocation
+
+```
+/plan-okrs Growth team Q2 — company goal is 50% ARR increase
+/plan-okrs Onboarding squad aligned to "improve activation rate"
+/plan-okrs [upload company OKRs or strategy doc]
+```
+
+## Workflow
+
+### Step 1: Gather Context
+
+Ask the user:
+- What team or product area are these OKRs for?
+- What time period? (quarterly is standard, but could be annual or custom)
+- What are the company-level objectives these should ladder up to?
+- What happened last quarter? (hits, misses, learnings)
+- Any constraints or known priorities?
+
+Accept company OKRs or strategy documents as uploads.
+
+### Step 2: Generate OKRs
+
+Apply the **brainstorm-okrs** skill:
+
+- Create 3 OKR sets (Objective + 3-5 Key Results each)
+- **Objectives**: Qualitative, inspiring, ambitious but achievable, action-oriented
+- **Key Results**: Quantitative, measurable, time-bound, have clear owners
+- Ensure OKRs ladder to company objectives with visible connection
+- Balance leading indicators (activity) with lagging indicators (outcomes)
+
+### Step 3: Validate Quality
+
+Check each OKR against best practices:
+- Is the Objective inspiring? (Would you rally a team around it?)
+- Are Key Results measurable? (Can you check completion with data, not judgment?)
+- Are targets ambitious but not demoralizing? (70% achievement = well-calibrated)
+- Are there 3-5 KRs per Objective? (More = unfocused)
+- Do KRs avoid gaming? (e.g., "ship 5 features" incentivizes shipping junk)
+
+Flag any issues and suggest improvements.
+
+### Step 4: Present and Iterate
+
+```
+## Team OKRs: [Team Name] — [Period]
+
+**Aligned to**: [Company Objective(s)]
+
+### Objective 1: [Inspiring qualitative statement]
+| # | Key Result | Baseline | Target | Owner |
+|---|-----------|----------|--------|-------|
+| KR1 | [measurable result] | [current] | [target] | [team/person] |
+| KR2 | ... | ... | ... | ... |
+| KR3 | ... | ... | ... | ... |
+
+### Objective 2: [Inspiring qualitative statement]
+[same format]
+
+### Objective 3: [Inspiring qualitative statement]
+[same format]
+
+### Alignment Map
+Company Objective → Team Objective → Key Results → Expected Impact
+
+### Scoring Guide
+- 0.0-0.3: Significant miss — investigate and learn
+- 0.4-0.6: Progress made but fell short
+- 0.7-0.9: Well-calibrated stretch goal — this is the target zone
+- 1.0: Either nailed it or target wasn't ambitious enough
+
+### Check-in Cadence
+- **Weekly**: Quick traffic-light update on each KR
+- **Mid-quarter**: Deep review, adjust targets if context changed
+- **End of quarter**: Score, reflect, feed into next quarter
+```
+
+Offer:
+- "Want me to **adjust ambition levels** — make them more/less aggressive?"
+- "Should I **create a metrics dashboard** for tracking these?"
+- "Want me to **draft a stakeholder update** introducing these OKRs?"
+
+## Notes
+
+- OKRs should describe outcomes, not outputs ("Increase activation by 20%" not "Ship onboarding redesign")
+- If the user doesn't have company OKRs, help them derive team objectives from product strategy or business goals
+- Maximum 3 objectives per team per quarter — more means less focus
+- Key Results should be stretch goals — if you're certain you'll hit them, they're not ambitious enough
+- Flag any KR that could be gamed and suggest a counter-metric
@@ -0,0 +1,104 @@
+---
+description: Run a pre-mortem risk analysis on a PRD, launch plan, or feature — identify what could go wrong before it does
+argument-hint: "<PRD, plan, or feature description>"
+---
+
+# /pre-mortem -- Pre-Launch Risk Analysis
+
+Imagine your launch has failed. Now work backward to figure out why. This command applies the Tigers/Paper Tigers/Elephants framework to surface real risks and create mitigation plans.
+
+## Invocation
+
+```
+/pre-mortem [paste or upload a PRD, launch plan, or feature spec]
+/pre-mortem We're launching a self-serve billing portal next month
+```
+
+## Workflow
+
+### Step 1: Accept the Plan
+
+Accept in any format: PRD, feature spec, launch plan, project brief, or verbal description. The more detail provided, the sharper the risk analysis.
+
+### Step 2: Risk Identification
+
+Apply the **pre-mortem** skill:
+
+Imagine the product has launched and failed. Generate risks across categories:
+- **Technical**: Performance, scalability, integration failures, data issues
+- **User**: Adoption barriers, usability problems, unmet expectations
+- **Business**: Revenue impact, competitive response, market timing
+- **Operational**: Support load, documentation gaps, training needs
+- **Dependencies**: Third-party services, cross-team handoffs, regulatory
+
+### Step 3: Classify Risks
+
+Categorize each risk:
+
+**Tigers** — Real, substantive risks that could cause failure
+- Assess severity: Launch-blocking / Fast-follow / Track
+- For launch-blocking Tigers: immediate mitigation required
+- For fast-follow Tigers: plan to address within first sprint post-launch
+- For track Tigers: monitor but don't delay launch
+
+**Paper Tigers** — Risks that feel scary but are overblown
+- Explain why the concern is manageable
+- Note what would need to change for this to become a real Tiger
+
+**Elephants** — Unspoken risks the team knows about but avoids discussing
+- Surface political, organizational, or uncomfortable risks
+- Frame constructively with suggested conversation starters
+
+### Step 4: Generate Pre-Mortem Report
+
+```
+## Pre-Mortem: [Feature/Launch]
+
+**Date**: [today]
+**Status**: [Draft / Reviewed]
+
+### Risk Summary
+- **Tigers**: [count] ([launch-blocking], [fast-follow], [track])
+- **Paper Tigers**: [count]
+- **Elephants**: [count]
+
+### Launch-Blocking Tigers
+| # | Risk | Likelihood | Impact | Mitigation | Owner | Deadline |
+|---|------|-----------|--------|-----------|-------|----------|
+
+### Fast-Follow Tigers
+| # | Risk | Likelihood | Impact | Planned Response | Owner |
+|---|------|-----------|--------|-----------------|-------|
+
+### Track Tigers
+[Risks to monitor post-launch with trigger conditions]
+
+### Paper Tigers
+[Concerns that seem big but are manageable — with reasoning]
+
+### Elephants in the Room
+[Uncomfortable truths the team should discuss]
+
+### Go/No-Go Checklist
+- [ ] All launch-blocking Tigers mitigated
+- [ ] Fast-follow plan documented and assigned
+- [ ] Monitoring in place for Track Tigers
+- [ ] Rollback plan defined
+- [ ] Support team briefed
+```
+
+Save as markdown.
+
+### Step 5: Offer Next Steps
+
+- "Want me to **update the PRD** with risk mitigations?"
+- "Should I **create test scenarios** for the riskiest areas?"
+- "Want me to **draft a launch checklist** from these findings?"
+
+## Notes
+
+- The best pre-mortems happen when the plan is 80% done — early enough to change course, late enough to have substance
+- Push past the obvious risks — the most dangerous risks are the ones nobody mentions
+- Elephants are the highest-value output — surfacing what the team avoids discussing
+- For each Tiger, the mitigation should be specific and assignable, not "be careful"
+- If the pre-mortem reveals too many launch-blocking Tigers, recommend delaying or phasing the launch
@@ -0,0 +1,193 @@
+---
+description: Sprint lifecycle — plan a sprint, run a retrospective, or generate release notes
+argument-hint: "[plan|retro|release-notes] <context>"
+---
+
+# /sprint -- Sprint Lifecycle
+
+Three modes covering the sprint lifecycle: **plan** for sprint planning, **retro** for retrospectives, **release-notes** for shipping communication.
+
+## Invocation
+
+```
+/sprint plan 2-week sprint, 4 engineers, focus on checkout improvements
+/sprint retro [paste team feedback or sprint data]
+/sprint release-notes [paste tickets, changelog, or PRD]
+/sprint                    # asks which phase you're in
+```
+
+## Modes
+
+---
+
+### Plan Mode
+
+Prepare for sprint planning with capacity estimation, story selection, and risk identification.
+
+#### Workflow
+
+**Step 1: Gather Sprint Context**
+- Sprint duration (1 or 2 weeks)
+- Team composition (engineers, designers, QA — and availability)
+- Sprint goal or focus area
+- Backlog items to consider (paste, upload, or describe)
+- Any carry-over from last sprint
+- Known interruptions (holidays, on-call, meetings)
+
+**Step 2: Estimate Capacity**
+
+Apply the **sprint-plan** skill:
+
+- Calculate available engineering hours/points after meetings, on-call, PTO
+- Apply a velocity adjustment based on historical data (if provided) or industry standard (70% of theoretical capacity)
+- Show capacity breakdown per team member
+
+**Step 3: Select and Sequence Stories**
+
+- Recommend which stories fit within capacity
+- Flag dependency chains (A must complete before B starts)
+- Identify risks: stories that are underspecified, have external dependencies, or need design input
+- Balance quick wins with larger items
+- Ensure every story has acceptance criteria
+
+**Step 4: Generate Sprint Plan**
+
+```
+## Sprint Plan: [Sprint Name/Number]
+
+**Duration**: [dates]
+**Sprint Goal**: [one sentence]
+**Team**: [members and availability]
+
+### Capacity
+| Member | Available Days | Points/Hours | Notes |
+|--------|--------------|-------------|-------|
+
+**Total capacity**: [X] points/hours
+**Recommended commitment**: [Y] points/hours (with buffer)
+
+### Selected Stories
+| # | Story | Points | Owner | Dependencies | Risk |
+|---|-------|--------|-------|-------------|------|
+
+### Sprint Risks
+1. [Risk] — Mitigation: [action]
+
+### Definition of Done
+- [ ] Code reviewed
+- [ ] Tests passing
+- [ ] Deployed to staging
+- [ ] QA approved
+- [ ] Documentation updated (if applicable)
+```
+
+---
+
+### Retro Mode
+
+Facilitate a structured retrospective that produces actionable improvements.
+
+#### Workflow
+
+**Step 1: Gather Sprint Feedback**
+
+Accept input as:
+- Team feedback (pasted from a survey, Slack, or collaborative doc)
+- Sprint metrics (velocity, bugs, incidents)
+- The user's own observations
+
+Ask: "Which retro format do you prefer?"
+- **Start/Stop/Continue** (simple, fast)
+- **4Ls** (Liked, Learned, Lacked, Longed for)
+- **Sailboat** (Wind = helps, Anchor = slows, Rocks = risks, Island = goals)
+
+**Step 2: Analyze and Structure**
+
+Apply the **retro** skill:
+
+- Categorize feedback into the chosen framework
+- Identify themes and patterns
+- Separate symptoms from root causes
+- Highlight wins worth celebrating
+
+**Step 3: Generate Retro Summary**
+
+```
+## Sprint Retrospective: [Sprint Name]
+
+**Date**: [today]
+**Format**: [Start/Stop/Continue | 4Ls | Sailboat]
+**Participants**: [if known]
+
+### What Went Well
+[Grouped themes with supporting evidence]
+
+### What Didn't Go Well
+[Grouped themes with root cause analysis]
+
+### Key Insights
+[2-3 patterns that emerged]
+
+### Action Items
+| # | Action | Owner | Deadline | Priority |
+|---|--------|-------|----------|----------|
+
+### Metrics This Sprint
+| Metric | This Sprint | Last Sprint | Trend |
+|--------|-----------|------------|-------|
+```
+
+---
+
+### Release Notes Mode
+
+Generate user-facing release notes from technical artifacts.
+
+#### Workflow
+
+**Step 1: Accept Release Content**
+
+Accept:
+- Jira/Linear tickets or changelog
+- PRD or feature specs
+- Git commit messages or PR descriptions
+- Team's internal summary of what shipped
+
+**Step 2: Transform**
+
+Apply the **release-notes** skill:
+
+- Translate technical language into user benefits
+- Categorize as: New Features, Improvements, Bug Fixes
+- Write in the product's voice (ask about tone if not clear)
+- Highlight the most impactful change first
+
+**Step 3: Generate Release Notes**
+
+```
+## What's New — [Version/Date]
+
+### Highlights
+[1-2 sentence summary of the most important change]
+
+### New Features
+- **[Feature Name]** — [user-facing benefit in plain language]
+
+### Improvements
+- **[Improvement]** — [what's better now]
+
+### Bug Fixes
+- Fixed [issue] that caused [user impact]
+
+### Coming Soon
+[Optional teaser for next release]
+```
+
+Save as markdown and offer to format for different channels (blog post, in-app, email, Slack announcement).
+
+## Notes
+
+- For plan mode: protect 20% buffer for unplanned work — teams that plan at 100% capacity always miss
+- For retro mode: focus on 2-3 high-impact action items, not 10 things nobody will do
+- For release notes: always frame changes as user benefits, not technical implementations
+- Each mode can chain to the others: plan → (sprint happens) → retro → release-notes
@@ -0,0 +1,107 @@
+---
+description: Map stakeholders on a Power × Interest grid and create a tailored communication plan
+argument-hint: "<project, initiative, or launch>"
+---
+
+# /stakeholder-map -- Stakeholder Mapping & Communication Plan
+
+Identify all stakeholders for a project, map them by influence and interest, and generate a communication plan that ensures the right people get the right information at the right time.
+
+## Invocation
+
+```
+/stakeholder-map New analytics platform launch
+/stakeholder-map Pricing model change affecting all customers
+/stakeholder-map [upload a project brief or org chart]
+```
+
+## Workflow
+
+### Step 1: Understand the Initiative
+
+Ask:
+- What is the project or initiative?
+- What phase is it in? (planning, building, launching, post-launch)
+- Who are the obvious stakeholders you already know about?
+- Are there any politically sensitive dynamics to be aware of?
+
+### Step 2: Identify Stakeholders
+
+Brainstorm stakeholders the user might not have considered:
+- **Internal**: Engineering, Design, QA, Data, Legal, Finance, Marketing, Sales, Support, Leadership
+- **External**: Customers, partners, vendors, regulators, board members
+- **Often missed**: Adjacent teams, on-call engineers, customer success, documentation team
+
+### Step 3: Map to Power × Interest Grid
+
+Apply the **stakeholder-map** skill:
+
+Place each stakeholder in a quadrant:
+
+```
+                    HIGH INTEREST
+                         │
+    KEEP SATISFIED       │      MANAGE CLOSELY
+    (High Power,         │      (High Power,
+     Low Interest)       │       High Interest)
+                         │
+   ──────────────────────┼──────────────────────
+                         │
+    MONITOR              │      KEEP INFORMED
+    (Low Power,          │      (Low Power,
+     Low Interest)       │       High Interest)
+                         │
+                    LOW INTEREST
+```
+
+### Step 4: Generate Communication Plan
+
+```
+## Stakeholder Map: [Initiative]
+
+### Stakeholder Grid
+| Stakeholder | Role | Power | Interest | Quadrant | Stance |
+|------------|------|-------|----------|----------|--------|
+
+### Communication Plan
+
+#### Manage Closely (High Power, High Interest)
+| Stakeholder | Channel | Frequency | Content | Owner |
+|------------|---------|-----------|---------|-------|
+
+#### Keep Satisfied (High Power, Low Interest)
+| Stakeholder | Channel | Frequency | Content | Owner |
+|------------|---------|-----------|---------|-------|
+
+#### Keep Informed (Low Power, High Interest)
+| Stakeholder | Channel | Frequency | Content | Owner |
+|------------|---------|-----------|---------|-------|
+
+#### Monitor (Low Power, Low Interest)
+[Minimal communication — include in broad updates only]
+
+### Potential Conflicts
+[Where stakeholder interests may clash — with mitigation strategies]
+
+### Escalation Path
+[Who to go to when decisions are blocked]
+
+### RACI Matrix
+| Decision Area | Responsible | Accountable | Consulted | Informed |
+|--------------|-------------|-------------|-----------|----------|
+```
+
+Save as markdown.
+
+### Step 5: Offer Next Steps
+
+- "Want me to **draft the first stakeholder update** for the 'Manage Closely' group?"
+- "Should I **create a meeting prep brief** for key stakeholder conversations?"
+- "Want me to **set up a communication cadence** as a recurring checklist?"
+
+## Notes
+
+- The "Manage Closely" quadrant is where PMs spend most of their political capital — get these relationships right
+- "Stance" (supportive, neutral, resistant) helps prioritize where to invest relationship-building effort
+- Don't forget downstream stakeholders: support, docs, and sales enablement teams are often surprised by launches
+- Update the map as the project evolves — stakeholder interest shifts with project phase
@@ -0,0 +1,83 @@
+---
+description: Generate comprehensive test scenarios from user stories or feature specs — happy paths, edge cases, and error handling
+argument-hint: "<user stories, feature spec, or description>"
+---
+
+# /test-scenarios -- Test Scenario Generator
+
+Turn user stories or feature descriptions into comprehensive test scenarios that QA can execute immediately. Covers happy paths, edge cases, error handling, and cross-browser/device considerations.
+
+## Invocation
+
+```
+/test-scenarios [paste user stories or acceptance criteria]
+/test-scenarios [upload a PRD or feature spec]
+/test-scenarios User can reset their password via email link
+```
+
+## Workflow
+
+### Step 1: Accept Input
+
+Accept: user stories, acceptance criteria, PRD sections, feature descriptions, or any specification of expected behavior.
+
+### Step 2: Generate Test Scenarios
+
+Apply the **test-scenarios** skill:
+
+For each user story or requirement, generate:
+
+**Happy Path Scenarios**: The expected user flow works correctly
+**Edge Cases**: Boundary conditions, unusual inputs, concurrent operations
+**Error Scenarios**: What happens when things go wrong
+**Security Scenarios**: If applicable (auth, permissions, data access)
+**Performance Scenarios**: If applicable (load, timeout, large data)
+
+### Step 3: Structure Output
+
+```
+## Test Scenarios: [Feature]
+
+**Source**: [user stories / PRD / description]
+**Total scenarios**: [count]
+**Coverage**: [happy path / edge cases / errors / security / performance]
+
+### Scenario 1: [Title]
+**Tests**: [which story or requirement]
+**Preconditions**: [setup needed]
+**User role**: [who is performing this]
+
+| Step | Action | Expected Result |
+|------|--------|----------------|
+| 1 | [user action] | [expected system response] |
+| 2 | [user action] | [expected system response] |
+
+**Postconditions**: [state after completion]
+**Priority**: [Critical / High / Medium / Low]
+
+---
+[Repeat for each scenario]
+
+### Coverage Matrix
+| Requirement | Happy Path | Edge Cases | Error Handling | Notes |
+|------------|-----------|-----------|---------------|-------|
+
+### Test Data Requirements
+[What test data is needed to execute these scenarios]
+```
+
+Save as markdown.
+
+### Step 4: Offer Next Steps
+
+- "Want me to **generate the test data** for these scenarios?"
+- "Should I **add more edge cases** for any specific scenario?"
+- "Want me to **create the user stories** that these scenarios test?"
+
+## Notes
+
+- Happy paths first, then layer in edge cases — ensure basic flows work before testing boundaries
+- Every acceptance criterion from the original story should map to at least one test scenario
+- Include both positive tests (it works) and negative tests (it fails gracefully)
+- For APIs, include scenarios for rate limiting, timeout, malformed requests, and auth failures
+- Flag scenarios that require specific test environments or third-party service mocking
@@ -0,0 +1,96 @@
+---
+description: Convert a feature-based roadmap into an outcome-focused roadmap that communicates strategic intent
+argument-hint: "<roadmap as text, file, or list of planned features>"
+---
+
+# /transform-roadmap -- Outcome-Focused Roadmap
+
+Take a list of planned features or an output-focused roadmap and rewrite it as an outcome-focused roadmap that communicates *why* instead of *what*.
+
+## Invocation
+
+```
+/transform-roadmap [paste your feature list or roadmap]
+/transform-roadmap [upload a roadmap doc, spreadsheet, or screenshot]
+```
+
+## Workflow
+
+### Step 1: Accept the Current Roadmap
+
+Accept in any format:
+- Feature list or backlog items
+- Roadmap document (Now/Next/Later, quarterly, timeline)
+- Spreadsheet or Gantt chart export
+- Screenshot of a roadmap tool
+
+Parse each item to extract: feature name, description, target date/timeframe, and any context.
+
+### Step 2: Understand Strategic Context
+
+Ask:
+- What are the product goals or OKRs for this period?
+- Who is the audience for this roadmap? (execs, engineering, customers, board)
+- What format do you prefer? (Now/Next/Later, quarterly, timeline)
+
+### Step 3: Transform Each Item
+
+Apply the **outcome-roadmap** skill:
+
+For each feature/output on the roadmap:
+1. Identify the **user or business outcome** it's trying to achieve
+2. Rewrite as an outcome statement: "[Verb] [metric/experience] for [user segment]"
+3. Group features that serve the same outcome under one initiative
+4. Add success metrics to each outcome
+
+**Before → After examples:**
+- "Build SSO integration" → "Reduce enterprise onboarding friction — target: 50% faster time-to-first-value for enterprise accounts"
+- "Redesign dashboard" → "Help power users find insights faster — target: 30% reduction in time-to-insight"
+- "Add CSV export" → "Enable teams to share data outside the product — target: 25% increase in report sharing"
+
+### Step 4: Generate Transformed Roadmap
+
+```
+## Outcome-Focused Roadmap: [Product] — [Period]
+
+**Strategic themes**: [2-3 high-level themes]
+
+### Now (Current Quarter)
+**Theme: [Strategic Theme]**
+| Outcome | Success Metric | Key Initiatives | Status |
+|---------|---------------|----------------|--------|
+
+### Next (Next Quarter)
+**Theme: [Strategic Theme]**
+| Outcome | Success Metric | Key Initiatives | Confidence |
+|---------|---------------|----------------|------------|
+
+### Later (Future)
+**Theme: [Strategic Theme]**
+| Outcome | Success Metric | Key Initiatives | Dependencies |
+|---------|---------------|----------------|-------------|
+
+### Transformation Notes
+| Original Feature | Transformed Outcome | Why This Framing |
+|-----------------|--------------------|-----------------|
+
+### What Changed
+[Summary of how the roadmap narrative shifted]
+```
+
+Save as a markdown file.
+
+### Step 5: Review
+
+Offer:
+- "Want me to **add OKR alignment** for each outcome?"
+- "Should I **draft a stakeholder presentation** of this roadmap?"
+- "Want me to **identify risks** for the Now items?"
+
+## Notes
+
+- Outcomes should be measurable and have a clear "done" state
+- Multiple features can map to one outcome — this is a feature, not a bug
+- If an output doesn't clearly serve an outcome, flag it for the user to justify or deprioritize
+- The audience matters: exec roadmaps should be outcome-only, engineering roadmaps can include deliverables under each outcome
+- "Later" items should be less specific — outcomes without committed solutions
@@ -0,0 +1,118 @@
+---
+description: Create a comprehensive Product Requirements Document from a feature idea or problem statement
+argument-hint: "<feature or problem statement>"
+---
+
+# /write-prd -- Product Requirements Document
+
+Create a structured PRD that aligns stakeholders and guides development. Accepts anything from a vague idea to a detailed brief.
+
+## Invocation
+
+```
+/write-prd SSO support for enterprise customers
+/write-prd Users are dropping off during onboarding — we need to fix step 3
+/write-prd [upload a brief, research doc, or strategy deck]
+```
+
+## Workflow
+
+### Step 1: Understand the Feature
+
+Accept the input in any form:
+- A feature name ("SSO support")
+- A problem statement ("Enterprise customers keep asking for centralized auth")
+- A user request ("Users want to export their data as CSV")
+- A vague idea ("We should do something about onboarding drop-off")
+- An uploaded document (brief, research, Slack thread, email)
+
+### Step 2: Gather Context
+
+Ask conversationally — most important questions first, fill gaps as you go:
+
+1. **User problem**: What problem does this solve? Who experiences it? How painful is it?
+2. **Target users**: Which user segment(s)? How many? What's their current workaround?
+3. **Success metrics**: How will we know this worked? What moves if we nail it?
+4. **Constraints**: Technical constraints, timeline, regulatory, dependencies on other teams?
+5. **Prior art**: Has this been attempted before? Existing solutions in the market?
+6. **Scope preference**: Full solution or phased approach?
+
+If the user provides a document with context, extract what's available and only ask about gaps.
+
+### Step 3: Generate the PRD
+
+Apply the **create-prd** skill to produce an 8-section document:
+
+```
+## Product Requirements Document: [Feature Name]
+
+**Author**: [user]
+**Date**: [today]
+**Status**: Draft
+**Stakeholders**: [if known]
+
+### 1. Executive Summary
+[2-3 sentences: what, for whom, why now]
+
+### 2. Background & Context
+[Problem space, prior research, market context, what prompted this]
+
+### 3. Objectives & Success Metrics
+**Goals** (what success looks like):
+1. [Specific, measurable goal]
+2. [...]
+
+**Non-Goals** (explicitly out of scope):
+1. [What we're not doing, and why]
+2. [...]
+
+**Success Metrics**:
+| Metric | Current | Target | Measurement |
+|--------|---------|--------|-------------|
+
+### 4. Target Users & Segments
+[Who this serves, user profiles, segment sizing]
+
+### 5. User Stories & Requirements
+
+**P0 — Must Have**:
+| # | User Story | Acceptance Criteria |
+|---|-----------|-------------------|
+
+**P1 — Should Have**:
+| # | User Story | Acceptance Criteria |
+|---|-----------|-------------------|
+
+**P2 — Nice to Have / Future**:
+| # | User Story | Acceptance Criteria |
+|---|-----------|-------------------|
+
+### 6. Solution Overview
+[High-level approach, key design decisions, technical approach if known]
+
+### 7. Open Questions
+| Question | Owner | Deadline |
+|----------|-------|----------|
+
+### 8. Timeline & Phasing
+[Milestones, dependencies, phasing if applicable]
+```
+
+### Step 4: Review and Iterate
+
+After generating, offer:
+- "Want me to **tighten the scope**? I can challenge which P1s should really be P2s."
+- "Should I **run a pre-mortem** on this PRD?"
+- "Want me to **break this into user stories** for engineering?"
+- "Should I **create a stakeholder update** to socialize this?"
+
+Save the PRD as a markdown file to the user's workspace.
+
+## Notes
+
+- Be opinionated about scope — a tight PRD is better than an expansive vague one
+- If the idea is too big, proactively suggest phasing and spec only Phase 1
+- Non-goals are as important as goals — they prevent scope creep
+- Success metrics must be specific: "improve NPS" is bad, "increase NPS from 32 to 45 within 90 days of launch" is good
+- Open questions should be genuinely unresolved — don't list things you can answer from context
+- If the user provides research, weave insights into the Background section with attribution
@@ -0,0 +1,112 @@
+---
+description: Break a feature into backlog items — user stories, job stories, or WWA format with acceptance criteria
+argument-hint: "[user|job|wwa] <feature description or PRD>"
+---
+
+# /write-stories -- Backlog Item Generator
+
+Break a feature into well-structured backlog items. Choose from three formats based on your team's preference, each with full acceptance criteria.
+
+## Invocation
+
+```
+/write-stories user Allow users to export reports as PDF and CSV
+/write-stories job Notification system for task deadlines
+/write-stories wwa Dark mode for the mobile app
+/write-stories [upload a PRD or feature spec]      # asks format preference
+/write-stories                                      # asks for feature and format
+```
+
+## Formats
+
+### User Stories
+**Format**: "As a [user type], I want [capability], so that [benefit]"
+Apply the **user-stories** skill:
+- Follow the 3 C's: Card (brief), Conversation (context), Confirmation (acceptance criteria)
+- Validate against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
+- Include design links or mockup references where relevant
+
+### Job Stories
+**Format**: "When [situation], I want to [motivation], so I can [outcome]"
+Apply the **job-stories** skill:
+- Focus on the situation and context, not the user role
+- Ground in real user scenarios observed in research
+- Ideal for JTBD-oriented teams
+
+### WWA (Why-What-Acceptance)
+**Format**: Why [strategic context] → What [deliverable] → Acceptance [criteria]
+Apply the **wwas** skill:
+- Includes strategic reasoning (why we're building this)
+- Produces independent, valuable, testable items
+- Good for cross-functional teams that need business context
+
+## Workflow
+
+### Step 1: Accept the Feature
+
+Accept in any form: PRD, feature description, user research finding, or verbal idea. If a PRD is provided, extract the requirements to decompose.
+
+### Step 2: Determine Format
+
+If not specified in the invocation, ask:
+- "Which format does your team use? **User stories**, **Job stories**, or **WWA**?"
+- If unsure, recommend user stories as the default
+
+### Step 3: Decompose the Feature
+
+- Break the feature into 5-15 independent stories (small enough to complete in one sprint)
+- Ensure each story is independently valuable (delivers user value on its own)
+- Order by dependency and priority
+- Write 3-5 acceptance criteria per story
+- Flag stories that need design input or technical spikes
+
+### Step 4: Generate Stories
+
+```
+## Backlog: [Feature Name]
+
+**Format**: [User Stories / Job Stories / WWA]
+**Total stories**: [count]
+**Estimated total effort**: [if possible]
+
+### Stories
+
+#### Story 1: [Short title]
+**[The story in chosen format]**
+
+Acceptance Criteria:
+- [ ] [Criterion 1]
+- [ ] [Criterion 2]
+- [ ] [Criterion 3]
+
+Priority: [P0/P1/P2] | Effort: [S/M/L] | Dependencies: [none or list]
+
+---
+[Repeat for each story]
+
+### Story Map
+[Visual ordering: must-have → should-have → nice-to-have]
+
+### Technical Notes
+[Cross-cutting concerns: API changes, data migration, infrastructure]
+
+### Open Questions
+[Things that need answers before implementation can start]
+```
+
+Save as markdown.
+
+### Step 5: Offer Next Steps
+
+- "Want me to **generate test scenarios** for these stories?"
+- "Should I **create dummy data** for development and testing?"
+- "Want me to **estimate sprint capacity** for these stories?"
+- "Should I **convert to a different format** (user stories ↔ job stories ↔ WWA)?"
+
+## Notes
+
+- One story = one deployable unit of value — if it needs another story to be useful, they should be combined
+- Acceptance criteria should be testable by QA without additional interpretation
+- Error handling and edge cases deserve their own stories, not bullet points within a happy-path story
+- If the feature is large (15+ stories), suggest grouping into epics or phases
+- Flag any story that requires a spike (technical investigation before estimation is possible)