Every page under wiki/ is read in two places: Obsidian, and GitHub. Follow each step before you finish the edit.

1. Edit in your own worktree

Write pages with Edit or Write in the current worktree. Never use the Obsidian MCP write tools (create_vault_file, patch_vault_file, search_and_replace, …) or obsidian create / append / property:set: both target the main worktree's wiki/, not your branch.

2. Put the page in the right folder

The folders mirror the monorepo. Choose by who the page is about, not what kind of page it is:

Product folders stay flat; the page's tags say whether it is a system or a runbook. Filenames stay unique across the whole vault, so a product page that could collide takes the product prefix (cire-auth, pulse-onboarding). The one exception is a folder's index or README: both names exist twice, and a bare [[index]] or [[README]] resolves to the page at the vault root. A page that starts in one product and later applies to two moves to shared/.

Moving a page keeps a bare [[page-name]] link working, because it resolves by filename. A link written with a folder, such as [[dpia/cire-guest-data]], breaks, and so does every repo path that cites the page — code comments, skills, AGENTS.md and issue bodies. bun scripts/check-wikilinks.ts finds the broken wikilinks; find the repo paths with grep -rn "wiki/<old-folder>/<name>" .. Fix both in the same pull request.

3. Load the syntax skill

Invoke obsidian:obsidian-markdown before writing. It is the syntax authority for this vault — wikilinks ([[Note#Heading]], [[Note#^block-id]], [[Note|alias]]), embeds, callouts, properties, nested tags, %%comments%%, ==highlights==, and mermaid nodes that link to notes. Half of it is not CommonMark, so do not guess.

4. Write for both surfaces

Use tables and mermaid for anything a GitHub reader needs. A .base or .canvas adds to a page's prose and never replaces it: remote and CI sessions only have grep.

5. Frontmatter and links

• Every page has YAML frontmatter with title, tags, related and last-reviewed. Set last-reviewed to today on every page you touch, except where the only change is a mechanical find-and-replace across many pages: nobody read those pages, so their date stays.
• Frontmatter describes the page, never a task: no finding IDs or per-PR keys.
• Link between pages with [[wikilinks]], never relative markdown links. Link to a source file with a relative markdown link from the page's directory. Cire pages carry a cire- prefix where a bare name would collide.
• A page links to at least two others.
• A new page gets a line in wiki/index.md, in the right section. Product-specific build rules go in wiki/<product>/<product>-development.md, never a nested AGENTS.md or CLAUDE.md; a fact true of more than one product belongs in frontend-patterns, backend-patterns or testing-patterns.
• A changed pattern updates its page in the same pull request.

6. State the present

A page says what is true now. No "used to", "was moved", "the first attempt" — git log holds history. A reason that stops a mistake stays.

7. A sentence you edit is a sentence you vouch for

When an edit changes one fact in a sentence or table row, the other claims in that sentence or row are yours to check too. Either check each one against the code, or narrow the edit to the words that change. Four misses from a branch that rewrote the production deploy path:

• shared/production-deploy.md §3.4 named three builds that read the Turnstile sitekey. Only one does. Following the list breaks sign-in.
• cire/cire.md kept "cire-web / organiser Pages" and two archived migrations.
• shared/production-deploy.md §4.3 kept "dev and staging, which no CI job touches". CI now migrates dev.
• The §5.0 table kept "(no public route yet)" for zap, which serves zap.cireweddings.com.

Each one sat in a line the branch had already rewritten. Re-read the whole sentence or row before you finish.

8. Numbers

Two kinds, written differently.

• A documented ceiling is a provider's published limit. Leave it in prose and name the pricing page.

• A measured figure is ours, and nobody can check it without running something. Put the command and date on the line under it, as visible italic text — an HTML comment renders on neither surface:

  A full dev rebuild costs **8,007 D1 rows written**.
  
  *Measured 2026-09-10 — `bunx wrangler d1 insights cire-db-dev --time-period=7d --sort-by=writes`*

  Where no single command produces it, name the method (Measured 2026-08-31 — latency probe from a Sydney client, n=25). Where the method or date is unknown, write *Unverified — …*, say what you do know, and leave the figure alone. Never invent a command.

last-reviewed means someone read the page, not that its numbers are true; the measured marker is what a reader re-runs.