Knowledge Synthesis
Turn scattered chat, email, docs, and tracker hits into one attributed answer before you commit to a product or API decision.
Overview
Knowledge Synthesis is an agent skill most often used in Idea/research (also Build/docs and Grow/content) that merges multi-source search hits into one deduplicated, source-attributed answer.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill knowledge-synthesisWhat is this skill?
- Merges chat, email, cloud docs, and project-tracker hits into a single narrative with dated source lines
- Cross-source deduplication so the same decision does not appear as conflicting facts
- Confidence scoring from freshness and authority of each source
- Summarizes large result sets without dropping who said what and when
- Transforms raw hit lists into quotable, enterprise-trustworthy answers
Adoption & trust: 3.7k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have relevant snippets from chat, email, and docs but no single trustworthy summary of what the team actually decided.
Who is it for?
Builders running agentic research across Slack, email, wikis, and trackers who need one attributed story before writing plans or shipping.
Skip if: Skip when you only need a single-document summary or when you have not run retrieval yet—synthesis needs raw multi-source results to combine.
When should I use this skill?
Raw results from multiple enterprise sources need merging into one coherent, attributed answer with deduplication and confidence cues.
What do I get? / Deliverables
You get a coherent narrative with a source list and confidence cues you can paste into specs, ADRs, or stakeholder updates.
- Coherent multi-source answer paragraph
- Bulleted source list with channels and dates
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Idea/research because synthesis is the capstone of discovery—where raw enterprise search results become decisions you can ship against. Research is where multi-source facts get merged; the skill explicitly models cross-source deduplication and source attribution for investigative work.
Where it fits
After searching #engineering and email threads, synthesize whether the team chose REST or GraphQL before you draft an API spec.
Merge tracker tasks and doc revisions into one scope narrative so your MVP boundary matches what stakeholders already approved.
Update an API design doc section from fragmented chat and file versions so the repo README matches the latest decision.
Reconcile post-incident chat, tickets, and runbooks into a single timeline for a retrospective write-up.
How it compares
Use after search/retrieval plugins; this is synthesis prose, not another index or MCP crawl.
Common Questions / FAQ
Who is knowledge-synthesis for?
Solo and indie builders and small teams who use AI agents to research decisions buried across chat, email, and shared docs.
When should I use knowledge-synthesis?
During Idea research to consolidate competitor and internal signals, during Validate scope when tracing prior decisions, and during Build/docs when updating design docs from scattered threads.
Is knowledge-synthesis safe to install?
Treat it as procedural guidance that may steer agents to summarize sensitive enterprise text; review the Security Audits panel on this page before enabling in repos with secrets or PII.
SKILL.md
READMESKILL.md - Knowledge Synthesis
# Knowledge Synthesis The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer. ## The Goal Transform this: ``` ~~chat result: "Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'" ~~email result: "Subject: API Decision — Sarah's email confirming REST approach with rationale" ~~cloud storage result: "API Design Doc v3 — updated section 2 to reflect REST decision" ~~project tracker result: "Task: Finalize API approach — marked complete by Sarah" ``` Into this: ``` The team decided to go with REST over GraphQL for the API redesign. Sarah made the call, noting that GraphQL was overkill for the current use case. This was discussed in #engineering on Tuesday, confirmed via email Wednesday, and the design doc has been updated to reflect the decision. The related ~~project tracker task is marked complete. Sources: - ~~chat: #engineering thread (Jan 14) - ~~email: "API Decision" from Sarah (Jan 15) - ~~cloud storage: "API Design Doc v3" (updated Jan 15) - ~~project tracker: "Finalize API approach" (completed Jan 15) ``` ## Deduplication ### Cross-Source Deduplication The same information often appears in multiple places. Identify and merge duplicates: **Signals that results are about the same thing:** - Same or very similar text content - Same author/sender - Timestamps within a short window (same day or adjacent days) - References to the same entity (project name, document, decision) - One source references another ("as discussed in ~~chat", "per the email", "see the doc") **How to merge:** - Combine into a single narrative item - Cite all sources where it appeared - Use the most complete version as the primary text - Add unique details from each source ### Deduplication Priority When the same information exists in multiple sources, prefer: ``` 1. The most complete version (fullest context) 2. The most authoritative source (official doc > chat) 3. The most recent version (latest update wins for evolving info) ``` ### What NOT to Deduplicate Keep as separate items when: - The same topic is discussed but with different conclusions - Different people express different viewpoints - The information evolved meaningfully between sources (v1 vs v2 of a decision) - Different time periods are represented ## Citation and Source Attribution Every claim in the synthesized answer must be attributable to a source. ### Attribution Format Inline for direct references: ``` Sarah confirmed the REST approach in her email on Wednesday. The design doc was updated to reflect this (~~cloud storage: "API Design Doc v3"). ``` Source list at the end for completeness: ``` Sources: - ~~chat: #engineering discussion (Jan 14) — initial decision thread - ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation - ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification ``` ### Attribution Rules - Always name the source type (~~chat, ~~email, ~~cloud storage, etc.) - Include the specific location (channel, folder, thread) - Include the date or relative time - Include the author when relevant - Include document/thread titles when available - For ~~chat, note the channel name - For ~~email, note the subject line and sender - For ~~cloud storage, note the document title ## Confidence Levels Not all results are equally trustworthy. Assess confidence based on: ### Freshness | Recency | Confidence impact | |---------|------------------| | Today / yesterday | High confidence for current state | | This week | Good confidence | | This month | Moderate — things may have changed | | Older than a month | Lower confidence — flag as potentially outdat