Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/research-decision-room
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
The product/design decision the team needs to make
📊 Stats
Stars80,924
Forks9,350
LanguageTypeScript
LicenseApache-2.0
📦 Ships with open-design
</> SKILL.md
research-decision-room.SKILL.md
---name: research-decision-room
description: |
Turn messy user research notes, interviews, support tickets, surveys, and product
context into an evidence-backed decision room: a single HTML artifact with an
evidence ledger, theme map, confidence heatmap, opportunity matrix, decision
memo, and experiment queue. Use when teams need to move from qualitative
signals to product or design decisions without fabricating certainty.
triggers:
- "research decision room"
- "user research synthesis"
- "research synthesis dashboard"
- "evidence-backed product decision"
- "interview synthesis"
- "opportunity solution tree"
- "usability findings dashboard"
- "qualitative research board"
od:
mode: prototype
platform: desktop
scenario: research
preview:
type: html
entry: index.html
reload: debounce-100
design_system:
requires: true
sections: [color, typography, layout, components]
craft:
requires: [typography, color, accessibility-baseline, anti-ai-slop]
inputs:
- name: research_material
type: string
description: "Interview notes, tickets, survey excerpts, analytics notes, or a product decision brief"
- name: decision_scope
type: string
required: false
description: "The product/design decision the team needs to make"
outputs:
primary: index.html
example_prompt: "Synthesize 8 interview notes, 24 support tickets, and recent activation metrics into a research decision room for whether a project-management app should add an onboarding checklist or contextual inline tips."
capabilities_required:
- file_write
---
# Research Decision Room Skill
Create a single-page HTML decision artifact that helps a product or design team
turn messy evidence into a clear next move. The output is not a decorative
research deck. It is a working room for debate: evidence, themes, confidence,
tradeoffs, and recommended experiments stay visible together.
## Resource map
```text
research-decision-room/
├── SKILL.md
├── example.html
└── references/
├── checklist.md
└── evidence-model.md
```
Read `references/evidence-model.md` before synthesis and run
`references/checklist.md` before emitting the artifact.
## When to use this skill
Use this skill when the user has any mix of:
- Interview notes, usability-test observations, support tickets, sales call notes,
app-store reviews, NPS comments, survey open text, analytics snippets, or
product-decision context.
- A decision that needs evidence: "Should we build X?", "Which onboarding path
should we try?", "Why are users dropping off?", "What do customers actually
mean by slow?"
- A need to share findings with stakeholders who will not read a long research
report.
Do not use it for pure visual inspiration, campaign ideation, or brand moodboards.
## Workflow
### Step 1 - Establish the decision frame
Identify the decision scope from the user's prompt. If the user did not give a
decision, derive one from the evidence and label it as inferred.
Write a short frame with:
- Decision question.
- Audience or segment.
- Time horizon.
- Known constraints.
- What this artifact will not decide.
If key context is missing and the task is not blocked, proceed with labelled
assumptions instead of asking a broad question.
### Step 2 - Build the evidence ledger
Normalize every useful signal into ledger rows using the model in
`references/evidence-model.md`.
Each ledger row must include:
- `id`: short stable id, such as `I-03`, `T-14`, `M-02`.
- `source_type`: interview, usability, support, survey, analytics, sales, field
note, or stakeholder.
- `segment`: user type or "unknown".
- `signal`: one-sentence observation.
- `quote_or_metric`: direct quote, metric, or "not provided".
- `strength`: strong, medium, or weak.
- `limitations`: why this evidence may be biased or incomplete.
Never invent quotes, participant counts, dates, revenue impact, or metrics. If
the user did not provide a number, use "not provided" and explain what evidence
would increase confidence.
### Step 3 - Synthesize themes and tensions
Cluster evidence into 4 to 6 themes. For each theme:
- Name the theme in plain human language.
- List the evidence ids that support it.
- Explain the behavior behind it, not just the UI complaint.
- Mark confidence as high, medium, or low.
- Note contradictions or segment differences.
Prefer verbs over nouns: "Teams abandon setup when the first blank state asks
for too much" is better than "Onboarding problem".
### Step 4 - Score opportunities
Create an opportunity matrix with 3 to 5 options. Score each option on a 1 to 5
scale:
- Evidence strength.
- User pain.
- Business leverage.
- Implementation risk, where 5 means low risk and 1 means high risk.
Show the total score, but do not let the score replace judgment. Add one sentence
on why the top recommendation wins.
### Step 5 - Draft the decision memo
Write a decision memo with:
1. Recommended move.
2. Why now.
3. What evidence supports it.
4. What could be wrong.
5. What to measure next.
6. Reversible next step.
Keep the memo short enough to read in under one minute.
### Step 6 - Create the HTML artifact
Produce a self-contained `index.html`. Use the active `DESIGN.md` for typography,
spacing, color roles, and component tone, but keep the information architecture
stable:
1. Header with decision question, confidence, and last-updated label.
2. Executive readout with recommendation, risk, and next experiment.
3. Evidence ledger with filter chips.
4. Theme map with evidence ids and confidence.
5. Opportunity matrix.
6. Decision memo.
7. Experiment queue with owner, metric, and success threshold.
8. Assumptions and limitations.
The artifact should be interactive but durable. Simple vanilla JavaScript is
allowed for filtering evidence, switching views, or highlighting related ids.
No framework dependency is required.
### Step 7 - Self-check and emit
Run the checklist. Then emit one concise orientation sentence and one HTML
