{"id":42863,"plugin_id":"plugin_asdk_app_699e3e4e050881919b373090d3059dc5","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:07:35.439Z","digest":"f72061118f606320d994b054577ce910d1057720a5aab9ff28263cb40096f181","against":null,"payload":{"description":"Retrieve defensible customer-voice evidence from BuildBetter MCP. Use when researching customer complaints, objections, praise, feature requests, needs, themes, exact quotes, account feedback, or changes over time, especially when direct external statements must be separated from internal commentary and supported with traceable signal or call evidence.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":232}],"name":"buildbetter-customer-voice","skill_md_contents":"---\nname: buildbetter-customer-voice\ndescription: Retrieve defensible customer-voice evidence from BuildBetter MCP. Use when researching customer complaints, objections, praise, feature requests, needs, themes, exact quotes, account feedback, or changes over time, especially when direct external statements must be separated from internal commentary and supported with traceable signal or call evidence.\n---\n\n# BuildBetter Customer Voice\n\nFollow [buildbetter-start’s interaction guidance](../buildbetter-start/SKILL.md#interaction): complete supported work through chat; use optional UI only when it reduces effort or clarifies a decision.\n\nUse BuildBetter as an evidence layer. Separate direct customer statements from internal interpretations, and preserve enough scope and identifiers for another researcher to reproduce the result.\n\nThis skill composes the general-purpose read tools shipped on the current MCP surface. It does not replace MCP behavior, encode a tenant's taxonomy, or depend on feature-gated domains and mutation workflows.\n\nUse `buildbetter-mcp-research` instead when the request primarily concerns internal documents, Projects Hub, or triage rather than customer evidence.\n\n## Evidence Standard\n\nRank evidence in this order:\n\n1. Transcript text from an identified external speaker.\n2. A signal's `exactQuote` with an external person boundary and unambiguous speaker attribution.\n3. A signal summary, clearly labeled as a paraphrase.\n4. Internal commentary, clearly separated as context rather than customer voice.\n\nNever turn a summary into a quotation. If identity, boundary, or speaker attribution is missing, mark the evidence unverified and do not silently count it as direct customer voice.\n\n## Workflow\n\n1. Define the population, product area, source set, time window, and whether the user wants direct external evidence, internal interpretation, or both. For a relative window, default to a rolling UTC interval with an exclusive end and state the exact timestamps.\n2. Discover the organization's current taxonomy. Start with `get-list-extractions-schema` and `list-signal-types`; search `list-extraction-tags` with a targeted term and bounded limit. Use `list-signal-properties` plus `search-signal-property-values` only when a custom dimension matters. Use `list-extraction-filter-fields` only when source metadata is needed. Do not assume names or meanings from another organization.\n3. Establish coverage with `aggregate-signals`, `aggregate-extractions`, or `aggregate-signals-by-tags`. Prefer unique calls, people, and companies over raw signal counts when discussing prevalence, and treat grouped type counts as overlapping when a signal can have multiple types.\n4. Retrieve a bounded evidence set with `list-extractions`, using the same structured filter as the aggregate query. Start with 20 to 40 rows and omit `page` for stable keyset traversal. Send only the returned continuation key on each later request.\n5. Inspect boundaries, dates, source kinds, call IDs, people, companies, types, and truncation metadata. Exclude rows with a missing person or unverified boundary from direct-voice evidence even if the structured external filter returned them. Deduplicate repeated signals from the same call before drawing conclusions.\n6. Deepen only representative evidence with `get-call` and, when needed, `get-call-transcript`. Verify the transcript before quoting when `exactQuote` contains multiple speakers or unclear attribution. Sample across leading themes, companies, dates, and viewpoints rather than selecting only the newest calls.\n7. Synthesize conclusions in proportion to evidence strength. Report sparse, conflicting, permission-limited, or truncated coverage explicitly.\n\n## Retrieval Patterns\n\n- Known call: `get-call` -> `get-call-transcript` when exact context is required.\n- Find relevant calls: `search-calls` -> `get-call` -> optional transcript.\n- Cross-call themes: aggregate external signals -> `list-extractions` -> selected calls/transcripts.\n- Fast exploration: `search-signals`; verify candidates with structured `list-extractions` before making exact-scope claims.\n- Account or person feedback: resolve identity with `search-people`, preferring an exact email, then filter calls and signals.\n\nFor direct customer evidence, use an explicit external-boundary filter and discovered taxonomy fields:\n\n```json\n{\n  \"where\": {\n    \"AND\": [\n      { \"person\": { \"boundary\": { \"eq\": \"external\" } } },\n      { \"date\": { \"gte\": \"<START_ISO>\", \"lt\": \"<END_ISO>\" } },\n      { \"<SCHEMA_SUPPORTED_FIELD>\": { \"<OPERATOR>\": \"<DISCOVERED_VALUE>\" } }\n    ]\n  },\n  \"select\": [\"id\", \"sourceKind\", \"summary\", \"context\", \"exactQuote\", \"date\", \"types\", \"person\", \"company\", \"data\"],\n  \"orderBy\": [[\"date\", \"desc\"]],\n  \"limit\": 40\n}\n```\n\nReplace the placeholder field, operator, and value with a clause supported by the live schema. If no reliable topic/type/tag exists, use a schema-supported content predicate or a literal `phrase` search and disclose the weaker filter. If a server version rejects omission of `page`, fall back to unchanged numbered pages and disclose the weaker pagination contract.\n\n## Reliability Rules\n\n- Treat signal types, tags, topics, and custom properties as organization-specific. Discover them and inspect sample results before relying on their semantics.\n- An `external` boundary does not prove that a person is a current customer. Inspect available person, account, persona, or lifecycle metadata; separate prospects, partners, and advisors when identifiable. If customer status cannot be verified, describe the population as external people rather than customers.\n- Search tags with a targeted term and bounded limit, following its continuation key only when more taxonomy coverage is needed. A zero tag count means no visible extractions are currently attached to that tag; it does not prove that the underlying feedback is absent.\n- When using `tagIds`, pass the public UUID returned by `list-extraction-tags`; do not reuse numeric tag IDs embedded in extraction rows.\n- Resolve relevant custom-property values with `search-signal-property-values`; do not infer hierarchy nodes from a property definition alone.\n- Treat `phrase` as literal matching. Combine it with discovered structured types/tags or use `list-extractions`; do not use the OAuth-only `query` argument in this universal workflow.\n- Use continuation keys only for the next page of an unchanged search. Restart pagination after changing any filter.\n- Treat continuation keys as opaque, short-lived traversal state rather than durable citations. Cite stable signal and call IDs in the answer.\n- Compare raw signal counts with unique call and company counts. Multiple extractions from one conversation do not represent multiple independent customers.\n- Treat grouped type totals as non-additive unless the live schema guarantees mutually exclusive groups.\n- An `exactQuote` may contain both sides of a dialogue. Quote only the clearly attributed customer fragment, using the transcript to verify ambiguous speaker boundaries.\n- Distinguish absence of evidence from verified absence. Empty results may reflect permissions, source exclusions, unsupported filters, truncation, or ingestion gaps.\n- Minimize unnecessary personal data. Include names, emails, or account details only when required to answer the request.\n- Keep this customer-voice workflow read-only. Do not call tools annotated as mutating; hand off to an explicit mutation workflow only after user approval.\n\n## Output Contract\n\nReturn:\n\n- Scope: population, boundary rule, dates, sources, taxonomy, filters, pages, and coverage counts.\n- Findings: concise themes ordered by directness, prevalence, and recency.\n- Evidence: exact quotes only when supported, otherwise labeled paraphrases; include stable signal/call IDs, dates, and companies when useful.\n- Counterevidence: meaningful disagreement or examples that weaken a theme.\n- Caveats: sparse coverage, duplication, missing identity/boundary, permissions, truncation, ingestion gaps, or weak filters.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}