Knowledge Synthesis

What This Skill Does

This skill synthesizes raw search results from multiple enterprise sources into a coherent and trustworthy answer. It's designed for users who need a clear, concise summary of information scattered across different platforms. The skill deduplicates information and prioritizes authoritative sources.

When to Use

• Summarize decisions made across chat, email, and documents.
• Combine information from multiple sources into a single report.
• Identify the most complete and authoritative answer to a question.
• Deduplicate information appearing in multiple locations.
• Quickly understand the context around a specific topic.
• Find the rationale behind a specific decision.

Key Features

• Deduplicates information from multiple sources.
• Prioritizes authoritative sources for accuracy.
• Combines information into a single narrative.
• Cites all sources used in the synthesis.
• Identifies and merges duplicate information.
• Uses the most complete version as the primary text.

## 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-

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 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) The most authoritative source (official doc > chat) 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

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").

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 (~~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

For status queries, heavily weight freshness. For policy/factual queries, freshness matters less.

Authority

Expressing Confidence

When confidence is high (multiple fresh, authoritative sources agree): The team decided to use REST for the API redesign. [direct statement]

When confidence is moderate (single somewhat dated): Based on the discussion in #engineering last month, the team was leaning toward REST for the API redesign. This may have evolved since then.

When confidence is low (old data, informal source, or conflicting signals): I found a reference to an API migration discussion from three months ago in ~~chat, but I couldn't find a formal decision document. The information may be outdated. You might want to check with the team for current status.

Conflicting Information

When sources disagree: I found conflicting information about the API approach: The ~~chat discussion on Jan 10 suggested GraphQL But Sarah's email on Jan 15 confirmed REST The design doc (updated Jan 15) reflects REST

The most recent sources indicate REST was the final decision, but the earlier ~~chat discussion explored GraphQL first.

Always surface conflicts rather than silently picking one version.

Summarization Strategies

For Small Result Sets (1-5 results)

Present each result with context. No summarization needed — give the user everything: [Direct answer synthesized from results]

[Detail from ] [Detail from ]

Sources: [full attribution]

For Medium Result Sets (5-15 results)

Group by theme and summarize each group: [Overall answer]

Theme 1: [summary of related results] Theme 2: [summary of related results]

Key sources: [top 3-5 most relevant sources] Full results: [count] items found across [sources]

For Large Result Sets (15+ results)

Provide a high-level synthesis with the option to drill down: [Overall answer based on most relevant results]

Summary: [Key finding 1] (supported by N sources) [Key finding 2] (supported by N sources) [Key finding 3] (supported by N sources)

Top sources: [Most authoritative/relevant source] [Second most relevant] [Third most relevant]

Found [total count] results across []. Want me to dig deeper into any specific aspect?

Summarization Rules

Lead with the answer, not the search process Do not list raw results — synthesize them into narrative Group related items from different sources together Preserve important nuance and caveats Include enough detail that the user can decide whether to dig deeper Always offer to provide more detail if the result set was large

Synthesis Workflow

[Raw results from all sources] ↓ [1. Deduplicate — merge same info from different sources] ↓ [2. Clu