po4yka/llm-wiki-skills/llm-wiki-team-rollout

LLM-Wiki Team Rollout

Goal

Introduce and operate LLM-Wiki in a team without creating an unreviewed official-looking slop layer or a hidden reliability burden.

Use references/docs/22-team-operating-model.md as the reference operating model for roles, RACI/DACI, governance, SLOs, rituals, staffing stages, dashboards, onboarding and GitOps controls.

When to use

• A team is adopting LLM-Wiki for the first time and needs an operating model, not just tooling.
• A pilot wiki is moving to early production and needs PR-based writes, CODEOWNERS and a review queue.
• Leadership asks for RACI/DACI, SLOs or a rollout plan before expanding to more domains.
• A team is deciding between read-only reports, PR-based writes, a draft wiki or direct writes.
• An existing rollout needs a governance or maturity-stage review (e.g. moving toward regulated/24x7).

Starter templates

Use these local templates when available:

• references/templates/team-operating-model.yaml
• references/templates/team-raci-daci.yaml
• references/templates/team-review-workflow.yaml
• references/templates/team-slo-scorecard.yaml
• references/templates/team-onboarding-checklist.md
• references/templates/CODEOWNERS.llm-wiki

Copy only the templates that fit the rollout stage, then replace placeholder roles, owners, SLOs and review-state gates.

Inputs

• Team size and workflows.
• Repository/docs platform.
• Existing docs, ADRs, onboarding material, issue/PR history, incident history and support channels.
• Security, privacy and permission constraints.
• Existing CODEOWNERS, branch protection and CI gates.
• Preferred write model: read-only, PR-based, direct writes, separate draft wiki.
• Current LLM-Wiki maturity: pilot, early production, business-critical, regulated/24x7.
• Desired outcome: adoption plan, operating model, RACI, templates, repo changes or governance review.

Procedure

1. Identify the organizational problem

Classify the primary use case:

• onboarding;
• bus factor / departing experts;
• agent context for coding workflows;
• decision provenance;
• incident/ops knowledge;
• product/research knowledge;
• customer/support knowledge;
• cross-team handoff;
• multi-domain knowledge governance;
• public/internal publishing;
• MCP/API/product interface support.

2. Choose maturity stage

3. Define operating model

Recommended default:

Product Owner + Technical Lead + Knowledge Engineer + Retrieval/Eval Engineer
+ shared Platform/SRE + shared Security + Domain Editors/SMEs + Publishing owner where needed

Use roles:

4. Choose write model

Default to PR/proposal-based writes for teams:

agent proposal -> branch/patch -> lint/eval/security checks -> CODEOWNERS/domain review -> merge -> index refresh

5. Define ownership and RACI

Map:

• who owns each wiki domain/path;
• who approves synthesis pages;
• who owns taxonomy/schema changes;
• who handles lint and eval failures;
• who owns ingestion profiles;
• who approves MCP/API/export changes;
• who handles incident response;
• which domains are sensitive or restricted;
• what agents may read, propose and publish.

Use RACI for recurring execution and DACI for cross-team decisions.

Minimum RACI fields:

workflow: ""
responsible: []
accountable: ""
consulted: []
informed: []
required_checks: []
escalation: ""

6. Add governance layers

Ensure the rollout covers:

7. Start with high-value domains

Good first domains:

• onboarding map;
• architecture overview;
• ADR/decision history;
• repo conventions;
• incident postmortems;
• product terminology;
• recurring support questions;
• policy/runbook pages with clear owners.

Avoid migrating everything at once.

8. Define metrics and SLOs

Track:

• retrieval hit rate;
• citation coverage;
• unsupported-claim rate;
• review backlog count;
• median review age;
• stale verified pages;
• source/index freshness lag;
• agent mistakes caused by missing context;
• PR cycle time for documentation updates;
• docs read/write ratio;
• onboarding questions answered from the wiki;
• public/agent export failures;
• incident count and MTTR;
• team toil percentage.

Example gates:

review_queue:
  median_age_days_max: 7
  high_risk_age_days_max: 3
retrieval:
  recall_at_10_min: 0.80
grounding:
  citation_coverage_min: 0.90
  material_unsupported_claims_max: 0
publishing:
  blocking_redaction_findings_max: 0
operations:
  index_freshness_hours_max: 24

9. Define operating rituals

Recommended cadence:

10. Add GitOps controls

Recommend:

• CODEOWNERS for wiki/, raw/manifests/, skills/, templates/, .github/, api/, mcp/, exports/profiles/, evals/;
• branch protection or rulesets;
• required PR reviews;
• required checks by PR type;
• protected environments for publishing/deployment;
• minimal workflow permissions;
• artifact manifests and scorecards.

11. Create rollout plan

Use phases:

1. team charter, working agreements, owners, initial RACI;
2. read-only inventory;
3. draft wiki for one domain;
4. PR-based updates and review states;
5. weekly lint/eval/security review;
6. onboarding/query usage;
7. export/MCP/API only after gates exist;
8. expand to more domains;
9. operating scorecard and maturity review.

Output

## Team rollout recommendation
 
## Primary use case
 
## Maturity stage
 
## Proposed operating model
 
## Roles and RACI
 
## Proposed write model
 
## Ownership and review policy
 
## Initial domains
 
## Repository and GitOps controls
 
## SLOs, metrics and dashboards
 
## Rituals and cadences
 
## Onboarding plan
 
## Rollout phases
 
## Risks and mitigations
 
## Follow-up skills

Safety gates

• Do not recommend direct writes for teams without a named reviewer and rollback path.
• Do not index restricted material into broadly readable wiki pages.
• Do not blur draft and verified knowledge.
• Do not let lint/eval agents silently resolve truth conflicts.
• Do not recommend public export, llms-full.txt, MCP/API or agent-bundle rollout before redaction, eval and approval gates exist.
• Do not recommend 24x7 support without a sustainable on-call staffing plan.