{"id":10116,"plugin_id":"plugin_asdk_app_6a83176bebfc819187076994aba78396","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T22:56:26.438Z","digest":"36234d46f2af42fe0e8ecd8097b820fcdb90278e37a64141d4fbaa7906706e33","against":null,"payload":{"description":"Produce concise source-grounded briefs, memos, and partner/customer prep notes from Partnership Leaders MCP findings with clear evidence, caveats, and follow-up questions.","included_files":[],"name":"pl-source-grounded-brief","skill_md_contents":"---\nname: pl-source-grounded-brief\ndescription: Produce concise source-grounded briefs, memos, and partner/customer prep notes from Partnership Leaders MCP findings with clear evidence, caveats, and follow-up questions.\n---\n\n# Partnership Leaders Source-Grounded Brief\n\nUse this skill when a user asks for a brief, memo, customer prep note, executive summary, or point of view based on Partnership Leaders research. Assume the reader is a senior partnership leader who wants a judgment they can act on or put in a slide, backed by named companies, dates, and figures.\n\nBriefing rules:\n\n- Use the MCP server to gather evidence before drafting.\n- Prioritize high-signal findings by tier, recency, and relevance to the user's question.\n- Lead with the judgment a partner executive would repeat, not a description of what the brief covers.\n- Surface notable companies, competitors, and adjacent ecosystem players when the user asks a broad question.\n- If the prompt names a company, center that company and use one or two named peers only when evidence supports the comparison.\n- Treat `insight_si`, `ec75`, and `aip` as internal routing only. Do not expose dataset names, significance labels, cadence, coverage notes, or provenance footers in the final answer unless the user asks an admin/testing question.\n- Use finding ids and source URLs to verify claims before writing.\n- Keep recommendations clearly labeled as interpretation.\n- Preserve uncertainty when evidence is mixed or limited.\n- Copy program names, dates, and figures from returned records; do not rely on memory.\n- Use day-level dates only when the returned records carry them.\n- Include cross-company synthesis when supported, but make every count auditable by naming each company in the count.\n- Count vendors and programs separately, and do not include announced future programs in counts of completed changes.\n- Cover what got harder or was tightened, not only what launched.\n\nSuggested brief structure:\n\n- Start with the executive judgment.\n- Explain why it matters for partner strategy.\n- Support the judgment with named companies, dates, and figures.\n- Include competitive or ecosystem implications when evidence supports them.\n- Close with a specific action for the reader.\n\nStyle:\n\n- Write continuous analyst prose and format sparingly.\n- Use bullets only for four or more genuinely parallel items.\n- Avoid bolded label ladders, formula closers, numbered signposts, and generic consulting language such as \"robust\", \"seamless\", \"landscape\", \"leverage\", and \"game-changing\".\n- Do not invent prior rules or prior regimes just to make a change look bigger.\n- Use at most one superlative per answer, and only when the evidence names what it beats.\n\nSecurity and privacy:\n\n- Never ask the user to paste secrets, API keys, OAuth tokens, or private partner records into chat.\n- Treat access control as server-side. The MCP server decides which rows the user can see.\n- If a requested answer appears to require data outside the user's entitled scope, state that the server did not return enough evidence.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}