菜单
Diagnostic-first user research for support conversations and feedback analysis. Reaches Level 3 (user goal) before investigating or fixing. Applies The Mom Test methodology to extract product insights from bug reports and feature requests.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Capture point-in-time MER (MiDi Experience Record) for a wallet — data state, visual screenshot, perception context, and decision metadata.
Compare user expectations (UTCs) with code reality to identify gaps. Use when you need to understand discrepancies between what users expect and what code actually does.
Batch scan canvases for GAP sections, deduplicate, route to correct repos, draft issue bodies, and file confirmed issues.
Parallel multi-user processing using Claude Code native teams. Leader spawns workers per user, each runs /ingest-dm, leader aggregates for cross-canvas patterns.
Validate gap hypotheses by manually simulating features for individual users and measuring commitment, not satisfaction.
Automated end-to-end feedback pipeline that pulls new Supabase entries, enriches, classifies, routes to canvases, and generates a synthesis report.
| name | level-3-diagnostic |
| description | Diagnostic-first user research for support conversations and feedback analysis. Reaches Level 3 (user goal) before investigating or fixing. Applies The Mom Test methodology to extract product insights from bug reports and feature requests. |
| author | THJ |
| version | 1.0.0 |
| triggers | ["user feedback","bug report","support conversation","discord message","telegram message","feature request","user complaint"] |
This skill transforms support conversations into product intelligence. Instead of the traditional report → investigate → fix loop, it inserts a diagnostic step that ensures you're solving the right problem.
Traditional: Report → Investigate → Fix → Ship
Level 3: Report → Diagnose → Scope → Fix → Validate → Ship
| Level | Question | Output |
|---|---|---|
| Level 1 | What's broken? | A fix |
| Level 2 | Why did they expect it differently? | Better fix |
| Level 3 | What were they trying to accomplish? | Right fix + product insight |
Always start at Level 3. The answer scopes your entire investigation.
This skill activates when:
If funds are at risk or system is down, fix first. For UX friction and expectation gaps, ask first.
Before interpreting any user quotes or forming hypotheses:
grimoires/keeper/glossary.yamlterm field)meaning field as the canonical interpretationnot field to explicitly avoid the common misinterpretation[glossary: {term}] annotation in the diagnostic outputUser reports something. Resist the urge to investigate.
INPUT: "Claim button still disabled hours after claim"
Ask the goal question:
"What were you trying to do when you noticed this?"
Wait for response. Do not proceed until you have it.
If user mentions specific expectations (numbers, timing, behavior):
"Where does [specific expectation] come from? Did you see that somewhere?"
| Source | Implication |
|---|---|
| "Your docs" | Promise broken — fix system or docs |
| "That's how [competitor] works" | Benchmark — product decision needed |
| "Just assumed" | Expectation gap — set correct expectation |
| "Someone told me" | Community misinformation — clarify |
| "Pure imagination" | No external source — low priority unless common |
Before building, verify the need isn't already met:
"[Feature] shows this — is it not updating for you, or is it something else you need?"
| Response | Problem Type |
|---|---|
| "Didn't know that existed" | Discoverability |
| "I see it but it hasn't changed" | Actual bug |
| "I see it but don't trust it" | Confidence gap |
| "I need history, not current" | Feature gap |
| "Hard to find" | UX/platform issue |
Now you know:
Investigation is scoped. You're looking at the right thing.
Fix addresses the actual need, not just the surface report.
Before shipping, confirm the fix addresses the Level 3 goal:
"You mentioned you were [goal]. Does this solve that for you?"
Update grimoires/artisan/observations/user-insights.md with:
| Instead of... | Ask... |
|---|---|
| "Thanks, we'll look into it" | "What were you trying to do right before you noticed this?" |
| "Can you reproduce it?" | "Walk me through what happened" |
| "Is it still happening?" | "What did you try after you saw this?" |
| "Works on my end" | "Where does that expectation come from?" |
When users mention specific numbers or behaviors:
"Where does [specific expectation] come from?
Did you see that somewhere or is that how other protocols work for you?"
When users reveal they check something regularly:
"What makes you check? Just habit or looking for something specific?"
| Trigger | Implication |
|---|---|
| Habit/routine | Engagement ritual built |
| Anxiety/trust check | Need confidence signal |
| Decision point | Watching for threshold to act |
| Boredom | Low signal |
"[Feature] shows this — is it not updating for you,
or is it something else you need?"
| Signal | User Type | Key Question |
|---|---|---|
| Mentions specific workflow (burns, compounds) | Decision-maker | "What info do you need to make that call?" |
| Thinks about tradeoffs, system design | Builder-minded | "Have you tried building something like this?" |
| Checks frequently, "just curious" | Trust-checker | "What would make you confident it's working?" |
| Reports multiple issues across channels | High-engagement scout | "What were you hoping to find?" |
| Left funds untouched for months | True passive user | "What made you come check today?" |
Decision-makers are highest priority — they have workflow dependencies on your product.
❌ Spend 2 hours on button logic → "Works on my end" ✅ Ask what they were trying to do → 30-second scoping → targeted investigation
❌ User: "Just curious" → Move on ✅ User: "Just curious" → "What would make you confident without checking?"
❌ "Our sidebar shows that — have you tried it?" ✅ "What info do you need to make that decision?" → then check if sidebar provides it
❌ "Is this a bug or feature request?" ✅ "What were you trying to accomplish?" → classification emerges from answer
After each diagnostic conversation, update the insights log:
## [Date] | [User/Channel]
### Level 3 Goal
[What were they actually trying to accomplish]
### User Type
[Decision-maker / Builder-minded / Trust-checker / Passive]
### Behavioral Evidence
- [What they actually did]
- [Workarounds they built]
- [Time/money invested]
### Expectation Gap
| Expected | Actual | Source |
|----------|--------|--------|
| [their expectation] | [system behavior] | [where it came from] |
### Workflow Dependency
[If they depend on product for decisions, what do they need?]
### Action Items
- [ ] [Specific action with context]
Common Expectation Gaps:
Key Questions:
/craftIf user feedback drives a UI change, diagnose first:
/craft with full contextIf diagnosis reveals a recurring pattern:
If the fix is obvious and takes 2 minutes:
Fix time: 2 minutes
Question time: 30 seconds
Potential insight: Shapes what you build next
Rule: Ask, then fix. The fix is the same either way, but you might learn something.
User: "Claim button still disabled (hours after claims too)
if finks it normaly should update every 5min max no?"
--- WRONG RESPONSE ---
"Let me check the button logic..."
[2 hours debugging]
"Works on our end"
--- LEVEL 3 RESPONSE ---
Team: "What were you trying to do when you noticed?"
Team: "Where does the 5min come from? Did you find this somewhere?"
User: "for this it's just pure imagination but:
- as a user it's more fun to see wallet growing
- as a dev it's no gud cuz it augment number of hits"
--- INSIGHT CAPTURED ---
- Expectation was invented (not from docs/competitor)
- User thinks like a builder (aware of tradeoffs)
- Real need: "fun to see wallet growing" (confidence/delight signal)
- Action: Consider "last updated" timestamp, set explicit expectation in docs
resources/templates/insights-log.md — Template for logging user insightsresources/templates/diagnostic-conversation.md — Conversation flow template