# Customer Insights Skills Research customers, build evidence-backed account briefs, inspect PDFs, improve customer-facing content, and review drafts through stakeholder lenses. Use for customer research, account planning, sales content, proposals, RFP responses, DDQs, and security questionnaires in any industry. This file is the Agent Skills standard package flattened for clients that take instructions rather than a Skill folder. Keep workflow files in Instructions. Upload business source documents and optional assets as Knowledge only when needed. ## SKILL.md # Customer Insights Skills Use the smallest workflow that satisfies the request. Preserve Claim IDs and evidence status whenever work moves between workflows. ## Start with the user's context Confirm the user's business, offering, target organisation, intended deliverable, jurisdiction, and available authorised sources. Ask only for missing details that materially affect the result. Do not assume the user is a software vendor, proposal team, workforce business, or AutoRFP.ai customer. Treat provided fields and examples as adaptable defaults: omit irrelevant fields and add industry-specific fields while preserving the evidence rules. If the user asks to use only supplied facts, do not delay the deliverable with questions. Mark relevant omissions as `Not provided` and list them as open gaps. ## Select a workflow - Create an account brief from authorised facts: read [Customer Brief Setup](references/customer-brief-setup.md). - Discover sources for this offering and write a full trust-classified research report in one run: read [External Sources](references/external-sources.md). - Research account gaps and buyer priorities: read [Customer Brief Research](references/customer-brief-research.md). - Build precise public-source discovery queries: read [Build Google Dork](references/build-google-dork.md). - Find and annotate evidence in supplied PDFs: read [PDF Insight Finder](references/pdf-insight-finder.md). - Rewrite a response with verified customer insight: read [Response Insight Enricher](references/response-insight-enricher.md). - Review a draft through named buyer-role lenses: read [Evaluator Review](references/evaluator-review.md). For multi-stage work, follow [the integrated workflow](references/WORKFLOW.md). Use [the shared handoff schema](references/HANDOFF_SCHEMA.md) for every intermediate artifact. For installation and platform-specific fallbacks, read [Platform Setup](references/PLATFORM_SETUP.md). ## Evidence rules - Map every material claim to a source and Claim ID. - Treat search results as leads until their underlying sources are validated. - Mark unsupported statements as `Needs evidence`; never present them as facts. - Mark explicit user or authorised internal facts as `Provided` unless independently verified. - Mark invented content in fictional or hypothetical scenarios as `Illustrative`; never present it as verified evidence. - Retain dates, qualifiers, geographies, sample sizes, and units. - Use only public or authorised material and keep relationship information professional and relevant. If browsing is unavailable, return a research plan, discovery queries, and evidence gaps instead of unsupported findings. If file creation is unavailable, return each requested artifact inline under its specified filename. ## Included resources - `assets/Customer-Brief-Research-Worksheet.docx`: editable research worksheet. - `scripts/annotate_pdf.py`: optionally creates colour-coded PDF highlights from an exact-text manifest. - `scripts/requirements.txt`: optional PDF annotation dependency. If code execution or PyMuPDF is unavailable, complete the research and evidence ledger, provide the exact-text annotation manifest, and clearly state that the annotated PDF was not generated. Never block the remaining workflow on optional tooling. ## Build Google Dork Source: `references/build-google-dork.md` # Build Google Dork Consume the organisation aliases, jurisdictions, document types, and open evidence gaps from Customer Brief Research or the source log in `external-source-report.md`. Produce `public-discovery-queries.md` with three to six labelled, copy-ready queries. ## Defaults Use `site:`, `filetype:`, quoted phrases, `OR`, and exclusions only when they improve precision. Prefer official and government sources. ```text Official reports site:organisation.example ("annual report" OR "impact report" OR strategy) (filetype:pdf OR filetype:xlsx) Topic signals "Organisation Name" ("Primary topic" OR "Related term") (filetype:pdf OR filetype:xlsx) ``` Replace every placeholder and choose terms that fit the user's industry, organisation type, language, and jurisdiction. Do not assume workforce management, software, or a commercial company. ## Boundary Use only publicly indexed business, regulatory, or academic material. Do not search for credentials, exposed secrets, personal data, private systems, or access-control bypasses. Search results are leads only: External Sources or Customer Brief Research must validate them before they become evidence. ## Customer Brief Research Source: `references/customer-brief-research.md` # Customer Brief Research Consume `customer-brief.md`; create `research-pack.md`; and use [the editable worksheet](../assets/Customer-Brief-Research-Worksheet.docx) as the structured work surface. ## Workflow 1. If `external-source-report.md` is present, start from its verified claims, buyer language, and open gaps. Otherwise start with sources appropriate to the organisation type and jurisdiction: official websites, reports, filings, regulators, government records, product documentation, newsroom material, or authorised internal sources. 2. Log direct URLs, exact findings, supported brief field, Claim ID, source type, confidence, and status. 3. Identify three to seven relevant priorities in the organisation's own language, plus document search terms. 4. Mark unsupported facts as `Needs evidence` and unknown fields as `Not provided`. 5. Record open evidence gaps. Use Build Google Dork only to generate public discovery leads; validate those leads before logging them as evidence. 6. Adapt the worksheet headings to the user's business and complete its five-bullet summary. If browsing is unavailable, do not invent research findings. Produce a source plan, copy-ready discovery queries, and open evidence gaps for later validation. ## Handoff Send verified claims and search terms to PDF Insight Finder; source-backed context to Response Insight Enricher; and unresolved evidence gaps to Build Google Dork. ## Customer Brief Setup Source: `references/customer-brief-setup.md` # Customer Brief Setup Create `customer-brief.md` from user-supplied or authorised internal information. ## Default sections - Account context - Business relevance: need, use case, alternatives or competition, and measurable value - Stakeholders and professional relationships: role context and relevant references - Operational and commercial context: relevant scale, spend, growth, constraints, or delivery model - Decision criteria and success measures - Open gaps Adapt these sections to the user's industry and objective. Omit a default field when it is irrelevant and add domain-specific fields when they affect the decision or deliverable. For every material fact, retain its source, owner, Claim ID, and status. Mark explicit prompt or authorised internal facts as `Provided`; use `Not provided` for relevant missing information. In fictional scenarios, label invented examples `Illustrative`. Never infer relationships, buying authority, budget, competition, or customer facts. Keep relationship information professional, authorised, and relevant. ## Handoff Send the brief and open public gaps to External Sources or Customer Brief Research. Send verified account context to PDF Insight Finder, Response Insight Enricher, and Evaluator Review. ## Evaluator Review Source: `references/evaluator-review.md` # Evaluator Review Consume the draft or `response-insight-pack.md`, relevant evidence maps, and named evaluator or stakeholder roles. Produce `review-backlog.md`. ## Light research Use up to four strong public sources per evaluator: official leadership bios, investor materials, newsroom, product documentation, or public talks. Record: ```text Name and role: [name / role] Publicly supported priorities: [facts with links] Role-informed criteria: [clearly labelled inference] ``` Do not claim to be the person, know their private views, or infer personal preferences from sparse information. If browsing is unavailable, use only supplied role information, label role-based criteria as inference, and list research gaps instead of inventing public priorities. ## Review Read only what is on the page. For each material issue, quote the draft, cite its Claim ID or `Needs evidence`, explain why it fails the role lens, and give the smallest concrete fix. Cover missing evidence, audience relevance, unsupported claims, implementation or operational risk, security or scale concerns, compliance, or strategy mismatch when relevant. Return at most five corrections per evaluator, each labelled Critical, High, or Medium. End with `Proceed`, `Proceed with revisions`, or `Not ready` and one reason. Send evidence gaps to Customer Brief Research and re-review only changed sections. ## External Sources Source: `references/external-sources.md` # External Sources In one run, discover the right public sources for this offering, search them, and write the full trust-classified research report. Produce `external-source-report.md`. Do not stop after listing sources or queries. Do not deliver a source map as the result. Sources are a working step. The report is the deliverable: trustworthy research, buyer language, falsifiable facts and stats, and strategic priorities, each classified by trust. ## Start with context Confirm the target organisation, the user's offering (the vendor and problem they sell), the intended deliverable, and the jurisdiction. Ask only for missing details that change what would count as proof. If the user supplies authorised vendor facts (their own figures, case studies, or product claims), record them as `Provided`. Do not present them as independently verified. Do not assume the industry, the offering, or a fixed second set of sources. Learn the high-signal sources from this run. ## Discover sources, then use them immediately Work in two layers: common sources that ground any organisation, then high-signal sources you infer from this offering. As soon as a source is named, search it. Do not wait for a complete catalogue. ### Common sources Use these as a starting lens for foundational facts. They are not the output. #### Website Look for company values, history, and scale. Prefer the official site, about pages, and current leadership or location pages. #### Investor Center Look for annual reports, investor presentations, and statistics. Prefer investor relations, filings, and official results pages. Keep figures with dates, geographies, and units. #### Job Ads Look for objectives, areas of focus, and locations of focus. Prefer current careers pages and official job posts. Treat ads as signals of priority, not as proof of a live programme. #### News Look for legal and financial issues, brand damage, and initiatives. Prefer the organisation newsroom, named outlets, and dated official statements. Separate the organisation's own announcement from third-party commentary. ### High-signal sources Infer these from the offering. They are the sources most likely to surface this organisation's real pains rather than generic industry trends. Do not reuse a remembered industry list. Derive the set now: 1. State the category of pain the offering addresses, in one sentence, using the user's words. 2. Name the official registers, regulators, courts or tribunals, statutory reports, industry bodies, and buyer-side forums that publish proof of that pain in this jurisdiction. 3. Add authorised operating documents or contracts only when the user supplied them. Do not hunt for leaked internal files. 4. Search those sources against this organisation. Keep a source only if it returns material here. Drop the rest. 5. If a promising class of record exists but nothing is found, log it as an open gap. Do not invent the finding. A useful high-signal source is official or statutory, specific to the offering's problem, and checkable. Reviews and forums are signals until a primary source corroborates them. ### Example only The cards below show the method for a workforce-management offering such as Workforce.com. Use them only when the user's offering is actually about workforce, payroll, HR, or employment. Do not copy them onto any other deal. - Employment court cases: underpayments, specific legal risks, penalties or enforcements. Prefer official court, tribunal, or regulator records in the named jurisdiction. - Wage equality reporting: employee type breakdown, headcount growth, wage cost details. Prefer statutory pay-gap or equivalent public reports. - Glassdoor reviews: key employee issues, opportunities, what is already working. Quote clusters, not single unverified posts. - Employee handbooks (user-supplied only): day to day workflow, systems and processes, values and communication channels. - Employment agreements (user-supplied only): applicable processes and laws, complexities, risks. For a payments vendor the same method might surface regulator enforcement, scheme rules, and outage reports. For a cyber vendor it might surface breach notifications and assurance filings. Name the equivalents for this offering yourself. ## Search and write in the same run For each source you kept, write one to three precise queries, run them if browsing is available, open the underlying pages or documents, and log the direct URL. Prefer official domains, `site:`, quoted phrases, `OR`, `filetype:pdf`, and exclusions only when they tighten the result. ```text Website site:organisation.example (about OR values OR "our story" OR leadership) Investor Center site:organisation.example ("annual report" OR "investor presentation" OR "full year") (filetype:pdf OR filetype:xlsx) Job Ads site:organisation.example (careers OR jobs) ("we are looking" OR "you will" OR "this role") News "Organisation Name" (investigation OR lawsuit OR "regulatory" OR initiative OR "strategic priority") ``` Build high-signal queries from the sources you just inferred. Point them at the regulator, register, statutory report, or buyer-side forum that applies. Replace every placeholder with this organisation's aliases, language, and jurisdiction. Search results stay leads until you open the source and record a locator. Then keep going: classify the finding and place it in the report. Do not pause to hand the user a query list. If browsing is unavailable, still write the report. Mark findings `Needs evidence`, list the queries you would run, and leave those items as open gaps. Do not invent URLs, case names, quotes, or figures. For extra query precision on remaining public gaps, Build Google Dork can refine them later. Do not delay the report for that step. ## Classify by trust, then extract the foundation Compare the same claim across source types. Classify every material finding. Then write the foundation sections from those classified findings. Do not write generic industry commentary. ### Trust bands Use these bands in the source log. They sit on top of the shared evidence contract (`Claim ID`, source type, confidence, status). | Band | What qualifies | Typical status | |---|---|---| | Official | Filings, statutory reports, court or regulator records, the organisation newsroom, the official website | `Verified` when the locator supports the scoped claim | | Corroborated | Two or more independent source types agree on the same scoped fact | `Verified` | | Independent | A named outlet, analyst, or third-party report that cites a primary source | `Verified` only after the primary source is checked; otherwise `Needs evidence` | | Signal | Job ads, review-site clusters, a single news item, or an undated deck | Lead; quote as a signal, not as proof of a live programme | | Unverified | A single comment, an undated claim, or no locator | `Needs evidence`; never present as fact | Cross-check rules: - An official first-party figure with a date, geography, and unit can be `Verified` from that one official source. - Interpretive claims (pains, priorities, culture, risk) need a second source type before you call them `Verified`. - When sources disagree, keep both wordings, record the conflict, and do not pick a winner. - Review sites and job ads never graduate past Signal on their own. - Retain dates, qualifiers, geographies, sample sizes, and units. Do not widen a claim. ### Foundation extracts These sections are the report. Write them from classified findings, not from general knowledge. #### Trustworthy Research Use only Official or Corroborated findings about this organisation's real pains, constraints, and initiatives. Speak to what they are dealing with, not generic industry trends. Each bullet needs a Claim ID and a locator. #### Buyer Language Quote phrases the organisation uses for itself: values, role language, strategy labels, and how they describe the problem. Prefer wording that appears more than once. Cite the source. The aim is to speak as a peer already working with them, not as an outsider. Do not invent voice. #### Falsifiable Facts and Stats List dated, scoped figures you can check. Include their numbers from official sources and, when the user supplied them, the vendor's own numbers as `Provided`. Trust sits in the details (year, unit, geography, sample), not in generalities. Never invent a statistic. #### Strategic Priorities List three to seven priorities in the organisation's own language. Tie each to a source and a trust band. Job-ad objectives and investor themes are signals until an official strategy document or results commentary corroborates them. Also capture, when the sources support them: risks, opportunities, and what is already working. Keep those labelled with their trust band. ## Output Write the full report in this run as `external-source-report.md`: ```markdown # External Source Report: [Organisation] ## Trustworthy research ## Buyer language ## Falsifiable facts and stats ## Strategic priorities ## Source log ## Open evidence gaps ``` The source log uses the shared evidence table plus a Trust band column. It supports the extracts. It is not a substitute for them. If file creation is unavailable, return the same report inline under that filename. ## Boundary Use only public or authorised material. Do not search for credentials, personal data, private systems, or access-control bypasses. Review sites, news, and job ads stay leads until the underlying source is validated. ## Handoff The report is the handoff. Send verified claims, buyer language, and priorities to Customer Brief Research and Response Insight Enricher. Send remaining public gaps to Build Google Dork. Send supplied PDFs to PDF Insight Finder. ## HANDOFF SCHEMA Source: `references/HANDOFF_SCHEMA.md` # Shared Handoff Schema Use these filenames and sections so every skill can pick up the prior work without re-researching it. ## `customer-brief.md` ```markdown # Customer Brief: [Organisation] ## Account context ## Business relevance ## Stakeholders and professional relationships ## Operational and commercial context ## Decision criteria and success measures ## Open gaps ``` Adapt or omit subsections to fit the user's business and objective. Keep the title, evidence references, and open gaps consistent for downstream workflows. ## `external-source-report.md` ```markdown # External Source Report: [Organisation] ## Trustworthy research ## Buyer language ## Falsifiable facts and stats ## Strategic priorities ## Source log ## Open evidence gaps ``` ## `research-pack.md` ```markdown # Research Pack: [Organisation] ## Official sources ## Research themes and search terms ## Source log ## Verified claims ## Open evidence gaps ``` ## `public-discovery-queries.md` ```markdown # Public Discovery Queries: [Organisation / Topic] ## Official and regulatory sources ## Topic-specific queries ## Results requiring validation ``` ## `pdf-evidence-ledger.md` ```markdown # PDF Evidence Ledger: [Organisation / Topic] ## Highlighted evidence ## Claim table ## Risks, opportunities, and quantified facts ``` ## `response-insight-pack.md` ```markdown # Response Insight Pack: [Question] ## Draft diagnosis ## Enriched response ## Claim-to-evidence map ## Open gaps ``` ## `review-backlog.md` ```markdown # Evaluator Review Backlog: [Draft] ## Evaluator lenses ## Prioritised corrections ## Required evidence changes ## Re-review scope ``` Reference `Claim ID` and status values from the shared evidence contract in every source log, response evidence map, and review correction. ## Pdf Insight Finder Source: `references/pdf-insight-finder.md` # PDF Insight Finder Use the supplied customer brief and research pack as a relevance lens. Create an annotated copy of the PDF and a `pdf-evidence-ledger.md`. ## Workflow 1. Search the PDF for the stated topic, researched themes, and brief priorities. 2. Highlight only exact, self-contained excerpts that the PDF supports: - Blue: falsifiable figures, statistics, dates, targets, or measured results. - Red: business risks, constraints, cost pressure, compliance exposure, or adverse outcomes. - Green: opportunities, investments, growth levers, or strategic initiatives. 3. Record each material highlight with Claim ID, exact quote, physical page, category, source type, confidence, and status (`Verified` or `Needs evidence`). 4. When annotation tools are available, render and inspect annotated pages before handoff. Preserve the original unless replacement is explicitly requested. 5. Return the annotated PDF when generated and at most five bullets on the strongest evidence, risks, opportunities, and numbers. ## Evidence rule Research guides what to look for; it never proves a claim in the PDF. Retain all qualifiers, dates, geographies, and units. Do not highlight generic boilerplate or keyword matches without a meaningful claim. ## Script Run `scripts/annotate_pdf.py` when Python 3, local file access, and PyMuPDF are available. It accepts an exact-text JSON manifest with `page`, `category` (`stat`, `risk`, `opportunity`), and `text`; it fails if an excerpt cannot be found. If the script or PDF editing is unavailable, still produce `pdf-evidence-ledger.md` and the exact-text JSON manifest. State that annotation was not generated and do not imply that a PDF was modified. ## PLATFORM SETUP Source: `references/PLATFORM_SETUP.md` # Platform Setup The core research, writing, and review workflows are model-independent. File installation and code execution vary by product. ## Package the skill Download or clone the repository, then package the `customer-insights-skills/` directory itself. The archive must retain that directory as its single top-level folder. macOS or Linux: ```bash zip -r customer-insights-skills.zip customer-insights-skills -x "*.DS_Store" ``` Windows PowerShell: ```powershell Compress-Archive -Path customer-insights-skills -DestinationPath customer-insights-skills.zip ``` ## Claude - **claude.ai:** Upload `customer-insights-skills.zip` from Customize > Skills. Custom Skills and code execution must be available for the account. - **Claude Code:** Copy the directory to `~/.claude/skills/customer-insights-skills/` or `.claude/skills/customer-insights-skills/`. - **Claude API:** Upload the package through the Skills API and attach the returned skill ID to a code-execution container. Hosted environments may not allow package installation or network access. If PyMuPDF is unavailable, use the PDF workflow's evidence-ledger fallback. ## Gemini - **Gemini Agents / Antigravity:** Mount the directory at `.agents/skills/customer-insights-skills/`. - **Gemini app / Gems:** Paste the body of `SKILL.md` and the contents of each required workflow file from `references/` into the Gem instructions. Upload business source documents and the worksheet as Knowledge only when needed. Gemini Gems treat these files as instructions rather than a natively installed Agent Skill. Do not rely on relative links to load behavioral files. If the instruction limit is reached, include only the workflows needed for that Gem or use Gemini Agents. Do not expect `scripts/annotate_pdf.py` to run unless the chosen environment provides code execution and PyMuPDF. ## ChatGPT - **ChatGPT Skills:** On an eligible workspace, create or upload a Skill from the Skills page and select this package. - **Without Skills access:** Paste the body of `SKILL.md` and the contents of each required workflow file from `references/` into the custom GPT or Project instructions. Upload business source documents and the worksheet as Knowledge only when needed. Behavioral workflow files must be included in Instructions; do not upload them only as Knowledge or rely on package-relative links. If the instruction limit is reached, include only the required workflows or use native ChatGPT Skills. Script execution depends on the selected surface and workspace policy. Use the evidence-ledger fallback when local files or PyMuPDF are unavailable. ## Smoke test After installation, prompt: > Create a customer brief for a fictional bicycle manufacturer entering the French market. Use only the facts in my prompt, mark missing information as Not provided, and list the evidence gaps to research. A correct installation should select Customer Brief Setup, avoid software or RFP-specific assumptions, preserve missing fields, and produce a sourced brief structure. ## Response Insight Enricher Source: `references/response-insight-enricher.md` # Response Insight Enricher Consume the target reader's question or draft, `customer-brief.md`, `research-pack.md`, `pdf-evidence-ledger.md`, and `external-source-report.md` when present. Produce `response-insight-pack.md`. ## Review and rewrite Diagnose only material issues: audience language missing, unverifiable claim, generic wording, strategy mismatch, or unsupported insight. Then rewrite the answer directly, using the target reader's documented language and success measures. - Map every material claim to a `Verified` or `Provided` Claim ID and source; never describe a `Provided` claim as independently verified. - Preserve scope, qualifiers, and units. - Use a qualified capability statement when proof is unavailable. - Never fabricate account facts, product capabilities, outcomes, competitor claims, or financial extrapolations. ## Output 1. Draft diagnosis: up to four bullets. 2. Enriched response: ready to use and no longer than the original unless supported detail is necessary. 3. Claim-to-evidence map: Claim ID, source, and status, or `Needs evidence`. 4. Open gaps: only facts needed to improve the answer. Send wording changes to Evaluator Review and missing facts to Customer Brief Research. ## WORKFLOW Source: `references/WORKFLOW.md` # Customer Insight Workflow Use these workflows as a connected, evidence-preserving system. Run only the stages the request needs, adapt fields to the user's business, and preserve the handoffs whenever a downstream stage is used. | Order | Skill | Consumes | Produces | Next use | |---:|---|---|---|---| | 1 | Customer Brief Setup | Authorised account inputs | `customer-brief.md` + open gaps | External sources, research, enrichment, evaluator review | | 2 | External Sources | Target organisation, offering, jurisdiction | `external-source-report.md` | Research, dork building, response enrichment | | 3 | Customer Brief Research | Brief + evidence gaps + external-source report when present | Updated brief, source log, research themes | Dork building, PDF insight finding | | 4 | Build Google Dork | Research gaps, organisation aliases, jurisdictions, source log | `public-discovery-queries.md` | External Sources or Research validates resulting sources | | 5 | PDF Insight Finder | Brief, research themes, verified PDFs | Annotated PDF + `pdf-evidence-ledger.md` | Response enrichment and evaluator review | | 6 | Response Insight Enricher | Buyer question/draft + brief + evidence ledger | `response-insight-pack.md` | Evaluator review | | 7 | Evaluator Review | Enriched response + evidence map + role lenses | `review-backlog.md` | Revise response, update gaps, then re-review | ## Evidence contract Every material statement that moves between stages must have a record in the shared evidence ledger: ```markdown | Claim ID | Claim / exact quote | Source | Locator | Source type | Confidence | Status | |---|---|---|---|---|---|---| | C-001 | [exact wording] | [title / URL / user prompt] | [page, section, or quote] | User supplied / Internal approved / PDF primary / Official public / Independent / Illustrative | High / Medium / Low | Provided / Verified / Needs evidence / Illustrative | ``` - `Verified` means the source supports the claim at the stated scope. - `Provided` means the user or an authorised internal source explicitly supplied the fact; it is not independently verified. - `Needs evidence` must never become a factual claim in an enriched response. - `Illustrative` is only for fictional or hypothetical content and must never be presented as verified evidence. - A Google result is a lead, not a source, until Research records and checks it. - Retain qualifiers, dates, geographies, sample sizes, and units; do not widen a claim during handoff. ## Revision loop Evaluator Review sends only evidence-backed changes to Response Insight Enricher. If a correction reveals a missing account fact, route it to Customer Brief Research. If it needs a public document, route it to Build Google Dork and then back to Research for validation. Re-run the evaluator only on the changed response. ## Final delivery Deliver the requested asset plus only the relevant supporting handoffs: a concise customer brief, source/evidence log, annotated PDF, enriched response, and/or prioritised review backlog. Do not expose internal working notes unless requested.