---
name: customer-discovery
description: Turn raw customer feedback (GitHub issues or a CSV export) into a ranked, evidence-backed list of product opportunities, and draft PRDs from the top ones. Use when the user wants to know what to build next, has a backlog of feedback to triage, or asks to prioritize feature requests.
---

# Customer discovery with FeedbackLens

## Workflow

1. **Load feedback.** Ask which source to use:
   - A public GitHub repo (`owner/name`) → `import_github_issues`
   - A CSV export → `import_csv` (a file path, or paste the CSV text directly)
   - No data on hand yet → `load_sample` (bundled synthetic demo dataset)

2. **Get the ranked opportunities.** Call `top_opportunities` (default top 5). Each result has
   a `themeId`, a `label`, a `score` (0-100), a `breakdown` of the four scoring factors, and a
   short quote.

3. **Pull the full evidence.** For any theme worth writing about, call `get_evidence` with its
   `themeId` to get the supporting quotes, links, reaction counts, and dates. Never state a
   pain point without a quote to back it — that is the whole point of this tool.

4. **Cross-check with search.** Use `search_feedback` to see whether a specific complaint shows
   up in items outside the top themes, or to sanity-check a theme's boundaries.

5. **Share the findings.**
   - `generate_report` renders the top opportunities as a ready-to-share Markdown report.
   - For a specific opportunity, draft a PRD by hand using the evidence you pulled: Problem,
     Evidence (quotes + links), Users affected, Proposed solution, Success metrics,
     Risks/open questions.

## How to read the scores

See `references/scoring.md` for the scoring model in plain words. The short version: a higher
score means the theme is mentioned more often, by more upset users, more recently, with more
engagement (votes/reactions) — not any one of those alone.

## Rules

- Every claim needs a quote. If you can't find one, say so instead of guessing.
- Never surface or repeat author-identifying information (names, emails, GitHub handles,
  avatars) — FeedbackLens already strips it; don't try to work around that by, e.g., fetching
  the original issue yourself.
- Keep language plain and PM-friendly. No "TF-IDF", "keyword clustering", or similar jargon in
  anything written for the user.