llm-wiki-cadence-governance
Weekly governance workflow for keeping an llm-wiki repository current, code-development-useful, and connected to actionable GitHub issue planning.
Best use case
llm-wiki-cadence-governance is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Weekly governance workflow for keeping an llm-wiki repository current, code-development-useful, and connected to actionable GitHub issue planning.
Teams using llm-wiki-cadence-governance should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/llm-wiki-cadence-governance/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How llm-wiki-cadence-governance Compares
| Feature / Agent | llm-wiki-cadence-governance | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Weekly governance workflow for keeping an llm-wiki repository current, code-development-useful, and connected to actionable GitHub issue planning.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# LLM Wiki Cadence Governance Use this skill when reviewing an llm-wiki repository, comparing it against current LLM/AI engineering concepts, or opening issues to keep the wiki useful for code development and repo architecture decisions. ## Trigger Conditions - User asks to review, refresh, or maintain an `llm-wiki` repository. - User asks for a weekly cadence to keep AI/LLM concepts current. - User asks what GitHub issues should be opened from an llm-wiki architecture/content gap review. - A session produces llm-wiki maintenance artifacts that need durable closeout or restart handoff. ## Core Principle Treat llm-wiki as a development leverage system, not a passive knowledge base. Every review should connect external concept freshness, internal repo architecture gaps, and actionable GitHub issues that move engineering work forward. ## Weekly Cadence Workflow 1. **Repository architecture inventory** - Inspect current information architecture: domains, concept pages, source maps, graph/manifest generation, validation scripts, and docs reports. - Identify stale pages, orphaned nodes, weak cross-links, missing source citations, and concepts not tied to code-development use cases. 2. **External concept freshness scan** - Review current LLM/agent engineering topics relevant to the workspace: agents, tool use, RAG, context engineering, evals, model-routing, inference/serving, structured outputs, safety, data governance, and code-agent workflows. - Capture concepts as candidate deltas, not undigested research dumps. 3. **Code-development usefulness mapping** - For each candidate gap, ask: what repo decision, code pattern, evaluation, documentation contract, or automation pipeline would this improve? - Prioritize items that improve engineering velocity, correctness, agent routing, or reusable architecture guidance. 4. **Issue portfolio creation** - Open de-duplicated GitHub issues only after checking existing issues and plan state. - Prefer issue clusters by class: freshness pipeline, graph/index quality, source/citation governance, domain pages, code integration guides, eval/readiness scorecards. - Keep implementation gated by the workspace issue workflow: plan → adversarial review → user approval → TDD implementation. 5. **Validation and closeout** - Run the repo's available tests/validators for graph manifests, schemas, docs, and legal/public-safety gates before claiming readiness. - If closeout cannot finish, preserve restart state in a repo-tracked handoff with exact validation evidence, dirty files, issue status, and the next checkpoint. ## Issue Quality Checklist A good llm-wiki maintenance issue includes: - Clear problem statement tied to code-development leverage. - Current evidence path: repo files, generated reports, graph metrics, issue links, or source pages. - Scope boundaries: what is in/out for this issue. - Acceptance criteria with validation commands or report artifacts. - Public/private data classification where source material may cross governance boundaries. - Dependencies on existing architecture contracts, graph schema, citation model, or source-ingest workflows. ## Pitfalls - Do not create a flat backlog of generic “add topic X” issues. Tie each issue to a reusable architecture or development outcome. - Do not treat external AI trends as authoritative without source provenance and update dates. - Do not bypass issue planning gates just because the task is documentation-heavy. - Do not close an llm-wiki issue after only generating reports; verify that committed files, pushed state, issue labels/comments, and tests all match the claimed closeout. - Do not lose partial closeout state. If the session ends before commit/push/issue close, write a handoff first. ## Support References - `references/issue-closeout-handoff-pattern.md` — concise restart-handoff pattern from an llm-wiki public-graph issue closeout where validation passed but implementation files still needed final commit and issue closure.
Related Skills
public-knowledge-graph-governance
Maintain public-safe knowledge graph artifacts for llm-wiki and similar markdown knowledge bases. Use when changing graph generators, validators, schema docs, weekly freshness checks, or public/private source-scope boundaries.
llm-wiki-weekly-freshness
Class-level governance workflow for keeping llm-wiki-style markdown knowledge bases current, public-safe, graph/index-valid, and useful for code development. Use when reviewing llm-wiki architecture/content, scanning new LLM concepts, maintaining public knowledge graphs, producing an issue roadmap, or running recurring freshness cadence.
llm-wiki-source-extraction-coverage
Doc-type-aware extraction contract for llm-wiki source ingestion with measurable coverage and source-anchored traceability. Use when (1) ingesting a PDF, DOCX, XLSX, PPTX, HTML, or scanned-image source into a wiki `sources/` page, (2) computing the pre-extraction estimate (what fraction of the source we expect to recover) and post-extraction yield (what fraction we actually recovered), (3) anchoring wiki claims back to specific page / paragraph / cell / slide positions in the source so a reviewer can re-verify or revise against the actual document, (4) deciding whether OCR fallback or manual transcription is needed. Codifies workspace-hub's existing OCR fallback chain and python-docx / openpyxl / trafilatura patterns into a format-specific routing table. Companion to research/llm-wiki-page-shape-contract (Rule 7 input-layer pages) and research/llm-wiki — this skill is the defense against silent extraction failure.
llm-wiki-public-private-routing
Firewall between the public llm-wiki repo (vamseeachanta/llm-wiki, MIT + CC-BY-4.0) and per-client private wikis (vamseeachanta/llm-wiki-<client>, e.g. llm-wiki-mkt-a per #2746). Use when (1) deciding whether a converted wiki page lands in public or private surface, (2) applying the project-name abstraction rule to public-bound content, (3) evaluating the public- availability exception that lets actual project names pass through unmodified, (4) promoting content from private to public after sanitization. Encodes the 2026-05-20 user routing directive verbatim: exact client results → private; abstracted (project-name only) → public; project name + all key data publicly available → exception applies. Companion to research/llm-wiki-page-shape-contract (which calls this skill at Rule 8) and research/llm-wiki-source-extraction-coverage (which produces the source pages this skill decides where to send).
llm-wiki-page-shape-contract
Enforce the page-shape contract when a repo-side document or analysis output gets converted into an llm-wiki page. Use when (1) running `scripts/knowledge/llm_wiki.py ingest`, (2) writing or rewriting a wiki page from docs/reports/*, docs/handoffs/*, scripts/review/results/*, or calc citation outputs, (3) deciding whether a page should be split into a folder of sub-pages, (4) reviewing wiki PRs for length / diagram / divide-and-conquer compliance. Codifies the Karpathy + Astro-Han + lewislulu page rules applied to workspace-hub's domain-wiki layout under /mnt/local-analysis/llm-wiki/wikis/<domain>/. Sibling to research/llm-wiki (which owns the CLI ops) — this skill is the quality gate every converted page must clear before commit.
llm-wiki-audit-feedback-loop
Durable feedback loop for correcting llm-wiki pages without losing the correction to chat history. Use when (1) a human notices a wiki page is wrong, outdated, or contradicts a source, (2) processing the `audit/` inbox of a domain wiki, (3) reviewing what feedback has been resolved vs deferred, (4) needing to leave a comment on a specific text range that survives line- number drift. Implements the anchored-text audit file pattern from lewislulu/llm-wiki-skill, adapted for workspace-hub's domain-wiki layout under /mnt/local-analysis/llm-wiki/wikis/<domain>/. Extends the 5-op model (compile/ingest/query/lint) from research/llm-wiki with the missing `audit` op. Never silently delete feedback — rejected audits stay archived with rejection rationale.
oss-wiki-development-arc
Three-phase methodology (Substrate → Depth → Quality) for building open-source engineering wikis efficiently. Skip 70%+ of empirical iteration cost by pre-loading the pattern.
client-llm-wiki-factory
Operator checklist for instantiating a new per-client private llm-wiki repo under workspace-hub [#2746](https://github.com/vamseeachanta/workspace-hub/issues/2746) + [#2731](https://github.com/vamseeachanta/workspace-hub/issues/2731) D4 (amended) naming convention `llm-wiki-<client>`.
metadata-only-wiki-sweep-workflow
Disciplined inventory process for cataloging documents by filename/path without content claims, using parent-centric grouping to prevent stub proliferation
exclude-wiki-Codex-md-from-harness-line-limit-hook
Fix false-positive pre-commit failures where workspace-hub's AGENTS.md line-limit hook blocks edits to auto-generated wiki schema files under knowledge/wikis/.
split-plan-governance-vs-substance
When repeated adversarial plan reviews keep returning MAJOR findings about validator mechanics, evidence bookkeeping, or governance traceability rather than the core product or mission decision, stop tightening the monolithic plan and split it into a content/decision packet and a tooling/enforcement packet.
repair-legacy-llm-wiki-frontmatter-dates
Diagnose and repair legacy llm-wiki source pages that have ingested timestamps but are missing required added/last_updated frontmatter dates.