Customer Research
Run attributed multi-source research before answering a customer, investigating a repeat bug, or pulling account-specific history for a support reply.
Overview
Customer Research is an agent skill most often used in Grow support (also Validate scope and Operate errors) that runs multi-source, attributed research on customer questions, bugs, and account history before you draft a
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill customer-researchWhat is this skill?
- Classifies requests into customer questions, issue investigations, account context, and topic research before searching
- Synthesizes findings from all connected sources with explicit attribution and confidence scoring
- Supports pre-draft background on whether a bug was reported before and what was told to a specific account
- Workflow starts with clarifying factual vs contextual questions to avoid noisy searches
- Integrates with knowledge-work CONNECTORS.md for which tools are available
Adoption & trust: 1.7k installs on skills.sh; 19.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a trustworthy answer for a customer or account question but the facts are scattered across tickets, docs, and past conversations with no clear sourcing.
Who is it for?
Indie SaaS or app founders who answer support themselves and already connect docs, email, or ticket tools to their agent.
Skip if: Builders who only need generic web search with no account context, attribution, or customer-support workflow—use a broad research skill instead.
When should I use this skill?
A customer asks something you need to look up, investigating whether a bug has been reported before, checking what was previously told to a specific account, or gathering background before drafting a response.
What do I get? / Deliverables
You get a synthesized briefing with attributed sources and confidence levels so you can draft or send a response without hallucinating policy, status, or prior commitments.
- Synthesized research summary with per-source attribution
- Confidence-scored findings aligned to the parsed request type
- Background brief ready for a customer-facing draft
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Grow because the skill is written for support and account-facing replies, even though the same workflow applies earlier when validating demand or operating on live tickets. Support is the primary trigger in the description—lookups, prior account context, and draft-ready synthesis for customer-facing answers.
Where it fits
A prospect’s feature question forces you to verify SSO or billing behavior across docs before committing on a landing-page promise.
A customer emails about webhook retries and you need best-practice background plus what your product actually supports.
A repeat outage report prompts a search for prior bug reports and known workarounds before you post a status update.
You prepare a renewal call by pulling what was promised to the account in earlier support threads.
How it compares
Use instead of pasting the question into chat once; this is a structured support-research ritual with request typing and source attribution, not a single-source lookup.
Common Questions / FAQ
Who is customer-research for?
Solo and indie builders who wear support and success hats and need verified, attributed answers before replying to customers or specific accounts.
When should I use customer-research?
During Grow when drafting support replies; during Validate when customer questions define scope; during Operate when checking if a bug was reported before or what you told an account last time.
Is customer-research safe to install?
Review what connectors the skill can reach via CONNECTORS.md and check the Security Audits panel on this Prism page before granting network or secrets access to production accounts.
SKILL.md
READMESKILL.md - Customer Research
# /customer-research > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Multi-source research on a customer question, product topic, or account-related inquiry. Synthesizes findings from all available sources with clear attribution and confidence scoring. ## Usage ``` /customer-research <question or topic> ``` ## Workflow ### 1. Parse the Research Request Identify what type of research is needed: - **Customer question**: Something a customer has asked that needs an answer (e.g., "Does our product support SSO with Okta?") - **Issue investigation**: Background on a reported problem (e.g., "Has this bug been reported before? What's the known workaround?") - **Account context**: History with a specific customer (e.g., "What did we tell Acme Corp last time they asked about this?") - **Topic research**: General topic relevant to support work (e.g., "Best practices for webhook retry logic") Before searching, clarify what you're actually trying to find: - Is this a factual question with a definitive answer? - Is this a contextual question requiring multiple perspectives? - Is this an exploratory question where the scope is still being defined? - Who is the audience for the answer (internal team, customer, leadership)? ### 2. Search Available Sources Search systematically through the source tiers below, adapting to what is connected. Don't stop at the first result — cross-reference across sources. **Tier 1 — Official Internal Sources (highest confidence):** - ~~knowledge base (if connected): product docs, runbooks, FAQs, policy documents - ~~cloud storage: internal documents, specs, guides, past research - Product roadmap (internal-facing): feature timelines, priorities **Tier 2 — Organizational Context:** - ~~CRM notes: account notes, activity history, previous answers, opportunity details - ~~support platform (if connected): previous resolutions, known issues, workarounds - Meeting notes: previous discussions, decisions, commitments **Tier 3 — Team Communications:** - ~~chat: search for the topic in relevant channels; check if teammates have discussed or answered this before - ~~email: search for previous correspondence on this topic - Calendar notes: meeting agendas and post-meeting notes **Tier 4 — External Sources:** - Web search: official documentation, blog posts, community forums - Public knowledge bases, help centers, release notes - Third-party documentation: integration partners, complementary tools **Tier 5 — Inferred or Analogical (use when direct sources don't yield answers):** - Similar situations: how similar questions were handled before - Analogous customers: what worked for comparable accounts - General best practices: industry standards and norms ### 3. Synthesize Findings Compile results into a structured research brief: ``` ## Research: [Question/Topic] ### Answer [Clear, direct answer to the question — lead with the bottom line] **Confidence:** [High / Medium / Low] [Explain what drives the confidence level] ### Key Findings **From [Source 1]:** - [Finding with specific detail] - [Finding with specific detail] **From [Source 2]:** - [Finding with specific detail] ### Context & Nuance [Any caveats, edge cases, or additional context that matters] ### Sources 1. [Source name/link] — [what it contributed] 2. [Source name/link] — [what it contributed] 3. [Source name/link] — [what it contributed] ### Gaps & Unknowns - [What couldn't be confirmed] - [What might need verification from a subject matter expert] ### Recommended Next Steps - [Action if