Stats
Actions
Tags
From enterprise-search
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/enterprise-search:knowledge-synthesisThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.
The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.
Lark-native execution (depth core: LARK-PATTERNS, LARK-FUSION). This skill is pure synthesis methodology — it operates on results already returned by the
lark_*reads (IMlark_im_search, Mail, Docs/Wikilark_doc_*, Minuteslark_minutes_search, Tasks/Baselark_task_my/lark_base_search). Attribute each source by its Lark surface + date. When the synthesized output is a decision recap or digest the user will act on, hand it to the caller to render as an interactive card (lark_im_card_send, P4) rather than plain text. If you need a deeper read of any source to resolve a conflict, delegate to that source's owning skill (lark-doc,lark-minutes,lark-base).
Transform this:
IM result (lark_im_search): "Sarah said in eng group: 'let's go with REST, GraphQL is overkill'"
Mail result: "Subject: API Decision — Sarah's mail confirming REST + rationale"
Docs result (lark_doc_fetch): "API Design Doc v3 — section 2 updated to reflect REST decision"
Tasks result (lark_task_my): "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 the engineering group on Tuesday, confirmed via mail Wednesday, and the design doc
has been updated to reflect the decision. The related task is marked complete.
Sources:
- IM: engineering group thread (Jan 14)
- Mail: "API Decision" from Sarah (Jan 15)
- Docs: "API Design Doc v3" (updated Jan 15)
- Task: "Finalize API approach" (completed Jan 15)
The same information often appears in multiple places. Identify and merge duplicates:
Signals that results are about the same thing:
How to merge:
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)
Keep as separate items when:
Every claim in the synthesized answer must be attributable to a source.
Inline for direct references:
Sarah confirmed the REST approach in her mail on Wednesday.
The design doc was updated to reflect this (Docs: "API Design Doc v3").
Source list at the end for completeness:
Sources:
- IM: engineering group discussion (Jan 14) — initial decision thread
- Mail: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
- Docs: "API Design Doc v3" last modified Jan 15 — updated specification
- Minutes: "API Sync" AI summary (Jan 14) — decision + owner captured
open_id)lark_im_search), note the group/chat namelark_doc_*), note the document title and linklark_minutes_search), note the meeting title and that it's an AI artifact (P6)lark_base_search), note the table/record (the system-of-record, P5)Not all results are equally trustworthy. Assess confidence based on:
| 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 outdated |
For status queries, heavily weight freshness. For policy/factual queries, freshness matters less.
| Source type | Authority level |
|---|---|
| Official wiki / knowledge base | Highest — curated, maintained |
| Shared documents (final versions) | High — intentionally published |
| Email announcements | High — formal communication |
| Meeting notes | Moderate-high — may be incomplete |
| Chat messages (thread conclusions) | Moderate — informal but real-time |
| Chat messages (mid-thread) | Lower — may not reflect final position |
| Draft documents | Low — not finalized |
| Task comments | Contextual — depends on commenter |
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 source or 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 IM, 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.
When sources disagree:
I found conflicting information about the API approach:
- The IM 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 IM discussion explored GraphQL first.
Always surface conflicts rather than silently picking one version.
Present each result with context. No summarization needed — give the user everything:
[Direct answer synthesized from results]
[Detail from source 1]
[Detail from source 2]
Sources: [full attribution]
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]
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 [source list].
Want me to dig deeper into any specific aspect?
[Raw results from all sources]
↓
[1. Deduplicate — merge same info from different sources]
↓
[2. Cluster — group related results by theme/topic]
↓
[3. Rank — order clusters and items by relevance to query]
↓
[4. Assess confidence — freshness × authority × agreement]
↓
[5. Synthesize — produce narrative answer with attribution]
↓
[6. Format — choose appropriate detail level for result count]
↓
[Coherent answer with sources]
Do not:
Do:
npx claudepluginhub larkcowork/lark-cowork-plugins --plugin enterprise-searchCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.