Update to Company Knowledge

{
  "name": "company-knowledge",
  "description": "Search company knowledge across connected workplace tools with direct connector fanout, evidence merging, and inline citations. Use for source-backed questions about internal projects, status, decisions, owners, docs, chat, GitHub, code, email, or meetings.",
  "included_files": [],
  "skill_md_contents": "---\nname: company-knowledge\ndescription: \"Search company knowledge across connected workplace tools with direct connector fanout, evidence merging, and inline citations. Use for source-backed questions about internal projects, status, decisions, owners, docs, chat, GitHub, code, email, or meetings.\"\n---\n\n# Company Knowledge\n\nCompany Knowledge makes connected workplace sources feel like one citeable knowledge surface:\n\n1. decide which connected sources are useful,\n2. fan out bounded first-pass searches directly through connector tools,\n3. merge and deduplicate evidence in the model,\n4. answer with inline citations and source coverage.\n\nTreat `@Company Knowledge`, `$company-knowledge`, or an explicit request to search company knowledge as routing the turn to this plugin.\n\nThis workflow deliberately avoids a custom MCP planner or merge server. Use direct connector fanout for the first pass. Use subagents only for a later deep-dive after the first merged evidence pack exposes a specific gap.\n\n## Source Preflight\n\nBefore searching, identify the source lanes that are available in the current session. Use the plugin-associated apps and any already loaded connector tools as the source of truth. Do not claim that an unavailable connector was searched. If a likely source lane is not already callable, use `tool_search` to discover and load that connector family before marking it unavailable. Treat \"only a profile/user lookup is available\" as insufficient for Slack, Teams, Gmail, or calendar evidence; message/thread/document search must be available before the lane can satisfy source-backed questions.\n\nThe plugin declares these optional source families:\n\n- Slack and Teams for recent discussion, informal decisions, feedback, and ownership signals.\n- Google Drive, SharePoint, and Notion for canonical docs, plans, runbooks, policies, and wiki pages.\n- GitHub and Linear for implementation state, issues, pull requests, milestones, and code ownership.\n- Gmail, Outlook Email, Google Calendar, Outlook Calendar, and ChatGPT Meetings for email threads, meeting context, attendees, pre-reads, and formal follow-up.\n\nBuild a complete connector inventory before selecting search lanes. Include all plugin-associated apps, all already exposed connector tool families, and any additional connected apps returned by a host-level connector inventory. Treat the declared families above as an expected set, not an allowlist. Classify each connector internally as:\n\n- `searchable_connected`: connected and exposes content search or read tools;\n- `connected_insufficient`: connected, but exposes only profile lookup or other tools that cannot retrieve evidence for the question;\n- `unavailable`: not connected, not loaded after discovery, or errored.\n\nDo not stop inventory after finding the first useful connectors. Declared does not mean connected, and connected does not mean searchable. If the host exposes no global connected-app inventory, exhaustive coverage is limited to the connectors visible to the plugin; disclose that limitation when the user asks for all connected sources.\n\nIf a high-value connector is unavailable, continue with the connected sources, but do not stop at a weak adjacent lane. Try the next most authoritative lane for the task first, and mention the missing lane only when it materially affects confidence.\n\n## Authoritative Code Lane\n\nFor code, file, API, stack trace, diff, CLI, migration, schema, dependency, or \"where in the codebase\" questions, GitHub/code evidence is the authoritative lane. In Codex environments, the local workspace and git checkout count as this lane and should usually be faster and more reliable than connector search.\n\nUse the local code lane before docs/wiki-only search when it is available:\n\n- Start with `rg --files`, `rg`, or `git grep` for exact paths, symbols, commands, errors, package names, PR numbers, and likely aliases.\n- For history or diff questions, search git history with exact terms using `git log --all --grep`, `git log -S`, `git log -G`, then inspect focused commits with `git show`.\n- For code ownership or implementation state, combine local files with GitHub PR/issue search if the GitHub connector is callable.\n- Cite concrete file paths, line numbers, PR numbers, commit hashes, or diff hunks. Do not cite a docs/wiki summary when local code or GitHub evidence directly supports the claim.\n\nDo not answer \"I could not find the code/source/diff\" from docs/wiki-only evidence. A negative code answer is allowed only after at least one authoritative code lane was actually searched. If no GitHub/code connector and no local workspace are available, say the code lane was unavailable and avoid replacing it with adjacent docs evidence.\n\n## Fanout Planning\n\nCreate a first-pass plan from the complete connector inventory. Do not impose a fixed connector-count cap. In the default relevant-coverage mode, search every `searchable_connected` connector whose source type could materially answer the question. Keep each lane bounded to one or two high-signal queries rather than a large query grid.\n\nUse exhaustive-coverage mode when the user asks to search all connectors, all sources, or everything; when the task is broad cross-company discovery; or when an ownership roster, inventory, or negative finding would be misleading if a connected source were omitted. In exhaustive mode, attempt at least one bounded search against every `searchable_connected` connector, even when a connector has a low prior probability of useful results. Connector errors must not block the remaining fanout.\n\nUse these defaults:\n\n- Canonical project or policy question: docs/wiki first, then Slack or Teams, then GitHub or Linear if implementation state matters.\n- Latest status or decision question: Slack or Teams first, then docs/wiki, then Linear or GitHub.\n- Ownership question: docs/wiki, Slack or Teams, GitHub, and Linear.\n- Engineering implementation question: GitHub and Linear first, then docs/wiki, then Slack or Teams for recent discussion.\n- Meeting or email question: Calendar, Meetings, Gmail or Outlook Email, then docs/wiki for linked pre-reads.\n\nUse task-specific query packs when the prompt includes strong retrieval hints:\n\n- Code, API, file, diff, stack trace, or implementation questions: GitHub/code search is required when available. In Codex, local `rg`/`git` search satisfies the code lane and should be attempted before any docs/wiki-only fallback. Search exact file paths, symbols, error strings, PR numbers, commit hashes, model/service names, and one paraphrase. Do not answer \"not found\" from docs/wiki-only evidence for code questions.\n- PRD, roadmap, policy, memo, migration guide, or runbook questions: Google Drive/SharePoint/Notion document search is required when available. Search exact titles and acronyms first, then owner/team aliases.\n- Slack channel, latest status, incident, customer issue, or \"who is working on this\" questions: Slack or Teams message/thread search is required when available. Search exact channel names, quoted terms, IDs, and the main entity name. If Slack/Teams message search is unavailable, say so explicitly and compensate with docs/wiki plus GitHub/Linear.\n- Broad \"search everything\", ownership, inventory, or negative-finding questions: use exhaustive-coverage mode before giving a final roster or \"no evidence found\" answer.\n\nWhen multiple connectors are selected, issue the first-pass connector calls in parallel where the host supports it. Do not spawn subagents for first-pass fanout. Subagents are only appropriate for a later deep-dive after the first merged evidence pack exposes a specific gap.\n\n## Connector Execution\n\nUse native connector search and read tools. Load connector tool families with `tool_search` only when they are needed and not already callable.\n\nConnection prompts are a fallback, not a prerequisite. Search materially relevant `searchable_connected` sources before offering another connector. Offer a missing connector only when the user explicitly requested that connector, no materially relevant connector is connected, or connected-source retrieval leaves a material evidence gap that the missing connector is strongly likely to resolve. Keep the offer optional and continue answering from available evidence. If no materially relevant connector is connected, recommend only the one to three source families most likely to answer the question, ranked by expected usefulness with a brief reason for each; do not enumerate every declared connector or start authentication automatically. This policy applies only to connecting data sources to ChatGPT: do not reinterpret ordinary questions about setting up or accessing a workplace account, device, or service as connector requests.\n\n### Bounded Two-Wave Normal Mode\n\nBefore dispatching the first search wave, extract a compact list of required answer slots from the question and pair each slot with its authoritative source lane. Examples include dates and status for a timeline, the primary command plus follow-up/validation commands for a how-to, and eligibility, exclusions, limits, and required documentation for a policy question. Shape the first query for each selected connector to cover those slots instead of beginning with a generic query and discovering the slots later.\n\nUse at most two logical search waves in normal mode:\n\n1. The first wave attempts every connector required by the relevant-coverage or exhaustive-coverage gate. Issue those searches in parallel when supported. Use one compact high-signal query per connector; use a second query in that same wave only when the connector accepts a parallel batch or the question contains two clearly distinct named entities.\n2. After merging the first-wave evidence, run one focused second wave only when a required answer slot lacks verified support, the evidence comes only from an adjacent lane, sources materially conflict, or a latest/negative finding lacks the required scope. Each second-wave call must name the missing slot, artifact, title, path, person, date, command, or conflict it is intended to resolve. Dispatch independent gap searches together.\n\nDo not start a third broad search wave. If a required slot remains unresolved after the focused second wave, state the gap or uncertainty in the answer. Explicit exhaustive coverage changes which connectors must be attempted in the first wave; it does not authorize repeated unfocused searches within every connector.\n\nTreat an unchanged connector failure as final for the turn after one attempt. A disconnected or authentication-required result must never block the turn: record it, continue immediately with other connected sources, and do not wait, poll, or retry an interactive connection flow. Do not retry the same failed operation unless authentication or tool availability visibly changes. Do not repeat an exact query or re-fetch an already visible artifact. Prefer merging and citing existing verified evidence over collecting redundant corroboration.\n\nFor local code, begin with a scoped exact-term, path, or symbol search and inspect only the most relevant files or commits. Do not recursively search generated outputs, caches, dependency/build output, or broad checkout roots with an unbounded result set. If an exact search is empty, use one scoped paraphrase or history query in the focused second wave.\n\nKeep the first pass bounded:\n\n- Search exact names, acronyms, and likely aliases from the prompt.\n- Prefer title/path/channel filters when the connector supports them.\n- Use recent windows for status questions and broader windows for canonical docs.\n- Read the top few promising results deeply enough to cite them.\n- Stop searching when additional results repeat the same evidence.\n- If the best result lane is only adjacent to the question, run one focused second-pass query in the more authoritative lane before answering. Examples: a docs/wiki result mentions a code path, then search GitHub for that path; Slack mentions a doc, then search docs/wiki for the title; docs mention a PR, then search GitHub for the PR or commit.\n\nTrack a compact internal envelope for each connector:\n\n```json\n{\n  \"connector\": \"slack\",\n  \"queries\": [\"query actually sent\"],\n  \"searched\": true,\n  \"resultCount\": 4,\n  \"topSourceIds\": [\"S1\", \"S2\"],\n  \"error\": null\n}\n```\n\nIf a connector is unavailable or errors, keep an envelope with `\"searched\": false` and a concise `error`, then continue with other sources.\n\nFor local code searches, keep the same envelope internally with `connector: \"local_code\"` and cite the resulting paths or commits in the final answer.\n\n## Connector Coverage Gate\n\nBefore merging evidence, compare the connector envelopes with the complete inventory:\n\n- In relevant-coverage mode, every materially relevant `searchable_connected` connector must have either a completed search attempt or an explicit error. Mark the remaining connected connectors as intentionally irrelevant to this question rather than silently omitting them.\n- In exhaustive-coverage mode, every `searchable_connected` connector must have a search attempt or explicit error. A zero-result search still counts as an attempt; an undispatched connector does not.\n\nIf required coverage is incomplete, dispatch the missing connector searches before answering. Never claim that all connected sources were searched unless the exhaustive-coverage gate passes.\n\n## Evidence Merge\n\nAfter the first-pass results return, deduplicate sources that refer to the same artifact, thread, issue, meeting, or decision. Rank evidence using:\n\n1. direct answer relevance,\n2. source authority,\n3. recency when the question asks for current state,\n4. corroboration across independent source lanes,\n5. source depth over search-result snippets.\n\nPrefer durable docs/wiki for canonical facts, specs, policies, and plans. Prefer Slack, Teams, email, meetings, and Linear for recent decisions and status. Prefer GitHub for code and pull request reality. If sources conflict, explain the conflict and identify which source appears newer or more authoritative.\n\nBefore finalizing, do a compact coverage check:\n\n1. Extract the answer slots implied by the question: people/owners, dates, decisions, locations/files, commands, examples, risks, and current status.\n2. Verify each material slot is supported by at least one cited source.\n3. If a required slot is unsupported, use the single focused second wave described above; do not reopen broad discovery.\n4. If the slot still cannot be supported, say exactly which slot is missing rather than replacing it with adjacent evidence.\n\nDo not treat a plausible docs/wiki summary as sufficient for a code/file answer, a broad docs result as sufficient for a latest Slack status answer, or a Slack snippet as sufficient for a canonical policy answer unless corroborating sources are unavailable and the caveat is explicit.\n\n## Evidence Visibility Gate\n\nOnly use evidence that is visible in the current tool trace. A connector call counts as supporting evidence only when the returned payload exposes enough source metadata or content to verify the claim. A completion status, result count, planned query, source URL remembered from elsewhere, or model memory of a document/thread is not evidence.\n\nBefore finalizing, classify every cited source as one of:\n\n- `verified`: source content, metadata, file excerpt, commit diff, or thread snippet is visible in the current trace.\n- `locator_only`: only a title, URL, path, or search hit is visible.\n- `unverified`: the source was planned, unavailable, errored, canceled, or not visibly returned.\n\nUse `verified` sources for material claims. `locator_only` sources may support a next search, but should not support final factual claims unless the answer says the evidence is only a locator. Never cite `unverified` sources. If all direct sources are unverified, answer with the uncertainty or missing-source finding instead of reconstructing the likely content.\n\nFor local code, a file path alone is not enough for a detailed claim. Inspect the relevant lines or diff hunk in the current turn, then cite that inspected path, line range, commit, or PR. If you cannot expose the relevant content in the trace, keep the answer high-level and say what still needs inspection.\n\n## Latest And Registry Gate\n\nFor latest-status, most-recent, checkpoint, inventory, model-version, owner roster, and \"current list\" questions, distinguish the latest source you could retrieve from the actual latest source. Do not say \"the latest thread/update is...\", \"the most recent checkpoint is...\", or provide a canonical inventory unless the searched connector visibly covers the relevant scope and returns ordered recent results or an authoritative registry.\n\nIf evidence is partial, historical, unordered, or only examples, say that plainly and avoid filling every requested slot with best guesses. For broad checkpoint or inventory questions, prefer:\n\n1. state that no authoritative current registry was retrieved,\n2. list only clearly supported examples with dates/source context,\n3. identify the registry or connector lane needed for a precise answer.\n\nFor Slack/Teams latest-thread questions, if the actual thread body is not retrieved, do not summarize it from titles, stale snippets, or adjacent docs. Say the latest thread contents could not be verified and name the searched scope.\n\n## Citation Contract\n\nEvery material claim should have an inline citation. Use native citation support when the host provides it. Otherwise use compact source IDs such as `[S1]` and include a `Sources` section.\n\nEach source should have enough metadata for a future source panel:\n\n- `id`: stable answer-local id such as `S1`\n- `connector`: Slack, Google Drive, GitHub, etc.\n- `title`: document title, thread title, issue title, email subject, or meeting title\n- `url`: durable link when available\n- `location`: channel, folder path, repo, issue number, sender, calendar, or workspace location when available\n- `date`: updated, created, sent, or meeting date when available\n- `snippet`: short evidence-bearing excerpt or paraphrase when direct quoting is not appropriate\n\nDo not over-cite. Put citations immediately after the claim they support. If the only available evidence is weak, stale, snippet-only, or from a non-canonical source, say that plainly.\n\nWhen the retrieved evidence includes a direct source and an indirect summary, cite the direct source for the claim. If the final answer says no source was found, cite the searches/results that support the negative finding and name the high-value lanes that could not be searched.\n\n## Required Slot Completeness\n\nBefore final answer, make a compact checklist of the answer slots implied by the question and the retrieved evidence. Check for commands, flags, file paths, follow-up commands, modes, data sources, packages, schema changes, dates, owners, status, caveats, and explicit negative findings.\n\nFor each slot:\n\n- if verified evidence supports it, include it with a citation;\n- if a focused follow-up search can verify it quickly, run that search;\n- if it remains unsupported, either omit it or mark it as unknown.\n\nDo not trade completeness for overconfident synthesis. If a code/script question asks \"what does this do?\", inspect the main entrypoint plus adjacent README, tests, or called ingestion/conversion scripts when names are visible. If a scaffolding or how-to question asks for commands, include post-generation or validation commands only when they are visible in inspected docs/code.\n\n## Answer Shape\n\nLead with the answer, not the search process. Use a source coverage note only when it helps the user judge reliability.\n\nDefault structure:\n\n1. answer or recommendation,\n2. brief supporting evidence with inline citations,\n3. open questions or caveats when evidence is incomplete,\n4. optional `Sources` list if native clickable citations are unavailable.\n\nDo not include search telemetry in the final answer by default. This includes \"planned connectors\", \"executed connectors\", result counts, availability diagnostics, and whether searches were parallel. Keep that envelope internal.\n\nFor an explicit exhaustive-coverage request, include one compact coverage note listing the connected connectors searched and any connected connectors that errored or lacked usable content search. Do not include result counts unless the user asks for them. If no global connector inventory was available, say that the coverage includes every connector visible to the plugin rather than claiming it includes every connector connected anywhere in the workspace.\n\nIf the user explicitly asks how the search was done, include only mechanically observed facts from actual tool calls. Never claim a connector was executed, parallelism happened, or a result count existed unless the visible tool trace proves it. For partial evidence, prefer a short source coverage caveat over a debug block.\n\n## Accuracy And Latency Expectations\n\nThis skill can express the CK product shape: at-mention routing, connector availability awareness, parallel first-pass search, citation discipline, and source coverage. It does not own server-side retrieval, sync indexes, ranking, deduplication, citation anchoring, caching, or the client citation panel.\n\nDirect connector fanout should avoid the startup cost of spinning up many subagents just to search. The tradeoff is weaker determinism: without MCP planner and merge tools, fanout choices and citation formatting are behavioral instructions rather than a hard schema contract.\n"
}