Module 17 · Lesson 01

The Yungsten Wiki System — Obsidian Architecture for Client Orgs

Reading time: 18 minutes Track: Yungsten Tech Employee Curriculum · Required for all staff

Why Obsidian, why wikis

The wiki is the foundation of every Yungsten engagement. It's the organizational memory that persists between sessions, the reference document that makes the client's AI stack accessible to their whole team, and the primary way we provide value between our biweekly meetings.

We use Obsidian because:

• It stores files as plain markdown — no vendor lock-in, no subscriptions to maintain
• Claude can read Obsidian vaults directly via MCP, making the wiki part of the agent context
• It's local-first and can be synced via whatever tool the client already uses (iCloud, Obsidian Sync, Google Drive)
• The linking model (wiki links) creates the relationship graph that makes AI-assisted retrieval powerful

Standard vault structure

Every Yungsten client gets a vault with this starting structure:

/00 - Home
  - Dashboard.md          (entry point, links to everything)
  - Quick Reference.md    (most-used prompts and agent triggers)

/01 - Organization
  - About Us.md           (company overview, team, mission)
  - AI Stack.md           (what's deployed, what does what)
  - Data Classification.md (what data goes in AI tools)

/02 - Agents
  - [Agent Name].md       (one file per agent: spec, system prompt, runbook)

/03 - Prompts
  - [Category].md         (prompt library by use case)

/04 - Processes
  - [Process Name].md     (team processes that involve AI tools)

/05 - Sessions
  - YYYY-MM-DD.md         (notes from each Yungsten session)

/06 - Resources
  - Reading List.md
  - Glossary.md

Writing wiki entries for Claude consumption

When Claude reads the wiki via MCP, it reads markdown. Structure your entries with this in mind:

Use headers generously. Claude's attention is guided by structure. A well-headered entry is easier for Claude to navigate than dense prose.

Put the key fact first. Don't bury the most important information in paragraph 3. Lead with it.

Use explicit labels. "Owner: [name]" is more parseable than "This is managed by [name]."

Avoid pronouns in favor of entity names. "The Scout agent" is clearer than "it" when Claude is reading multiple pages.

Include "do not" sections explicitly. Claude respects explicit constraints in its context. A "Do Not" section in an agent's wiki entry is additional guardrailing beyond the system prompt.

Maintaining wiki quality

Wikis degrade if not maintained. The enemy is not neglect — it's stale information. A wiki with wrong information is worse than no wiki.

Three practices maintain quality:

1. Date every significant entry. "Updated: 2026-05-15" tells readers (human and AI) how fresh this is.
2. Flag when something changes. When a process updates, update the wiki immediately — not next week.
3. Archive rather than delete. Move outdated entries to /Archive with a note: "Replaced by [new entry] on [date]." Historical context is valuable.

The wiki as client capability

By the end of a Yungsten engagement, the client's wiki should be self-sustaining: the team can add entries, update existing ones, and onboard new members using the wiki without Yungsten involvement.

This capability is part of what we're building. We're not building a wiki — we're building the client's ability to run and extend their own AI knowledge base.