Skip to content

Wiki Schema

How this wiki is structured and how an agent maintains it. Based on the LLM Wiki pattern: the agent — not humans — writes and maintains every page.

Purpose

A general-purpose, portable knowledge base for agents. It captures lessons, patterns, and playbooks that transfer across projects, so agents stop making the same mistakes twice. It evolves like a harness: every project, retrospective, and debugging session can feed it.

What does NOT belong here:

  • ❌ Client-specific or confidential info (profiles, addresses, pricing deals) — that lives in clients/*/CLIENT.md and changes anytime; agents read it there directly
  • ❌ Project-specific state ("the K-PUB site uses X") — file the generalized lesson instead ("restaurant sites need X because Y")
  • ❌ Anything derivable from reading the code or the source repo

Litmus test before filing a page: would this still be useful on the next project, for a different client? If no, it doesn't go in the wiki.

Three layers

Layer Location Rule
Raw sources Retrospectives, debugging sessions, meeting takeaways, articles Immutable to the wiki. Read, never modify.
The wiki wiki/ (this directory) Agent-owned. Markdown only. Humans read; the agent writes.
The schema This file Conventions and workflows. Co-evolves with the user.

Directory layout

wiki/
├── index.md        # catalog of every page — update on every ingest
├── log.md          # append-only history of wiki operations
├── SCHEMA.md       # this file
├── playbooks/      # DEV playbooks — native wiki content, source of truth is HERE
├── marketing/      # MARKETING playbooks — native wiki content, source of truth is HERE
├── lessons/        # mistakes made once, generalized so they aren't made again
├── patterns/       # reusable how-tos and design patterns that worked
└── notes/          # filed query answers, comparisons, syntheses

Page types

  • Playbook — step-by-step procedural checklist. Dev playbooks (playbooks/) and marketing playbooks (marketing/) both live natively in this wiki — the single source of truth; edit them here directly. When a lesson matures into a repeatable procedure, promote it into the matching playbook. Campaign artifacts (lead CSVs, outreach drafts, flyers) stay in agency/promotions/; brand assets stay in agency/brand/.
  • Lesson (lessons/) — one mistake or gotcha per page, generalized. Structure: Context → What went wrong → Root cause → Rule going forward. Name by the rule, not the incident (verify-dns-before-deploy.md, not kpub-outage.md).
  • Pattern (patterns/) — an approach that worked and is worth repeating. Structure: Problem → Solution → When to use / when not → Example.
  • Note (notes/) — filed answers and syntheses worth keeping.

Page conventions

  • YAML frontmatter on every page: type (lesson | pattern | note | ops), tags, updated (YYYY-MM-DD).
  • Cross-reference with relative links: [verify DNS first](../lessons/verify-dns-before-deploy.md).
  • Korean/English mixed is fine; write rules in whichever is clearest.
  • Flag contradictions and open questions inline with > ⚠️ … — never silently pick a side.
  • Keep pages atomic: one lesson/pattern per page. Merge duplicates during lint.

Operations

Ingest — after a retrospective, debugging session, or project handoff: 1. Read the source fully. 2. Extract only what generalizes; strip client names where they aren't essential. 3. Create/update lesson and pattern pages (one source may touch several). 4. Update index.md; append to log.md: ## [YYYY-MM-DD] ingest | <source> + bullets.

Query — answering questions from the wiki: 1. Read index.md first, then drill into pages. 2. If the answer produced new reusable synthesis, file it under notes/ and index it. 3. Log it: ## [YYYY-MM-DD] query | <question>.

Lint — periodic health check: - Duplicated lessons, stale rules superseded by newer experience, orphan pages, lessons that should be promoted into a checklist in _checklists. - Log findings: ## [YYYY-MM-DD] lint.

Publishing

Renders as a static site (MkDocs Material) on Cloudflare Pages at wiki.bonbondino.com, behind Cloudflare Access (team emails only), and is linked from the bonbondino.com admin dashboard. scripts/wiki/build.sh builds; scripts/wiki/deploy.sh ships it (see scripts/wiki/DEPLOY.md). Never edit site/ — it's generated. Everything under wiki/ is real, editable content.

When adding a page: create it, add it to index.md, add it to nav: in mkdocs.yml.