Skip to content
Back to skills

Researcher

ASecurity

Desk research on the web, filed as cited Evidence (never Signals) to fill gaps in a persona's data. Use on /researcher or when asked to find external reports/studies/data on a topic.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 19, 2026
researchgoawsgit

Security analysis

A100/100

Scanned September 19, 2026

npx -y skills add Pearl1531/Archetype-talk --skill researcher --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Researcher?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Researcher
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/pearl1531-researcher/badge)](https://www.skillsdirectory.com/skills/pearl1531-researcher)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: researcher
description: Desk research on the web, filed as cited Evidence (never Signals) to fill gaps in a persona's data. Use on /researcher or when asked to find external reports/studies/data on a topic.
---

# researcher — Desk Research Assistant (UX Researcher + Analyst)

On request, search the web for **existing desk research** — reports, studies, official statistics, community threads, journalism — that fills a gap in a persona's data. Cite properly, then turn findings into `Evidence/` files. This is the tool for "go find out if this is actually true" — it doesn't run interviews, it finds what's already published.

**Language:** work in the user's language; keep any quoted source text verbatim (don't translate a quote from a source — translate your own commentary around it).

## Trigger

```
/researcher <topic or question>
/researcher Personas/Emma.md                                  ← find desk research for gaps in her data
/researcher Personas/Emma.md "student music discovery habits" ← persona + a specific angle
```

Also invoked mid-conversation from `/persona-talk`, when a persona hits a **Known unknown** and the user explicitly agrees to a web-fallback offer — see persona-talk/SKILL.md's "Warm-up and unknowns" section. Same skill, same rules, just triggered from inside a session instead of run standalone.

**Real user research always outranks this.** Whatever this skill finds is desk research (Evidence), not an interview (Signal) — say so plainly whenever it's offered as a stand-in for a data gap: a real interview/test with an actual user is the stronger, preferred source, and finding something on the web doesn't close that gap, it only softens it temporarily.

## Competitor quick-research (app-added files)

A `Competitors/*.md` with `needs_research: true` was created by name in the app. When the user confirms (the SessionStart hook prompts you to ask), honor the **lookback window they chose — 1, 2 or 3 years back from today** — and skip sources published earlier. Fill the file's own template sections (Market position, Features vs the product, User voices, Sources) with linked public data; recent-first. Then set `retrieved: <today>` and delete the `needs_research:` line. The competitor file is opt-in context, not Evidence — file separate `Evidence/` entries only for findings that ground persona claims.

## Why this always produces Evidence, never Signal

This project's grounding model draws a hard line: **`Signal` = an observation from OUR OWN interview/test** (has an "Interview date" and a `Transcript` link back to a session we ran). **`Evidence` = desk research** — data someone else already published, that we found and cited. A community thread, a market report, an academic paper — no matter how compelling the quote inside it — is desk research, not our interview. Filing it as a `Signal` would silently inflate the Level scale (`Signal`-only = L3, "from experience") for something that was never actually witnessed firsthand. **Everything this skill produces is `Evidence`.**

## Workflow

1. **Scope the research.**
   - Given a persona file: read its `Pains`, `Jobs to be Done`, and `Correlations`. Identify claims that are thin — L2 (Evidence-only, no interview) or L3 (Signal-only, no external confirmation) — or gaps with no data at all.
   - Given free text: treat it as the research question directly.
   - If genuinely ambiguous, ask one clarifying question — don't guess at scope silently.

2. **Search.**
   - Use `WebSearch` broadly first, then `WebFetch` on the most promising, most authoritative pages.
   - Priority order: official statistics/company reports > academic papers > established journalism > community/forum threads (fully valid — this repo already cites Spotify Community threads throughout) > generic blogs (only if nothing better exists, and say so).
   - Cross-check a surprising number against a second source when one exists.

3. **Draft candidate Evidence entries.**
   - One `Evidence/<Title>.md` per distinct finding, using `Evidence/_template.md` exactly (Content → Takeaways → Sources), `retrieved:` = today.
   - **Never invent a statistic or quote to fill a thin result.** If the search comes up empty or weak, say so plainly instead of padding the file.

4. **Check for duplicates.**
   - Before creating a new file, scan `Evidence/` for an existing entry on the same topic. If one exists, prefer updating its `retrieved:` date and content over creating a near-duplicate.

5. **Present a plan, then confirm before writing.**
   - List candidates: title — one-line summary — source domain(s). Ask which to keep. Don't silently write a batch of files the user hasn't seen (same pattern as `dovetail-sync`).

6. **Write, then wire.**
   - Create the confirmed file(s).
   - If the research targeted a persona, offer to add a line under that persona's `## Evidences` section, linking the new file and stating what it confirms.
   - **If a finding contradicts an existing Pain/Correlation, flag it explicitly** rather than quietly overwriting — this repo's standing rule is that contradictions are data, not noise.

7. **Freshness is automatic at creation** (new Evidence starts at L2+ eligible with today's `retrieved:` date) — but this skill is also the right tool to periodically refresh Evidence the 3-month rule has flagged as stale.

## Target-population estimates (for the app's sample-confidence math)

When asked to find the size of the user's target population (total active accounts, subscribers in a segment, market size in people): use **public sources no older than 9 months** — investor reports, regulator filings, established market research; cite the specific page and date. File it as `Evidence/` like everything else, then tell the user the number and offer to enter it in the app's **Settings → Target population** (stored in the gitignored `.claude/preferences.local.md`). If only older data exists, say so plainly and mark it as needing refresh — never silently use a stale figure for confidence math.

## Rules

- Real, verifiable, linkable sources only — the same hard rule as the rest of this project. No fabricated statistics, no invented quotes, ever.
- Cite the specific page, not a bare domain.
- Prefer the primary source (the original study/report) over a secondary write-up when both are findable.
- A weak source is still worth including if it's the only one — just label it plainly ("only source found — treat as thin") rather than omitting the gap silently.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…