knowledge-synthesis

Name: knowledge-synthesis
Author: anthropics

5.1kinstalls2.7kforks

How to install knowledge-synthesis?

anthropics/knowledge-work-plugins/knowledge-synthesis

$npx -y skills add anthropics/knowledge-work-plugins --skill knowledge-synthesis

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Knowledge Synthesis
2
3	The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.
4
5	## The Goal
6
7	Transform this:
8	```
9	~~chat result: "Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'"
10	~~email result: "Subject: API Decision — Sarah's email confirming REST approach with rationale"
11	~~cloud storage result: "API Design Doc v3 — updated section 2 to reflect REST decision"
12	~~project tracker result: "Task: Finalize API approach — marked complete by Sarah"
13	```
14
15	Into this:
16	```
17	The team decided to go with REST over GraphQL for the API redesign. Sarah made the
18	call, noting that GraphQL was overkill for the current use case. This was discussed
19	in #engineering on Tuesday, confirmed via email Wednesday, and the design doc has
20	been updated to reflect the decision. The related ~~project tracker task is marked complete.
21
22	Sources:
23	- ~~chat: #engineering thread (Jan 14)
24	- ~~email: "API Decision" from Sarah (Jan 15)
25	- ~~cloud storage: "API Design Doc v3" (updated Jan 15)
26	- ~~project tracker: "Finalize API approach" (completed Jan 15)
27	```
28
29	## Deduplication
30
31	### Cross-Source Deduplication
32
33	The same information often appears in multiple places. Identify and merge duplicates:
34
35	Signals that results are about the same thing:
36	- Same or very similar text content
37	- Same author/sender
38	- Timestamps within a short window (same day or adjacent days)
39	- References to the same entity (project name, document, decision)
40	- One source references another ("as discussed in ~~chat", "per the email", "see the doc")
41
42	How to merge:
43	- Combine into a single narrative item
44	- Cite all sources where it appeared
45	- Use the most complete version as the primary text
46	- Add unique details from each source
47
48	### Deduplication Priority
49
50	When the same information exists in multiple sources, prefer:
51	```
52	1. The most complete version (fullest context)
53	2. The most authoritative source (official doc > chat)
54	3. The most recent version (latest update wins for evolving info)
55	```
56
57	### What NOT to Deduplicate
58
59	Keep as separate items when:
60	- The same topic is discussed but with different conclusions
61	- Different people express different viewpoints
62	- The information evolved meaningfully between sources (v1 vs v2 of a decision)
63	- Different time periods are represented
64
65	## Citation and Source Attribution
66
67	Every claim in the synthesized answer must be attributable to a source.
68
69	### Attribution Format
70
71	Inline for direct references:
72	```
73	Sarah confirmed the REST approach in her email on Wednesday.
74	The design doc was updated to reflect this (~~cloud storage: "API Design Doc v3").
75	```
76
77	Source list at the end for completeness:
78	```
79	Sources:
80	- ~~chat: #engineering discussion (Jan 14) — initial decision thread
81	- ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
82	- ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification
83	```
84
85	### Attribution Rules
86
87	- Always name the source type (~~chat, ~~email, ~~cloud storage, etc.)
88	- Include the specific location (channel, folder, thread)
89	- Include the date or relative time
90	- Include the author when relevant
91	- Include document/thread titles when available
92	- For ~~chat, note the channel name
93	- For ~~email, note the subject line and sender
94	- For ~~cloud storage, note the document title
95
96	## Confidence Levels
97
98	Not all results are equally trustworthy. Assess confidence based on:
99
100	### Freshness
101
102	\| Recency \| Confidence impact \|
103	\|---------\|------------------\|
104	\| Today / yesterday \| High confidence for current state \|
105	\| This week \| Good confidence \|
106	\| This month \| Moderate — things may have changed \|
107	\| Older than a month \| Lower confidence — flag as potentially outdated \|
108
109	For status queries, heavily weight freshness. For policy/factual queries, freshness matters less.
110
111	### Authority
112
113	\| Source type \| Authority level \|
114	\|-------------\|----------------\|
115	\| Official wiki / knowledge base \| Highest — curated, maintained \|
116	\| Shared documents (final versions) \| High — intentionally published \|
117	\| Email announcements \| High — formal communication \|
118	\| Meeting notes \| Moderate-high — may be incomplete \|
119	\| Chat messages (thread conclusions) \| Moderate — informal but real-time \|
120	\| Chat messages (mid-thread) \| Lower — may not reflect final position \|
121	\| Draft documents \| Low — not finalized \|
122	\| Task comments \| Contextual — depends on commenter \|
123
124	### Expressing Confidence
125
126	When confidence is high (multiple fresh, authoritative sources agree):
127	```
128	The team decided to use REST for the API redesign. [direct statement]
129	```
130
131	When confidence is moderate (single source or somewhat dated):
132	```
133	Based on the discussion in #engineering last month, the team was leaning
134	toward

People who liked this also viewed

6 picks

Type

knowledge-synthesis

5.1kinstalls2.7kforks

View on GitHub

How to install knowledge-synthesis?

anthropics/knowledge-work-plugins/knowledge-synthesis

$npx -y skills add anthropics/knowledge-work-plugins --skill knowledge-synthesis

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Knowledge Synthesis
2
3	The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.
4
5	## The Goal
6
7	Transform this:
8	```
9	~~chat result: "Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'"
10	~~email result: "Subject: API Decision — Sarah's email confirming REST approach with rationale"
11	~~cloud storage result: "API Design Doc v3 — updated section 2 to reflect REST decision"
12	~~project tracker result: "Task: Finalize API approach — marked complete by Sarah"
13	```
14
15	Into this:
16	```
17	The team decided to go with REST over GraphQL for the API redesign. Sarah made the
18	call, noting that GraphQL was overkill for the current use case. This was discussed
19	in #engineering on Tuesday, confirmed via email Wednesday, and the design doc has
20	been updated to reflect the decision. The related ~~project tracker task is marked complete.
21
22	Sources:
23	- ~~chat: #engineering thread (Jan 14)
24	- ~~email: "API Decision" from Sarah (Jan 15)
25	- ~~cloud storage: "API Design Doc v3" (updated Jan 15)
26	- ~~project tracker: "Finalize API approach" (completed Jan 15)
27	```
28
29	## Deduplication
30
31	### Cross-Source Deduplication
32
33	The same information often appears in multiple places. Identify and merge duplicates:
34
35	Signals that results are about the same thing:
36	- Same or very similar text content
37	- Same author/sender
38	- Timestamps within a short window (same day or adjacent days)
39	- References to the same entity (project name, document, decision)
40	- One source references another ("as discussed in ~~chat", "per the email", "see the doc")
41
42	How to merge:
43	- Combine into a single narrative item
44	- Cite all sources where it appeared
45	- Use the most complete version as the primary text
46	- Add unique details from each source
47
48	### Deduplication Priority
49
50	When the same information exists in multiple sources, prefer:
51	```
52	1. The most complete version (fullest context)
53	2. The most authoritative source (official doc > chat)
54	3. The most recent version (latest update wins for evolving info)
55	```
56
57	### What NOT to Deduplicate
58
59	Keep as separate items when:
60	- The same topic is discussed but with different conclusions
61	- Different people express different viewpoints
62	- The information evolved meaningfully between sources (v1 vs v2 of a decision)
63	- Different time periods are represented
64
65	## Citation and Source Attribution
66
67	Every claim in the synthesized answer must be attributable to a source.
68
69	### Attribution Format
70
71	Inline for direct references:
72	```
73	Sarah confirmed the REST approach in her email on Wednesday.
74	The design doc was updated to reflect this (~~cloud storage: "API Design Doc v3").
75	```
76
77	Source list at the end for completeness:
78	```
79	Sources:
80	- ~~chat: #engineering discussion (Jan 14) — initial decision thread
81	- ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
82	- ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification
83	```
84
85	### Attribution Rules
86
87	- Always name the source type (~~chat, ~~email, ~~cloud storage, etc.)
88	- Include the specific location (channel, folder, thread)
89	- Include the date or relative time
90	- Include the author when relevant
91	- Include document/thread titles when available
92	- For ~~chat, note the channel name
93	- For ~~email, note the subject line and sender
94	- For ~~cloud storage, note the document title
95
96	## Confidence Levels
97
98	Not all results are equally trustworthy. Assess confidence based on:
99
100	### Freshness
101
102	\| Recency \| Confidence impact \|
103	\|---------\|------------------\|
104	\| Today / yesterday \| High confidence for current state \|
105	\| This week \| Good confidence \|
106	\| This month \| Moderate — things may have changed \|
107	\| Older than a month \| Lower confidence — flag as potentially outdated \|
108
109	For status queries, heavily weight freshness. For policy/factual queries, freshness matters less.
110
111	### Authority
112
113	\| Source type \| Authority level \|
114	\|-------------\|----------------\|
115	\| Official wiki / knowledge base \| Highest — curated, maintained \|
116	\| Shared documents (final versions) \| High — intentionally published \|
117	\| Email announcements \| High — formal communication \|
118	\| Meeting notes \| Moderate-high — may be incomplete \|
119	\| Chat messages (thread conclusions) \| Moderate — informal but real-time \|
120	\| Chat messages (mid-thread) \| Lower — may not reflect final position \|
121	\| Draft documents \| Low — not finalized \|
122	\| Task comments \| Contextual — depends on commenter \|
123
124	### Expressing Confidence
125
126	When confidence is high (multiple fresh, authoritative sources agree):
127	```
128	The team decided to use REST for the API redesign. [direct statement]
129	```
130
131	When confidence is moderate (single source or somewhat dated):
132	```
133	Based on the discussion in #engineering last month, the team was leaning
134	toward

People who liked this also viewed

6 picks

Type