Research Repository

Use this when a team wants to make research findings reusable across projects and time. Without a repository, insights die in slide decks and Google Docs. This skill produces the structure for a research repository: taxonomy, tagging schema, nugget format, connection rules, and governance. It does not create the repository itself -- it creates the blueprint the team implements in their tool of choice (Notion, Dovetail, Airtable, or a shared drive).

Related skills: Uses the Research Nugget format from /interview-synthesis as the atomic unit of insight. Findings from /research-synthesize feed into the repository. /research-readout pulls from the repository when building stakeholder presentations. /research-prioritize uses the repository to surface what's already known before planning new research.

Process

Step 1: Gather inputs

Ask the user to provide:

1. Team size and roles -- who produces research? Who consumes it? (Researchers, PMs, designers, engineers, executives?)
2. Research volume -- how often does the team run studies? (Weekly, monthly, quarterly?) How many findings per study?
3. Current state -- where do insights live today? (Slide decks, Confluence, Notion, nowhere?) What's the main pain?
4. Tool preference -- what tool will house the repository? (Notion, Dovetail, Airtable, Google Sheets, Confluence, other?)
5. Products and domains -- what products, features, or user segments does the team research?
6. Existing personas -- does the team have defined personas or segments? (Link to /persona-draft output if available.)

Step 2: Design the taxonomy

The taxonomy defines how insights are organized so people can find them later. Design 3-5 facets:

## Research Repository Blueprint -- (Team/product, date)

### Taxonomy

| Facet | Purpose | Example values |
|---|---|---|
| Theme | What topic area does this insight belong to? | Onboarding, Checkout, Navigation, Trust, Pricing, Collaboration |
| Product area | Which part of the product does this relate to? | (Product-specific: Dashboard, Mobile app, API, Admin panel) |
| User segment | Which users does this apply to? | (Persona names or segments: New users, Power users, Enterprise admins) |
| Research method | How was this insight gathered? | Interview, Usability test, Survey, Analytics, Support tickets, Competitive analysis, Observational study / contextual inquiry |
| Confidence | How strong is the evidence? | Strong (3+ sources), Moderate (1-2 sources), Emerging (single signal) |

Taxonomy rules:

• 3-5 facets is the sweet spot. Fewer than 3 makes search too broad. More than 5 makes tagging too burdensome and people stop doing it.
• Every facet must answer a real question someone would ask when looking for insights: "What do we know about onboarding?" (theme), "What did enterprise users say?" (segment), "How confident are we?" (confidence).
• Facet values should be mutually exclusive within a facet but an insight can have multiple values across facets.
• Start with 5-8 values per facet. Let them grow organically rather than pre-defining every possible value.

Step 3: Define the nugget format

A research nugget is the atomic unit of insight. It must be small enough to reuse across contexts but rich enough to be meaningful on its own.

### Nugget format

Each nugget follows this structure (matching the /interview-synthesis Research Nuggets format):

| Field | Description | Example |
|---|---|---|
| Nugget ID | Unique identifier | NUG-2026-047 |
| Insight | One-sentence finding, stated as a fact | "New users don't understand what the product does until they complete their first project." |
| Quote | Verbatim participant quote that grounds the insight | "I signed up but I still didn't get it until I actually made something." |
| Interpretation | What this means for the product or business | This suggests onboarding should be task-oriented, not feature-touring. First-project completion is the activation metric. |
| Source | Study name, date, participant ID | Onboarding interviews, 2026-03, P04 |
| Tags | Taxonomy values | Theme: Onboarding; Segment: New users; Method: Interview; Confidence: Strong |
| Linked decisions | What product decisions this informed | Redesigned onboarding flow (Q2 2026), Activation metric change |
| Status | Current relevance | Active / Superseded / Archived |

### Nugget quality criteria
- **Insight must be falsifiable.** "Users want a better experience" is not a nugget. "Users abandon setup when asked for billing before seeing value" is.
- **Quote is mandatory.** No quote means no evidence. Use "[paraphrased]" only if verbatim wasn't captured.
- **One insight per nugget.** If a finding contains two distinct ideas, split into two nuggets.
- **Interpretation must include "so what."** Why should anyone care about this insight? What should change?

Step 4: Set connection rules

Insights gain value when connected to each other and to decisions. Define how nuggets relate:

### Connection rules

**Nugget-to-nugget connections:**
- **Supports:** Another nugget provides corroborating evidence from a different source or method
- **Contradicts:** Another nugget provides conflicting evidence (flag for further research)
- **Extends:** Another nugget adds nuance or context to this finding

**Nugget-to-artifact connections:**
- **Informed:** Links to product decisions, designs, or features this insight influenced
- **Sourced from:** Links to the full study report, synthesis doc, or readout
- **Referenced in:** Links to presentations, PRDs, or strategy docs that cited this insight

**Connection triggers:**
- When adding a new nugget, search existing nuggets for the same theme + segment combination. Flag potential supports/contradicts.
- When a product decision is made, link it to the nuggets that informed it.
- When a nugget is cited in a document, add a "Referenced in" connection.

**Contradiction protocol:**
When two nuggets contradict each other:
1. Note both with a "Contradicts" connection
2. Compare confidence levels and recency
3. If unresolved, flag as a research question for `/research-prioritize`

Step 5: Define governance

A repository without governance becomes a graveyard. Define who maintains it and how:

### Governance

**Contribution rules:**
| Who | Contributes what | When |
|---|---|---|
| Researcher / PM | New nuggets from studies | Within 1 week of study completion |
| Anyone | Nuggets from ad-hoc signals (support tickets, sales calls, analytics) | As encountered |
| Repository owner | Taxonomy updates, deduplication, archival | Monthly review |

**Quality review:**
- New nuggets reviewed by (role) within (timeframe) before marked Active
- Review checks: Is the insight falsifiable? Is the quote real? Are tags accurate? Is confidence rated honestly?

**Freshness rules:**
| Age | Action |
|---|---|
| < 6 months | Active -- cite freely |
| 6-12 months | Review -- still valid? Check against recent data |
| 12+ months | Archive candidate -- mark Archived unless revalidated |
| Superseded | Mark Superseded with link to newer nugget |

**Repository owner:** (Name/role -- one person accountable for repository health)
**Review cadence:** Monthly 30-min review to deduplicate, archive stale nuggets, update taxonomy
**Onboarding:** New team members get a 15-min walkthrough of the repository during onboarding

Step 6: Diagnose research adoption maturity

Before finalizing, use Churchill's research adoption lifecycle to diagnose where the organization stands. Most repositories fail at the awareness-to-understanding gap.

1. Awareness -- people know research exists
2. Understanding -- people can interpret it
3. Adoption -- people use it in decisions
4. Implementation -- it changes what gets built
5. Adaptation -- teams modify findings for their context
6. Appropriation -- the insight becomes organizational knowledge

Diagnostic question: "Where is your org on the research adoption lifecycle?" If the team is stuck at awareness, investing in taxonomy refinement is premature. Fix discoverability and communication first. If the team is at adoption, the repository design matters more because people are actively trying to find and use insights.

Step 7: Review and validate

Ask the user:

• Does the taxonomy match how your team actually asks questions? Try: "What do we know about (theme) for (segment)?" If the taxonomy answers that, it's working.
• Is the nugget format lightweight enough that people will actually fill it in? If it takes more than 5 minutes to write a nugget, it's too heavy.
• Who is the repository owner? Without a named owner, the repository will decay within 3 months.
• What's the minimum viable start? You don't need to backfill everything. Start with the next study and build forward.
• Where will this live? (Notion database, Dovetail, Airtable, spreadsheet?) The tool matters less than the habit.

Output location

Present the repository blueprint as formatted text in the conversation. The user copies it into their team documentation and uses it to configure their chosen tool.