{"id":42865,"plugin_id":"plugin_asdk_app_699e3e4e050881919b373090d3059dc5","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:07:35.473Z","digest":"1970894d3f2f1bae9d30b1f76e1ffd7a715163cf2b82b4ecf6a55dc0c8f17261","against":null,"payload":{"description":"Research BuildBetter data accurately through BuildBetter MCP. Use for open-ended questions about customer evidence, signals, support tickets, recordings, transcripts, survey responses, product analytics, people, companies, documents, knowledge pages, Projects Hub, or triage, and whenever an agent must choose reliable BuildBetter MCP read tools and return traceable evidence.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":236},{"relative_path":"references/mcp-tool-map.md","size_in_bytes":8073}],"name":"buildbetter-mcp-research","skill_md_contents":"---\nname: buildbetter-mcp-research\ndescription: Research BuildBetter data accurately through BuildBetter MCP. Use for open-ended questions about customer evidence, signals, support tickets, recordings, transcripts, survey responses, product analytics, people, companies, documents, knowledge pages, Projects Hub, or triage, and whenever an agent must choose reliable BuildBetter MCP read tools and return traceable evidence.\n---\n\n# BuildBetter MCP Research\n\nUse BuildBetter domain tools before GraphQL helpers. Use `run-query` only when discovery confirms that no domain tool expresses the request.\n\nRead `references/mcp-tool-map.md` when exact tool names, arguments, pagination rules, or multi-source examples are needed.\n\nFollow [buildbetter-start's interaction guidance](../buildbetter-start/SKILL.md#interaction) when choosing conversation, clarification, or optional visual output.\n\nThis skill adds reusable routing and evidence discipline over the MCP's general-purpose read tools. It does not replace MCP behavior or encode a tenant's taxonomy. Feature-scoped and mutating workflows route to dedicated skills when those skills and their tools are available.\n\n## Research Workflow\n\n1. Translate the question into a retrieval plan: evidence source, organization-specific metadata, filters, time range, and the minimum detail needed to answer.\n2. Discover before guessing. List configured signal types, tags, properties, project types, or GraphQL fields when the request depends on them.\n3. Choose the narrowest domain tool. Use aggregate tools for totals or distributions, search/list tools for candidate discovery, and detail tools for exact evidence.\n4. Start with a stable page of 20 to 40 results unless the user requests an export. Keep filters unchanged while paging.\n5. Inspect returned IDs, dates, boundaries, people, companies, source kinds, types, and truncation metadata before synthesizing.\n6. Deepen only the best candidates with call, transcript, document, knowledge-page, or project detail tools.\n7. Answer with the scope searched, evidence identifiers, findings, and material coverage limitations. Never imply that unqueried sources were searched.\n\n## Routing\n\n- Recordings, including calls and interviews: `search-calls` -> `get-call` -> `get-call-transcript`. These established tool names are compatibility names; a meeting and its recording remain distinct.\n- Evidence across imported support, feedback, survey, and recording sources: `search-signals` for fast discovery; `list-extractions` for exact filters.\n- Counts, trends, and distributions: `aggregate-signals`, `aggregate-extractions`, or `aggregate-signals-by-tags` before listing every row.\n- Connected product usage: `list-analytics-projects` -> `query-analytics-data`, or `get-analytics-insight` for an existing chart/insight. Use advertised schemas and actual event names; retain provider, connection, project, timezone, timeframe, and truncation.\n- Explicit visual browsing or curation of individual items: `open-evidence-browser` when advertised and supported by the client. The agent selects relevant evidence for ordinary research and comparison through domain read tools without opening the browser.\n- User-requested monitoring: hand off to `buildbetter-start` and the client's discovered MCP Events workflow; keep this research retrieval read-only.\n- Direct customer evidence: use `buildbetter-customer-voice` when installed.\n- Synthetic persona profiles, panels, studies, and chats: use `buildbetter-synthetic-research` when installed.\n- Native survey authoring, delivery, intercepts, and responses: use `buildbetter-survey-research` when installed.\n- Smart Tag drafting, evaluation, publishing, and backfills: use `buildbetter-smart-tags` when installed.\n- People and accounts: `search-people`; use `search-people-properties` for CRM or integration attributes.\n- Documents and knowledge: `search-documents` -> `get-document`; `search-knowledge-pages` or `list-knowledge-pages` -> `get-knowledge-page`.\n- Exact folder contents: `get-folder`.\n- Projects and triage: `list-project-types`, `list-projects`, `get-project`, `triage-count`, `list-triage-items`, `get-triage-item`. When the user asks for active work context, search promoted projects and triage separately.\n- Project and Linear promotion workflows: use `buildbetter-project-triage` when installed.\n- Knowledge-gap review, attachments, rechecks, and release readiness: use `buildbetter-knowledge-gaps` when installed.\n\n## Reliability Rules\n\n- If authentication or organization context fails, ask the user to connect BuildBetter MCP. Do not substitute guessed data.\n- Prefer exact public IDs. Prefer email addresses over names when identifying a known person.\n- Treat organization taxonomies as dynamic. Discover signal types, tags, and properties instead of assuming another account's names or meanings.\n- Treat boundary labels as retrieval hints, not proof of customer identity. Verify returned people and companies before describing evidence as direct customer voice.\n- Treat `phrase` as literal matching. Combine it with discovered structured types, tags, or `list-extractions` filters when exact scope matters. Do not use the OAuth-only `query` argument in this universal workflow.\n- Use a continuation key only for the next page of the identical query. Drop it when any phrase, type, call, persona, tag, or filter changes.\n- If a filter appears ineffective, compare returned IDs and verify with `list-extractions`; report the limitation rather than claiming the result was narrowed.\n- Establish recurrence from signal, call, person, and company evidence. Do not rely on project or triage `customerCount` fields when attached evidence is sparse or contradictory.\n- Distinguish an empty verified result from missing permissions, truncated coverage, unsupported filters, or a failed request.\n- Treat an unavailable feature flag or disconnected integration as an unavailable surface, not an empty result.\n- Keep this research 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: sources, filters, dates, limits, pages, and organization metadata used.\n- Findings: concise conclusions ordered by evidence strength.\n- Evidence: stable signal, call, document, or project identifiers with dates and people/companies when available.\n- Caveats: truncation, sparse coverage, ambiguous identity, internal-versus-external ambiguity, permission gaps, or filter anomalies.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}