Clean Interviews

Clean Interviews

Processes user interviews in ~/obsidian/Research/User interviews/, standardizes their format, adds tags, and aggregates insights into the research dashboard.

When to Use

• After conducting user interviews
• When interview files need standardization
• To aggregate interview insights across projects
• When preparing interview data for analysis

Workflow

1. Scan Interview Files

Find all interview files:

find ~/obsidian/Research/User\ interviews -name "*.md" -type f

Note the directory structure - interviews are organized by project (e.g., Project-A/, Project-B/).

2. Read Current Dashboard

cat ~/obsidian/research-dashboard.md

Check if "User Interview Insights" section exists.

3. Process Each Interview File

For each interview file:

a) Read the file to understand current content b) Add YAML frontmatter if missing:

---
tags:
  - interview
  - [project-name]
interviewee: Name
date: YYYY-MM-DD
project: Project Name
signal: strong | moderate | weak
action-items:
  - "Intro to [Contact] at [Company]"
  - "Follow up on [specific topic]"
---

Note: action-items is optional - only include if there are genuinely important actions from this interview. See "Action Item Criteria" section below.

c) Restructure content into standard sections:

## Summary
One-paragraph synthesis of the interview

## Key Insights
- Bullet points of main takeaways

## Pain Points
- Problems the interviewee faces

## Quotes
> Direct quotes worth preserving

## Follow-ups
- Action items or questions for next time

d) Preserve original content - reorganize, don't delete

4. Determine Signal Strength

Apply these criteria:

Strong Signal:

• Explicit willingness/commitment ("I would definitely use this")
• Quantified usage metrics specific to their domain
• Current paid solution they would switch from
• Specific problems that match our solution

Moderate Signal:

• Interest expressed but conditional
• Some relevant problems, some not
• Unclear on willingness to pay or switch
• General positive sentiment without commitment

Weak Signal:

• Polite interest but no clear need
• Problems do not align with our solution
• Low usage/engagement in relevant areas
• Blockers (jurisdiction, technical, organizational)

5. Archive Dashboard (if updating)

If dashboard will be updated, run archive first:

bash ~/.claude/scripts/archive-dashboard.sh

6. Aggregate Interview Insights

Count interviews by:

• Project (directory name)
• Signal strength

Summarize key takeaways per project.

7. Update Research Dashboard

Add or update "User Interview Insights" section after "Latest Research Documents":

## User Interview Insights
**Total Interviews:** X | **Strong:** Y | **Moderate:** Z | **Weak:** W

### By Project
- **Project-A:** X interviews - [key aggregated takeaway]
- **Project-B:** X interviews - [key aggregated takeaway]

### Recent Interviews
- [[Research/User interviews/Project-A/Jane Doe|Jane Doe]] - Strong, target user interested in product

8. Verify

• All interview files have YAML frontmatter
• All files have standard sections
• Dashboard has interview insights section
• Tags work in Obsidian (#interview)

Interview Template

When processing interviews, structure them as:

---
tags:
  - interview
  - project-a
interviewee: Jane Doe
date: 2026-01-15
project: Project-A
signal: strong
---

## Summary
One-paragraph synthesis capturing who they are, what they need, and key signals.

## Key Insights
- Insight 1
- Insight 2

## Pain Points
- Pain point 1
- Pain point 2

## Quotes
> "Direct quote that captures something important"

## Follow-ups
- Action item or question

Action Item Criteria

Action items in frontmatter are for genuinely important tasks that should surface on the daily dashboard. Most interviews won't have any.

Include (Important - Surface to Dashboard)

• Introductions: "Can intro to [Person] at [Company]" - warm intros are high-value
• Follow-up calls/meetings: Scheduled or promised follow-ups with the interviewee
• Partner/vendor investigation: Specific companies or tools mentioned worth investigating
• Critical product decisions: Feature requests that came with strong signal and affect architecture
• Urgent blockers: Regulatory, legal, or technical issues that need immediate attention

Exclude (Keep in Follow-ups Section Only)

• General "look into X" observations
• Minor UX suggestions
• Feature ideas without strong signal
• Vague "might be interesting" items
• Things already on the roadmap
• Research that's nice-to-have, not blocking

Examples

Include:

action-items:
  - "Intro to [Partner] (via [Contact]) - partner opportunity"
  - "Investigate [Vendor] integration for risk management"
  - "Follow-up call with [Contact] re: [Feature] threshold feature"

Don't Include:

• "Think about rewards structure" (too vague)
• "Consider better FX handling" (product backlog, not action item)
• "Research stETH safety" (general research, not urgent)

Rule of Thumb

Ask: "Would I forget this and regret it?" If yes, it's an action item. If it's just useful context, leave it in the Follow-ups section only.

Signal Tagging Guidelines

Strong

• Explicit "I would use this" or "I would pay for this"
• Currently using competitors and unhappy
• Quantified spending patterns (monthly card spend, holdings)
• Clear problem-solution fit

Moderate

• "This sounds interesting" without commitment
• Some problems align, others don't
• Unclear on pricing sensitivity
• Would need to see it working first

Weak

• Polite but non-committal
• Problems don't match solution
• Jurisdiction/regulatory blockers
• Low target market fit (small spender, no crypto holdings)

Important Notes

• Preserve original content - restructure, don't delete information
• Be conservative with signal strength - default to moderate if unclear
• Use project directory name as the project tag (lowercase)
• Date format: YYYY-MM-DD (ISO 8601)
• Link format: Obsidian wikilinks with display text

Paths Reference

• Interview root: ~/obsidian/Research/User interviews/
• Dashboard: ~/obsidian/research-dashboard.md
• Archive script: ~/.claude/scripts/archive-dashboard.sh

Note: Paths can be customized in ~/.claude/config/paths.env

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: GregTheGreek
• Source: GregTheGreek/claude-obsidian
• License: MIT

Install and usage instructions live in the source repository linked above.