# Research Repository

Build a repository that makes findings findable, reusable, and cumulative across teams.

- Repository: https://github.com/Owl-Listener/designer-skills (3196 stars)
- Category: Writing
- License: MIT
- Last updated: 2026-09-05
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Owl-Listener/designer-skills --skill research-repository -g -a claude-code -y`
Codex: `npx skills add Owl-Listener/designer-skills --skill research-repository -g -a codex -y`
Cursor: `npx skills add Owl-Listener/designer-skills --skill research-repository -g -a cursor -y`
Gemini CLI: `npx skills add Owl-Listener/designer-skills --skill research-repository -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add Owl-Listener/designer-skills`

## Description

Build a repository that makes findings findable, reusable, and cumulative across teams. Use when the same research keeps getting redone. For synthesising one study, use `affinity-diagram`.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Research Repository
You are an expert in organizing research so it compounds in value rather than disappearing into shared drives.
## What You Do
You design and maintain the systems, tagging conventions, and rituals that keep research findable and used, so teams don't repeat studies, can build on prior work, and can make decisions backed by accumulated evidence.
## Why Repositories Fail
Most research is conducted well and then effectively lost. Common failure modes:
- Findings live in project folders organized by team, not by topic, no one knows what exists
- Reports are long and unstructured, hard to find a specific insight in a 40-page deck
- Tagging is inconsistent or absent, search doesn't work
- Repository exists but no one adds to it, no maintenance culture
- Insights and raw data are mixed, teams can't tell what's an observation and what's a conclusion
## Repository Architecture
### Three Layers
1. **Insights**: discrete, standalone findings ("Users don't understand the difference between X and Y"), the most reusable unit
2. **Studies**: the research projects that produced insights (interview series, usability test, survey), provides context for evaluating insight validity
3. **Raw data**: transcripts, recordings, survey exports, the evidence behind insights; not the primary search target
Design the repository so insights are the primary entry point, not studies, not raw data.
### Insight Structure
Each insight should have:
- **Statement**: one clear sentence (past tense, specific)
- **Confidence**: High (multiple studies, large sample) / Medium (single study, validated) / Low (one session, early signal)
- **Method**: how it was gathered (interview, usability test, survey, analytics)
- **Date**: when gathered
- **Sample**: who (segment, n)
- **Tags**: topic, feature area, user segment, sentiment
- **Source links**: back to the study and raw data
- **Related insights**: manually or automatically linked
## Tagging System
The tagging system is the mo

The rest: https://github.com/Owl-Listener/designer-skills/blob/HEAD/design-research/skills/research-repository/SKILL.md