| name | llm-wiki-company-flow-audit |
| description | Map company/team information flows into an LLM-Wiki adoption plan. Use when the user asks where team knowledge lives, which streams can be automated, how Confluence/Jira/Slack/Drive changes stay synced, how fragile review is, how confidential data is handled, or whether maintenance cost is worth the benefit. |
| license | MIT |
| compatibility | Designed for Agent Skills-compatible coding agents. Browse and cite fresh vendor API/security docs before giving exact connector or permission claims. |
| metadata | {"author":"po4yka","version":"1.0.0","install_scope":"self-contained"} |
LLM-Wiki Company Flow Audit
Goal
Help users plan company/team-level LLM-Wiki ingestion and operations from real information flows, without pretending that all knowledge can be safely or usefully automated.
When to use
Use when the user asks:
- where team/company information currently lives;
- how to collect from Confluence, Jira, GitHub, Slack, Teams, Drive, meetings, support, analytics or email;
- what can be fully automated and what cannot;
- how to keep external docs updated when they change;
- how fragile vault-review/lint systems are;
- how much time link/contradiction repair takes;
- whether there is a good UI for review queues;
- whether confidential information and access control are supported;
- what pitfalls to avoid;
- whether the maintenance cost is worth the value.
Inputs
- The list of systems currently holding team/company knowledge (e.g. Confluence, Jira, GitHub, Slack, Teams, Drive, PagerDuty).
- Team/org scale (personal pilot, one team, cross-functional, or company-level) so the maintenance-planning range fits.
- Whether a source registry or ingestion tooling already exists, and its refresh policy (webhook, poll, manual, snapshot).
- Any confidentiality/access constraints: data classification tiers, who owns which sources, existing permission boundaries.
- Prior review-queue or UI setup (PR-based review, Obsidian vault, dashboard) if one is already in place.
Required references
Read these when available:
references/docs/company-information-flows.mdreferences/docs/adoption-objections.mdreferences/docs/adoption-q-and-a.mdreferences/docs/19-security-threat-model.md
For vendor claims about Confluence, Jira, Slack, Teams, Google Drive, SharePoint or GitHub, browse and cite current official docs.
Core stance
Use this answer:
Start from the information flows that already influence decisions. Automate capture, metadata, version/hash tracking, stale marking and review reports. Do not fully automate truth promotion, contradiction resolution, sensitive summaries or official documentation updates.
Procedure
1. Inventory source flows
Map sources into:
| Flow | Examples |
|---|
| Docs | Confluence, Notion, Google Docs, SharePoint, PDFs. |
| Work tracking | Jira, Linear, GitHub Issues, YouTrack. |
| Code collaboration | PRs, reviews, commits, releases, ADRs. |
| Chat | Slack, Teams, Telegram, Discord. |
| Meetings | Calendar, transcripts, recordings, notes. |
| Customer/product evidence | CRM, support tickets, sales calls, research repos. |
| Analytics | BI, warehouse queries, product analytics, experiments. |
| Ops/incidents | PagerDuty, postmortems, on-call notes. |
Recommend starting with 3-5 flows that affect real decisions, not every system.
2. Classify automation level
Use three levels:
| Level | Meaning | Examples |
|---|
| Automatic capture | Safe append-only or metadata sync. | Webhooks, event logs, source hashes, stale flags. |
| Assisted transformation | Agent drafts structure but review is needed. | Summaries, entity pages, decision pages, dedup candidates. |
| Human-gated truth | Human owner must approve. | Verified claims, contradictions, sensitive summaries, official docs. |
3. Design external update handling
Require a source registry:
source_id: confluence:123456
system: confluence|jira|github|slack|teams|drive|manual
external_id: "123456"
url: "https://..."
version: "42"
updated_at: "2026-07-07T10:00:00Z"
source_hash: "sha256:..."
last_seen_at: "2026-07-07T10:05:00Z"
last_ingested_at: "2026-07-07T10:10:00Z"
derived_pages: []
refresh_policy: webhook|poll|manual|snapshot
Update flow:
webhook/delta/poll -> raw event -> fetch current source -> compare version/hash -> mark derived pages stale -> create diff/refresh report -> owner review
Do not silently overwrite reviewed human synthesis.
4. Explain fragility and repair effort
Be honest:
- broken links and orphans are usually cheap;
- schema drift is manageable with validators and dry-run migrations;
- duplicates and contradictions require owner judgment;
- stale external sources require a source registry and refresh loop;
- permission leaks and generated slop are high-risk;
- ignored review queues are a system failure, not a UI bug.
Use planning ranges, not guarantees:
| Scale | Maintenance planning range |
|---|
| Personal/tiny pilot | 30-60 minutes weekly. |
| One team/domain | 1-2 hours weekly plus domain-owner review. |
| Cross-functional pilot | Product Ops/curator rotation and weekly review meeting. |
| Company-level Nexus | Dedicated ownership, access policy and dashboards. |
5. Discuss UI
Default UI stack:
- Markdown reports for portability;
- GitHub/GitLab PR or issue queue for review;
- Obsidian graph/backlinks/Dataview for local exploration;
- Jira/Linear board for team triage;
- dashboard only after queues are too hard to operate manually.
Do not imply a polished universal UI exists unless the repository/tooling actually has one.
6. Handle confidentiality
Say:
Yes, but only with data classification, split access domains, least-privilege agents, model boundaries, redaction and audit logs. If permissions cannot be modeled, keep metadata/links only and fetch with user-scoped credentials on demand.
Never recommend ingesting secrets.
7. Evaluate cost versus benefit
Do not use page count. Use:
- time-to-answer recurring questions;
- answer reuse rate;
- decision citation rate;
- stale/unsupported claims found before decisions;
- review backlog;
- output beyond wiki: PRDs, strategy notes, experiments, ADRs, reports.
Continue only if the wiki changes decisions, speeds context recovery or prevents mistakes.
Output
Use this structure:
## Information-flow map
## Automation plan
## External update / versioning plan
## Fragility and review effort
## UI and operating model
## Confidentiality and permissions
## Pitfalls
## Cost-benefit check
Safety gates
- Do not promise full automation of truth.
- Do not claim webhook delivery is sufficient without reconciliation.
- Do not recommend all-chat or all-email ingestion by default.
- Do not centralize confidential sources before modeling permissions.
- Do not imply a polished UI exists unless it does.
- Do not use page count as a success metric.
- Do not ingest secrets.
