add marketplace plugin structure
This commit is contained in:
mohitagw15856
@@ -0,0 +1,145 @@
|
||||
---
|
||||
name: ai-product-canvas
|
||||
description: Structures AI and ML product decisions including model selection, data requirements, evaluation frameworks, and responsible AI considerations. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Triggers on "AI product", "LLM feature", "AI canvas", "build with AI", "AI integration", "AI-powered", "machine learning feature".
|
||||
---
|
||||
|
||||
# AI Product Canvas Skill
|
||||
|
||||
Define AI products with the same rigour as any product decision — but with additional layers for data, model, evaluation, and responsible AI. This canvas prevents the most common AI product failure: building a technically impressive feature that doesn't solve a real problem.
|
||||
|
||||
## AI Product Anti-Patterns to Check First
|
||||
|
||||
Before building, flag if any of these apply:
|
||||
- ❌ "We should add AI to [existing feature]" — with no user problem defined
|
||||
- ❌ Accuracy target undefined before build begins
|
||||
- ❌ No plan for what happens when the model is wrong
|
||||
- ❌ User-facing AI output with no human review or fallback
|
||||
- ❌ Training data not audited for bias or quality
|
||||
- ❌ No evaluation metric — "we'll know it when we see it"
|
||||
|
||||
---
|
||||
|
||||
## AI Product Canvas Output Format
|
||||
|
||||
### AI Product Canvas — [Feature Name] — [Date]
|
||||
|
||||
**PM Owner:** [Name]
|
||||
**ML/AI Lead:** [Name]
|
||||
**Status:** Discovery / Design / Build / Evaluation / Live
|
||||
|
||||
---
|
||||
|
||||
#### 1. Problem Definition
|
||||
**User problem being solved:**
|
||||
> [What specific situation is the user in? What job are they trying to get done?]
|
||||
|
||||
**Why AI?**
|
||||
> [What makes this problem require AI vs a deterministic solution? If the answer is "because we can," stop here.]
|
||||
|
||||
**Success for the user looks like:**
|
||||
> [What outcome does the user experience when the AI feature is working well?]
|
||||
|
||||
---
|
||||
|
||||
#### 2. AI Approach
|
||||
|
||||
**Task type:**
|
||||
- [ ] Classification
|
||||
- [ ] Generation (text, image, code)
|
||||
- [ ] Summarisation / extraction
|
||||
- [ ] Recommendation
|
||||
- [ ] Search / retrieval
|
||||
- [ ] Prediction / forecasting
|
||||
- [ ] Conversation / agent
|
||||
|
||||
**Model approach:**
|
||||
- [ ] LLM API (GPT-4, Claude, Gemini, etc.) — specify: [Model name + version]
|
||||
- [ ] Fine-tuned model on own data
|
||||
- [ ] Custom model trained from scratch
|
||||
- [ ] RAG (retrieval-augmented generation)
|
||||
- [ ] Embedding + vector search
|
||||
|
||||
**Rationale for chosen approach:** [Why this, not alternatives]
|
||||
|
||||
---
|
||||
|
||||
#### 3. Data Requirements
|
||||
|
||||
| Data Type | Source | Volume | Quality Status | Bias Risk |
|
||||
|---|---|---|---|---|
|
||||
| [Training data] | [Where it comes from] | [Volume] | [Audit status] | H/M/L |
|
||||
| [Evaluation data] | [Where it comes from] | [Volume] | [Audit status] | H/M/L |
|
||||
|
||||
**Data gaps:** [What's missing and plan to get it]
|
||||
**Privacy considerations:** [Any PII in training or inference data]
|
||||
**Data ownership:** [Do we own this data? Can we use it for training?]
|
||||
|
||||
---
|
||||
|
||||
#### 4. Evaluation Framework
|
||||
|
||||
**Primary metric:** [The number that defines success — accuracy, F1, BLEU, user rating, task completion rate]
|
||||
**Minimum acceptable threshold:** [Below X, the feature does not ship]
|
||||
**Human evaluation plan:** [How will humans review model outputs? Sampling rate? Review panel?]
|
||||
|
||||
| Evaluation Type | Method | Cadence | Owner |
|
||||
|---|---|---|---|
|
||||
| Offline (pre-launch) | [Test set, benchmark] | Pre-launch | ML Lead |
|
||||
| Online (post-launch) | [A/B test, user feedback] | Weekly | PM + ML |
|
||||
| Adversarial | [Red-team, edge cases] | Pre-launch | Safety reviewer |
|
||||
|
||||
---
|
||||
|
||||
#### 5. User Experience Design
|
||||
|
||||
**How is AI output presented?**
|
||||
- [ ] Direct output shown to user (high trust required)
|
||||
- [ ] AI-assisted with user confirmation
|
||||
- [ ] Suggestion user can accept/reject
|
||||
- [ ] Background action with audit log
|
||||
|
||||
**Confidence and uncertainty handling:**
|
||||
- What happens when confidence is low? [Show alternative, ask for clarification, fallback to manual]
|
||||
- How is uncertainty communicated to the user? [UI pattern]
|
||||
|
||||
**Fallback plan:**
|
||||
- If the model fails or returns an error: [Specific fallback behaviour]
|
||||
- If accuracy degrades below threshold: [Kill switch or graceful degradation plan]
|
||||
|
||||
---
|
||||
|
||||
#### 6. Responsible AI Checklist
|
||||
|
||||
- [ ] Bias audit completed on training data
|
||||
- [ ] Demographic fairness evaluated (does performance differ by user group?)
|
||||
- [ ] Hallucination / confabulation risk assessed and mitigated
|
||||
- [ ] User can see and correct AI output
|
||||
- [ ] Opt-out mechanism exists (can user disable the AI feature?)
|
||||
- [ ] Output provenance visible when relevant (does user know AI generated this?)
|
||||
- [ ] PII not used in ways user didn't consent to
|
||||
- [ ] Regulatory review completed (GDPR, AI Act, sector-specific)
|
||||
- [ ] Model cards / documentation completed
|
||||
|
||||
---
|
||||
|
||||
#### 7. Launch & Monitoring Plan
|
||||
|
||||
**Rollout:** [% of users, with staged expansion criteria]
|
||||
**Monitoring metrics:**
|
||||
- Model performance: [Metric + alert threshold]
|
||||
- User engagement with AI output: [Acceptance rate, override rate, feedback score]
|
||||
- Error rate: [% of failed inferences]
|
||||
- Latency: [P95 target]
|
||||
|
||||
**Model refresh cadence:** [How often is the model retrained or updated?]
|
||||
**Drift detection:** [How will you know when model performance degrades in production?]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never skip the "Why AI?" section — it's the most important question in AI product development
|
||||
- The fallback UX is not optional — what happens when AI fails defines your product's trustworthiness
|
||||
- Responsible AI checklist must be completed before launch, not after
|
||||
- Include latency in success metrics — a 5-second AI response is often worse than no AI at all
|
||||
- Recommend starting with a human-in-the-loop design and automating only when accuracy is proven
|
||||
@@ -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,55 @@
|
||||
---
|
||||
name: experiment-designer
|
||||
description: Designs A/B tests from hypotheses and interprets experiment results
|
||||
with statistical rigour. Use when user says "run an experiment", "design an A/B
|
||||
test", "test this feature", "interpret these results", "was this experiment
|
||||
successful", or "what sample size do I need".
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: data-and-metrics
|
||||
tags: [experimentation, data, analytics, ab-testing]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Experiment Designer Skill
|
||||
|
||||
## Purpose
|
||||
Produce rigorous experiment designs from product hypotheses, and interpret
|
||||
results with statistical and practical significance — so you can defend every
|
||||
decision to a sceptical engineering lead or data scientist.
|
||||
|
||||
## Two-Phase Process
|
||||
|
||||
### Phase 1: Experiment Design
|
||||
**Required inputs:** hypothesis, primary metric, current baseline, minimum
|
||||
detectable effect (MDE), available sample size per day.
|
||||
|
||||
**Output:**
|
||||
- Hypothesis restated as: "If we [change], we expect [metric] to [move by X%]
|
||||
because [reason]"
|
||||
- Control and variant definitions
|
||||
- Primary metric (one only)
|
||||
- Secondary guardrail metrics (2-3 max)
|
||||
- Required sample size (calculated from MDE and baseline)
|
||||
- Estimated run time in days
|
||||
- Pre-defined success criteria (before the test runs — no moving goalposts)
|
||||
- Design risk flags: novelty effects, seasonal confounds, multiple testing issues,
|
||||
network effects, sample ratio mismatch risks
|
||||
|
||||
### Phase 2: Results Interpretation
|
||||
**Required inputs:** control results, variant results, p-value or raw numbers,
|
||||
run duration, any anomalies observed.
|
||||
|
||||
**Output:**
|
||||
- Statistical significance assessment (p < 0.05 threshold)
|
||||
- Practical significance: was the lift meaningful for the business, not just real?
|
||||
- Confidence interval interpretation
|
||||
- Confounding factors to investigate
|
||||
- Recommendation: Ship / Iterate / Kill / Run follow-up test
|
||||
- If "Iterate": specific hypotheses to test next
|
||||
|
||||
## Quality Checks
|
||||
- Never interpret results from an underpowered test without flagging it
|
||||
- Always distinguish statistical from practical significance
|
||||
- Flag if test was stopped early (peeking problem)
|
||||
- Note if sample ratio mismatch occurred
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
name: multi-source-signal-synthesiser
|
||||
description: Synthesises user signals from multiple research sources into a
|
||||
unified insight brief, reconciling conflicting feedback. Use when user has data
|
||||
from multiple sources, needs to "make sense of all this user data", "what are
|
||||
users really telling us", "synthesise our research", or has conflicting feedback
|
||||
from different channels.
|
||||
metadata:
|
||||
author: Mohit Aggarwal
|
||||
version: 1.0.0
|
||||
category: discovery
|
||||
tags: [user-research, synthesis, discovery, insights]
|
||||
documentation: https://github.com/mohitagw15856/pm-claude-skills
|
||||
---
|
||||
# Multi-Source Signal Synthesiser Skill
|
||||
|
||||
## Purpose
|
||||
Reconcile user signals from multiple sources — interviews, support tickets, NPS,
|
||||
app reviews, sales calls — into a unified, weighted insight brief that surfaces
|
||||
the underlying need rather than the surface-level request.
|
||||
|
||||
## Source Weighting (default — adapt to your context)
|
||||
- Direct research (interviews, usability tests): weight 5
|
||||
- Support tickets (unprompted pain signals): weight 4
|
||||
- NPS verbatims: weight 3
|
||||
- App store reviews: weight 2
|
||||
- Sales call summaries (filtered through sales lens): weight 2
|
||||
- Anecdote or single report: weight 1
|
||||
|
||||
## Process
|
||||
1. Accept inputs from any combination of the source types above
|
||||
2. Tag each signal by source and apply weight
|
||||
3. Look for CONVERGENCE: same underlying need appearing across 3+ sources
|
||||
4. Look for DIVERGENCE: contradictory signals suggesting user segmentation
|
||||
5. Distinguish surface request from underlying need
|
||||
(e.g. "faster export" may mean "I don't trust the data will be there when
|
||||
I need it")
|
||||
6. Produce ranked insights by weighted frequency
|
||||
|
||||
## Output Format
|
||||
|
||||
### User Signal Synthesis — [Date / Period]
|
||||
**Sources included:** [list]
|
||||
**Total signals processed:** [n]
|
||||
|
||||
#### Insight 1: [Underlying need, not feature request]
|
||||
- **Confidence:** High / Medium / Low (based on source diversity and weight)
|
||||
- **Evidence:** [Signals from each source supporting this]
|
||||
- **Conflicting signals:** [Any contradicting evidence and how to interpret it]
|
||||
- **Product implication:** [Specific, not generic]
|
||||
|
||||
[Repeat for top 3-5 insights]
|
||||
|
||||
#### Divergent Signals (Possible Segmentation)
|
||||
[Where user groups appear to have genuinely different needs]
|
||||
|
||||
#### What the Data Does NOT Tell Us
|
||||
[Gaps that require further research before acting]
|
||||
|
||||
## OpenClaw Configuration
|
||||
Connect to: Notion (research docs), support inbox, NPS tool, app review feed.
|
||||
Schedule: weekly synthesis run, diff output showing new signals only.
|
||||
Reference in New Issue
Block a user