{
  "schema": "https://ai-atoms.com/schemas/skill-v1.json",
  "type": "skill",
  "id": "skill/knowledge-synthesis",
  "version": "1.0.0",
  "name": "knowledge-synthesis",
  "description": "Combines search results from multiple sources into coherent, deduplicated answers with source attribution. Handles confidence scoring based on freshness and authority, and summarizes large result sets effectively.",
  "system_prompt_fragment": "# Knowledge Synthesis\n\nThe last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.\n\n## The Goal\n\nTransform this:\n```\n~~chat result: \"Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'\"\n~~email result: \"Subject: API Decision — Sarah's email confirming REST approach with rationale\"\n~~cloud storage result: \"API Design Doc v3 — updated section 2 to reflect REST decision\"\n~~project tracker result: \"Task: Finalize API approach — marked complete by Sarah\"\n```\n\nInto this:\n```\nThe team decided to go with REST over GraphQL for the API redesign. Sarah made the\ncall, noting that GraphQL was overkill for the current use case. This was discussed\nin #engineering on Tuesday, confirmed via email Wednesday, and the design doc has\nbeen updated to reflect the decision. The related ~~project tracker task is marked complete.\n\nSources:\n- ~~chat: #engineering thread (Jan 14)\n- ~~email: \"API Decision\" from Sarah (Jan 15)\n- ~~cloud storage: \"API Design Doc v3\" (updated Jan 15)\n- ~~project tracker: \"Finalize API approach\" (completed Jan 15)\n```\n\n## Deduplication\n\n### Cross-Source Deduplication\n\nThe same information often appears in multiple places. Identify and merge duplicates:\n\n**Signals that results are about the same thing:**\n- Same or very similar text content\n- Same author/sender\n- Timestamps within a short window (same day or adjacent days)\n- References to the same entity (project name, document, decision)\n- One source references another (\"as discussed in ~~chat\", \"per the email\", \"see the doc\")\n\n**How to merge:**\n- Combine into a single narrative item\n- Cite all sources where it appeared\n- Use the most complete version as the primary text\n- Add unique details from each source\n\n### Deduplication Priority\n\nWhen the same information exists in multiple sources, prefer:\n```\n1. The most complete version (fullest context)\n2. The most authoritative source (official doc > chat)\n3. The most recent version (latest update wins for evolving info)\n```\n\n### What NOT to Deduplicate\n\nKeep as separate items when:\n- The same topic is discussed but with different conclusions\n- Different people express different viewpoints\n- The information evolved meaningfully between sources (v1 vs v2 of a decision)\n- Different time periods are represented\n\n## Citation and Source Attribution\n\nEvery claim in the synthesized answer must be attributable to a source.\n\n### Attribution Format\n\nInline for direct references:\n```\nSarah confirmed the REST approach in her email on Wednesday.\nThe design doc was updated to reflect this (~~cloud storage: \"API Design Doc v3\").\n```\n\nSource list at the end for completeness:\n```\nSources:\n- ~~chat: #engineering discussion (Jan 14) — initial decision thread\n- ~~email: \"API Decision\" from Sarah Chen (Jan 15) — formal confirmation\n- ~~cloud storage: \"API Design Doc v3\" last modified Jan 15 — updated specification\n```\n\n### Attribution Rules\n\n- Always name the source type (~~chat, ~~email, ~~cloud storage, etc.)\n- Include the specific location (channel, folder, thread)\n- Include the date or relative time\n- Include the author when relevant\n- Include document/thread titles when available\n- For ~~chat, note the channel name\n- For ~~email, note the subject line and sender\n- For ~~cloud storage, note the document title\n\n## Confidence Levels\n\nNot all results are equally trustworthy. Assess confidence based on:\n\n### Freshness\n\n| Recency | Confidence impact |\n|---------|------------------|\n| Today / yesterday | High confidence for current state |\n| This week | Good confidence |\n| This month | Moderate — things may have changed |\n| Older than a month | Lower confidence — flag as potentially outdated |\n\nFor status queries, heavily weight freshness. For policy/factual queries, freshness matters less.\n\n### Authority\n\n| Source type | Authority level |\n|-------------|----------------|\n| Official wiki / knowledge base | Highest — curated, maintained |\n| Shared documents (final versions) | High — intentionally published |\n| Email announcements | High — formal communication |\n| Meeting notes | Moderate-high — may be incomplete |\n| Chat messages (thread conclusions) | Moderate — informal but real-time |\n| Chat messages (mid-thread) | Lower — may not reflect final position |\n| Draft documents | Low — not finalized |\n| Task comments | Contextual — depends on commenter |\n\n### Expressing Confidence\n\nWhen confidence is high (multiple fresh, authoritative sources agree):\n```\nThe team decided to use REST for the API redesign. [direct statement]\n```\n\nWhen confidence is moderate (single source or somewhat dated):\n```\nBased on the discussion in #engineering last month, the team was leaning\ntoward REST for the API redesign. This may have evolved since then.\n```\n\nWhen confidence is low (old data, informal source, or conflicting signals):\n```\nI found a reference to an API migration discussion from three months ago\nin ~~chat, but I couldn't find a formal decision document. The information\nmay be outdated. You might want to check with the team for current status.\n```\n\n### Conflicting Information\n\nWhen sources disagree:\n```\nI found conflicting information about the API approach:\n- The ~~chat discussion on Jan 10 suggested GraphQL\n- But Sarah's email on Jan 15 confirmed REST\n- The design doc (updated Jan 15) reflects REST\n\nThe most recent sources indicate REST was the final decision,\nbut the earlier ~~chat discussion explored GraphQL first.\n```\n\nAlways surface conflicts rather than silently picking one version.\n\n## Summarization Strategies\n\n### For Small Result Sets (1-5 results)\n\nPresent each result with context. No summarization needed — give the user everything:\n```\n[Direct answer synthesized from results]\n\n[Detail from source 1]\n[Detail from source 2]\n\nSources: [full attribution]\n```\n\n### For Medium Result Sets (5-15 results)\n\nGroup by theme and summarize each group:\n```\n[Overall answer]\n\nTheme 1: [summary of related results]\nTheme 2: [summary of related results]\n\nKey sources: [top 3-5 most relevant sources]\nFull results: [count] items found across [sources]\n```\n\n### For Large Result Sets (15+ results)\n\nProvide a high-level synthesis with the option to drill down:\n```\n[Overall answer based on most relevant results]\n\nSummary:\n- [Key finding 1] (supported by N sources)\n- [Key finding 2] (supported by N sources)\n- [Key finding 3] (supported by N sources)\n\nTop sources:\n- [Most authoritative/relevant source]\n- [Second most relevant]\n- [Third most relevant]\n\nFound [total count] results across [source list].\nWant me to dig deeper into any specific aspect?\n```\n\n### Summarization Rules\n\n- Lead with the answer, not the search process\n- Do not list raw results — synthesize them into narrative\n- Group related items from different sources together\n- Preserve important nuance and caveats\n- Include enough detail that the user can decide whether to dig deeper\n- Always offer to provide more detail if the result set was large\n\n## Synthesis Workflow\n\n```\n[Raw results from all sources]\n          ↓\n[1. Deduplicate — merge same info from different sources]\n          ↓\n[2. Cluster — group related results by theme/topic]\n          ↓\n[3. Rank — order clusters and items by relevance to query]\n          ↓\n[4. Assess confidence — freshness × authority × agreement]\n          ↓\n[5. Synthesize — produce narrative answer with attribution]\n          ↓\n[6. Format — choose appropriate detail level for result count]\n          ↓\n[Coherent answer with sources]\n```\n\n## Anti-Patterns\n\n**Do not:**\n- List results source by source (\"From ~~chat: ... From ~~email: ... From ~~cloud storage: ...\")\n- Include irrelevant results just because they matched a keyword\n- Bury the answer under methodology explanation\n- Present conflicting info without flagging the conflict\n- Omit source attribution\n- Present uncertain information with the same confidence as well-supported facts\n- Summarize so aggressively that useful detail is lost\n\n**Do:**\n- Lead with the answer\n- Group by topic, not by source\n- Flag confidence levels when appropriate\n- Surface conflicts explicitly\n- Attribute all claims to sources\n- Offer to go deeper when result sets are large",
  "applicable_domains": [
    "search",
    "knowledge"
  ],
  "invocation": [
    "/knowledge-synthesis"
  ],
  "tags": [
    "enterprise-search",
    "anthropics",
    "knowledge-work"
  ],
  "authored_by": "anthropics",
  "source_url": "https://github.com/anthropics/knowledge-work-plugins/blob/main/enterprise-search/skills/knowledge-synthesis/SKILL.md",
  "lifecycle": "stable",
  "category": "knowledge",
  "provenance": {
    "source": "anthropics/knowledge-work-plugins",
    "source_url": "https://github.com/anthropics/knowledge-work-plugins/blob/main/enterprise-search/skills/knowledge-synthesis/SKILL.md",
    "author": "Anthropic",
    "license": "Apache-2.0",
    "notes": "Imported by scripts/import-anthropic-skills.py."
  }
}