opencode-knowledge-work 0.0.0-stage → 0.1.0

package/content/enterprise-search/skills/enterprise-search-search/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: search
+description: Search across all connected sources in one query. Trigger with "find that doc about...", "what did we decide on...", "where was the conversation about...", or when looking for a decision, document, or discussion that could live in chat, email, cloud storage, or a project tracker.
+argument-hint: "<query>"
+---
+
+# Search Command
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Search across all connected MCP sources in a single query. Decompose the user's question, run parallel searches, and synthesize results.
+
+## Instructions
+
+### 1. Check Available Sources
+
+Before searching, determine which MCP sources are available. Attempt to identify connected tools from the available tool list. Common sources:
+
+- **~~chat** — chat platform tools
+- **~~email** — email tools
+- **~~cloud storage** — cloud storage tools
+- **~~project tracker** — project tracking tools
+- **~~CRM** — CRM tools
+- **~~knowledge base** — knowledge base tools
+
+If no MCP sources are connected:
+```
+To search across your tools, you'll need to connect at least one source.
+Check your MCP settings to add ~~chat, ~~email, ~~cloud storage, or other tools.
+
+Supported sources: ~~chat, ~~email, ~~cloud storage, ~~project tracker, ~~CRM, ~~knowledge base,
+and any other MCP-connected service.
+```
+
+### 2. Parse the User's Query
+
+Analyze the search query to understand:
+
+- **Intent**: What is the user looking for? (a decision, a document, a person, a status update, a conversation)
+- **Entities**: People, projects, teams, tools mentioned
+- **Time constraints**: Recency signals ("this week", "last month", specific dates)
+- **Source hints**: References to specific tools ("in ~~chat", "that email", "the doc")
+- **Filters**: Extract explicit filters from the query:
+  - `from:` — Filter by sender/author
+  - `in:` — Filter by channel, folder, or location
+  - `after:` — Only results after this date
+  - `before:` — Only results before this date
+  - `type:` — Filter by content type (message, email, doc, thread, file)
+
+### 3. Decompose into Sub-Queries
+
+For each available source, create a targeted sub-query using that source's native search syntax:
+
+**~~chat:**
+- Use available search and read tools for your chat platform
+- Translate filters: `from:` maps to sender, `in:` maps to channel/room, dates map to time range filters
+- Use natural language queries for semantic search when appropriate
+- Use keyword queries for exact matches
+
+**~~email:**
+- Use available email search tools
+- Translate filters: `from:` maps to sender, dates map to time range filters
+- Map `type:` to attachment filters or subject-line searches as appropriate
+
+**~~cloud storage:**
+- Use available file search tools
+- Translate to file query syntax: name contains, full text contains, modified date, file type
+- Consider both file names and content
+
+**~~project tracker:**
+- Use available task search or typeahead tools
+- Map to task text search, assignee filters, date filters, project filters
+
+**~~CRM:**
+- Use available CRM query tools
+- Search across Account, Contact, Opportunity, and other relevant objects
+
+**~~knowledge base:**
+- Use semantic search for conceptual questions
+- Use keyword search for exact matches
+
+### 4. Execute Searches in Parallel
+
+Run all sub-queries simultaneously across available sources. Do not wait for one source before searching another.
+
+For each source:
+- Execute the translated query
+- Capture results with metadata (timestamps, authors, links, source type)
+- Note any sources that fail or return errors — do not let one failure block others
+
+### 5. Rank and Deduplicate Results
+
+**Deduplication:**
+- Identify the same information appearing across sources (e.g., a decision discussed in ~~chat AND confirmed via email)
+- Group related results together rather than showing duplicates
+- Prefer the most authoritative or complete version
+
+**Ranking factors:**
+- **Relevance**: How well does the result match the query intent?
+- **Freshness**: More recent results rank higher for status/decision queries
+- **Authority**: Official docs > wiki > chat messages for factual questions; conversations > docs for "what did we discuss" queries
+- **Completeness**: Results with more context rank higher
+
+### 6. Present Unified Results
+
+Format the response as a synthesized answer, not a raw list of results:
+
+**For factual/decision queries:**
+```
+[Direct answer to the question]
+
+Sources:
+- [Source 1: brief description] (~~chat, #channel, date)
+- [Source 2: brief description] (~~email, from person, date)
+- [Source 3: brief description] (~~cloud storage, doc name, last modified)
+```
+
+**For exploratory queries ("what do we know about X"):**
+```
+[Synthesized summary combining information from all sources]
+
+Found across:
+- ~~chat: X relevant messages in Y channels
+- ~~email: X relevant threads
+- ~~cloud storage: X related documents
+- [Other sources as applicable]
+
+Key sources:
+- [Most important source with link/reference]
+- [Second most important source]
+```
+
+**For "find" queries (looking for a specific thing):**
+```
+[The thing they're looking for, with direct reference]
+
+Also found:
+- [Related items from other sources]
+```
+
+### 7. Handle Edge Cases
+
+**Ambiguous queries:**
+If the query could mean multiple things, ask one clarifying question before searching:
+```
+"API redesign" could refer to a few things. Are you looking for:
+1. The REST API v2 redesign (Project Aurora)
+2. The internal SDK API changes
+3. Something else?
+```
+
+**No results:**
+```
+I couldn't find anything matching "[query]" across [list of sources searched].
+
+Try:
+- Broader terms (e.g., "database" instead of "PostgreSQL migration")
+- Different time range (currently searching [time range])
+- Checking if the relevant source is connected (currently searching: [sources])
+```
+
+**Partial results (some sources failed):**
+```
+[Results from successful sources]
+
+Note: I couldn't reach [failed source(s)] during this search.
+Results above are from [successful sources] only.
+```
+
+## Notes
+
+- Always search multiple sources in parallel — never sequentially
+- Synthesize results into answers, do not just list raw search results
+- Include source attribution so users can dig deeper
+- Respect the user's filter syntax and apply it appropriately per source
+- When a query mentions a specific person, search for their messages/docs/mentions across all sources
+- For time-sensitive queries, prioritize recency in ranking
+- If only one source is connected, still provide useful results from that source

package/content/enterprise-search/skills/enterprise-search-search-strategy/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: search-strategy
+description: Query decomposition and multi-source search orchestration. Breaks natural language questions into targeted searches per source, translates queries into source-specific syntax, ranks results by relevance, and handles ambiguity and fallback strategies.
+user-invocable: false
+---
+
+# Search Strategy
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+The core intelligence behind enterprise search. Transforms a single natural language question into parallel, source-specific searches and produces ranked, deduplicated results.
+
+## The Goal
+
+Turn this:
+```
+"What did we decide about the API migration timeline?"
+```
+
+Into targeted searches across every connected source:
+```
+~~chat:  "API migration timeline decision" (semantic) + "API migration" in:#engineering after:2025-01-01
+~~knowledge base: semantic search "API migration timeline decision"
+~~project tracker:  text search "API migration" in relevant workspace
+```
+
+Then synthesize the results into a single coherent answer.
+
+## Query Decomposition
+
+### Step 1: Identify Query Type
+
+Classify the user's question to determine search strategy:
+
+| Query Type | Example | Strategy |
+|-----------|---------|----------|
+| **Decision** | "What did we decide about X?" | Prioritize conversations (~~chat, email), look for conclusion signals |
+| **Status** | "What's the status of Project Y?" | Prioritize recent activity, task trackers, status updates |
+| **Document** | "Where's the spec for Z?" | Prioritize Drive, wiki, shared docs |
+| **Person** | "Who's working on X?" | Search task assignments, message authors, doc collaborators |
+| **Factual** | "What's our policy on X?" | Prioritize wiki, official docs, then confirmatory conversations |
+| **Temporal** | "When did X happen?" | Search with broad date range, look for timestamps |
+| **Exploratory** | "What do we know about X?" | Broad search across all sources, synthesize |
+
+### Step 2: Extract Search Components
+
+From the query, extract:
+
+- **Keywords**: Core terms that must appear in results
+- **Entities**: People, projects, teams, tools (use memory system if available)
+- **Intent signals**: Decision words, status words, temporal markers
+- **Constraints**: Time ranges, source hints, author filters
+- **Negations**: Things to exclude
+
+### Step 3: Generate Sub-Queries Per Source
+
+For each available source, create one or more targeted queries:
+
+**Prefer semantic search** for:
+- Conceptual questions ("What do we think about...")
+- Questions where exact keywords are unknown
+- Exploratory queries
+
+**Prefer keyword search** for:
+- Known terms, project names, acronyms
+- Exact phrases the user quoted
+- Filter-heavy queries (from:, in:, after:)
+
+**Generate multiple query variants** when the topic might be referred to differently:
+```
+User: "Kubernetes setup"
+Queries: "Kubernetes", "k8s", "cluster", "container orchestration"
+```
+
+## Source-Specific Query Translation
+
+### ~~chat
+
+**Semantic search** (natural language questions):
+```
+query: "What is the status of project aurora?"
+```
+
+**Keyword search:**
+```
+query: "project aurora status update"
+query: "aurora in:#engineering after:2025-01-15"
+query: "from:<@UserID> aurora"
+```
+
+**Filter mapping:**
+| Enterprise filter | ~~chat syntax |
+|------------------|--------------|
+| `from:sarah` | `from:sarah` or `from:<@USERID>` |
+| `in:engineering` | `in:engineering` |
+| `after:2025-01-01` | `after:2025-01-01` |
+| `before:2025-02-01` | `before:2025-02-01` |
+| `type:thread` | `is:thread` |
+| `type:file` | `has:file` |
+
+### ~~knowledge base (Wiki)
+
+**Semantic search** — Use for conceptual queries:
+```
+descriptive_query: "API migration timeline and decision rationale"
+```
+
+**Keyword search** — Use for exact terms:
+```
+query: "API migration"
+query: "\"API migration timeline\""  (exact phrase)
+```
+
+### ~~project tracker
+
+**Task search:**
+```
+text: "API migration"
+workspace: [workspace_id]
+completed: false  (for status queries)
+assignee_any: "me"  (for "my tasks" queries)
+```
+
+**Filter mapping:**
+| Enterprise filter | ~~project tracker parameter |
+|------------------|----------------|
+| `from:sarah` | `assignee_any` or `created_by_any` |
+| `after:2025-01-01` | `modified_on_after: "2025-01-01"` |
+| `type:milestone` | `resource_subtype: "milestone"` |
+
+## Result Ranking
+
+### Relevance Scoring
+
+Score each result on these factors (weighted by query type):
+
+| Factor | Weight (Decision) | Weight (Status) | Weight (Document) | Weight (Factual) |
+|--------|-------------------|------------------|--------------------|-------------------|
+| Keyword match | 0.3 | 0.2 | 0.4 | 0.3 |
+| Freshness | 0.3 | 0.4 | 0.2 | 0.1 |
+| Authority | 0.2 | 0.1 | 0.3 | 0.4 |
+| Completeness | 0.2 | 0.3 | 0.1 | 0.2 |
+
+### Authority Hierarchy
+
+Depends on query type:
+
+**For factual/policy questions:**
+```
+Wiki/Official docs > Shared documents > Email announcements > Chat messages
+```
+
+**For "what happened" / decision questions:**
+```
+Meeting notes > Thread conclusions > Email confirmations > Chat messages
+```
+
+**For status questions:**
+```
+Task tracker > Recent chat > Status docs > Email updates
+```
+
+## Handling Ambiguity
+
+When a query is ambiguous, prefer asking one focused clarifying question over guessing:
+
+```
+Ambiguous: "search for the migration"
+→ "I found references to a few migrations. Are you looking for:
+   1. The database migration (Project Phoenix)
+   2. The cloud migration (AWS → GCP)
+   3. The email migration (Exchange → O365)"
+```
+
+Only ask for clarification when:
+- There are genuinely distinct interpretations that would produce very different results
+- The ambiguity would significantly affect which sources to search
+
+Do NOT ask for clarification when:
+- The query is clear enough to produce useful results
+- Minor ambiguity can be resolved by returning results from multiple interpretations
+
+## Fallback Strategies
+
+When a source is unavailable or returns no results:
+
+1. **Source unavailable**: Skip it, search remaining sources, note the gap
+2. **No results from a source**: Try broader query terms, remove date filters, try alternate keywords
+3. **All sources return nothing**: Suggest query modifications to the user
+4. **Rate limited**: Note the limitation, return results from other sources, suggest retrying later
+
+### Query Broadening
+
+If initial queries return too few results:
+```
+Original: "PostgreSQL migration Q2 timeline decision"
+Broader:  "PostgreSQL migration"
+Broader:  "database migration"
+Broadest: "migration"
+```
+
+Remove constraints in this order:
+1. Date filters (search all time)
+2. Source/location filters
+3. Less important keywords
+4. Keep only core entity/topic terms
+
+## Parallel Execution
+
+Always execute searches across sources in parallel, never sequentially. The total search time should be roughly equal to the slowest single source, not the sum of all sources.
+
+```
+[User query]
+     ↓ decompose
+[~~chat query] [~~email query] [~~cloud storage query] [Wiki query] [~~project tracker query]
+     ↓            ↓            ↓              ↓            ↓
+  (parallel execution)
+     ↓
+[Merge + Rank + Deduplicate]
+     ↓
+[Synthesized answer]
+```

package/content/enterprise-search/skills/enterprise-search-source-management/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: source-management
+description: Manages connected MCP sources for enterprise search. Detects available sources, guides users to connect new ones, handles source priority ordering, and manages rate limiting awareness.
+user-invocable: false
+---
+
+# Source Management
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Knows what sources are available, helps connect new ones, and manages how sources are queried.
+
+## Checking Available Sources
+
+Determine which MCP sources are connected by checking available tools. Each source corresponds to a set of MCP tools:
+
+| Source | Key capabilities |
+|--------|-----------------|
+| **~~chat** | Search messages, read channels and threads |
+| **~~email** | Search messages, read individual emails |
+| **~~cloud storage** | Search files, fetch document contents |
+| **~~project tracker** | Search tasks, typeahead search |
+| **~~CRM** | Query records (accounts, contacts, opportunities) |
+| **~~knowledge base** | Semantic search, keyword search |
+
+If a tool prefix is available, the source is connected and searchable.
+
+## Guiding Users to Connect Sources
+
+When a user searches but has few or no sources connected:
+
+```
+You currently have [N] source(s) connected: [list].
+
+To expand your search, you can connect additional sources in your MCP settings:
+- ~~chat — messages, threads, channels
+- ~~email — emails, conversations, attachments
+- ~~cloud storage — docs, sheets, slides
+- ~~project tracker — tasks, projects, milestones
+- ~~CRM — accounts, contacts, opportunities
+- ~~knowledge base — wiki pages, knowledge base articles
+
+The more sources you connect, the more complete your search results.
+```
+
+When a user asks about a specific tool that is not connected:
+
+```
+[Tool name] isn't currently connected. To add it:
+1. Open your MCP settings
+2. Add the [tool] MCP server configuration
+3. Authenticate when prompted
+
+Once connected, it will be automatically included in future searches.
+```
+
+## Source Priority Ordering
+
+Different query types benefit from searching certain sources first. Use these priorities to weight results, not to skip sources:
+
+### By Query Type
+
+**Decision queries** ("What did we decide..."):
+```
+1. ~~chat (conversations where decisions happen)
+2. ~~email (decision confirmations, announcements)
+3. ~~cloud storage (meeting notes, decision logs)
+4. Wiki (if decisions are documented)
+5. Task tracker (if decisions are captured in tasks)
+```
+
+**Status queries** ("What's the status of..."):
+```
+1. Task tracker (~~project tracker — authoritative status)
+2. ~~chat (real-time discussion)
+3. ~~cloud storage (status docs, reports)
+4. ~~email (status update emails)
+5. Wiki (project pages)
+```
+
+**Document queries** ("Where's the doc for..."):
+```
+1. ~~cloud storage (primary doc storage)
+2. Wiki / ~~knowledge base (knowledge base)
+3. ~~email (docs shared via email)
+4. ~~chat (docs shared in channels)
+5. Task tracker (docs linked to tasks)
+```
+
+**People queries** ("Who works on..." / "Who knows about..."):
+```
+1. ~~chat (message authors, channel members)
+2. Task tracker (task assignees)
+3. ~~cloud storage (doc authors, collaborators)
+4. ~~CRM (account owners, contacts)
+5. ~~email (email participants)
+```
+
+**Factual/Policy queries** ("What's our policy on..."):
+```
+1. Wiki / ~~knowledge base (official documentation)
+2. ~~cloud storage (policy docs, handbooks)
+3. ~~email (policy announcements)
+4. ~~chat (policy discussions)
+```
+
+### Default Priority (General Queries)
+
+When query type is unclear:
+```
+1. ~~chat (highest volume, most real-time)
+2. ~~email (formal communications)
+3. ~~cloud storage (documents and files)
+4. Wiki / ~~knowledge base (structured knowledge)
+5. Task tracker (work items)
+6. CRM (customer data)
+```
+
+## Rate Limiting Awareness
+
+MCP sources may have rate limits. Handle them gracefully:
+
+### Detection
+
+Rate limit responses typically appear as:
+- HTTP 429 responses
+- Error messages mentioning "rate limit", "too many requests", or "quota exceeded"
+- Throttled or delayed responses
+
+### Handling
+
+When a source is rate limited:
+
+1. **Do not retry immediately** — respect the limit
+2. **Continue with other sources** — do not block the entire search
+3. **Inform the user**:
+```
+Note: [Source] is temporarily rate limited. Results below are from
+[other sources]. You can retry in a few minutes to include [source].
+```
+4. **For digests** — if rate limited mid-scan, note which time range was covered before the limit hit
+
+### Prevention
+
+- Avoid unnecessary API calls — check if the source is likely to have relevant results before querying
+- Use targeted queries over broad scans when possible
+- For digests, batch requests where the API supports it
+- Cache awareness: if a search was just run, avoid re-running the same query immediately
+
+## Source Health
+
+Track source availability during a session:
+
+```
+Source Status:
+  ~~chat:        ✓ Available
+  ~~email:        ✓ Available
+  ~~cloud storage:  ✓ Available
+  ~~project tracker:        ✗ Not connected
+  ~~CRM:   ✗ Not connected
+  ~~knowledge base:      ⚠ Rate limited (retry in 2 min)
+```
+
+When reporting search results, include which sources were searched so the user knows the scope of the answer.
+
+## Adding Custom Sources
+
+The enterprise search plugin works with any MCP-connected source. As new MCP servers become available, they can be added to the `.mcp.json` configuration. The search and digest commands will automatically detect and include new sources based on available tools.
+
+To add a new source:
+1. Add the MCP server configuration to `.mcp.json`
+2. Authenticate if required
+3. The source will be included in subsequent searches automatically

package/content/finance/.mcp.json

@@ -0,0 +1,32 @@
+{
+  "mcpServers": {
+    "snowflake": {
+      "type": "http",
+      "url": ""
+    },
+    "databricks": {
+      "type": "http",
+      "url": ""
+    },
+    "bigquery": {
+      "type": "http",
+      "url": "https://bigquery.googleapis.com/mcp"
+    },
+    "slack": {
+      "type": "http",
+      "url": "https://mcp.slack.com/mcp",
+      "oauth": {
+        "clientId": "1601185624273.8899143856786",
+        "callbackPort": 3118
+      }
+    },
+    "google calendar": {
+      "type": "http",
+      "url": ""
+    },
+    "gmail": {
+      "type": "http",
+      "url": ""
+    }
+  }
+}

package/content/finance/CONNECTORS.md

@@ -0,0 +1,20 @@
+# Connectors
+
+## How tool references work
+
+Plugin files use `~~category` as a placeholder for whatever tool the user connects in that category. For example, `~~data warehouse` might mean Snowflake, BigQuery, or any other warehouse with an MCP server.
+
+Plugins are **tool-agnostic** — they describe workflows in terms of categories (data warehouse, chat, project tracker, etc.) rather than specific products. The `.mcp.json` pre-configures specific MCP servers, but any MCP server in that category works.
+
+## Connectors for this plugin
+
+| Category | Placeholder | Included servers | Other options |
+|----------|-------------|-----------------|---------------|
+| Data warehouse | `~~data warehouse` | Snowflake\*, Databricks\*, BigQuery | Redshift, PostgreSQL |
+| Email | `~~email` | Microsoft 365 | — |
+| Office suite | `~~office suite` | Microsoft 365 | — |
+| Chat | `~~chat` | Slack | Microsoft Teams |
+| ERP / Accounting | `~~erp` | — (no supported MCP servers yet) | NetSuite, SAP, QuickBooks, Xero |
+| Analytics / BI | `~~analytics` | — (no supported MCP servers yet) | Tableau, Looker, Power BI |
+
+\* Placeholder — MCP URL not yet configured