@simpleapps-com/augur-skills 0.0.18 → 0.0.21

package/skills/simpleapps/workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow
-description: How we track and deliver work. Covers the Basecamp-to-GitHub flow for client requests, task tracking, and cross-linking. Use when working on client tasks, creating issues, or checking assignments.
+description: How we track and deliver work. Covers the Basecamp-to-GitHub flow for client requests, task tracking, cross-linking, and issue templates. Use when working on client tasks, creating issues, or checking assignments.
 ---
 
 # Workflow
@@ -27,13 +27,41 @@ Basecamp todos and GitHub issues SHOULD cross-link (many-to-many — one todo MA
 
 ## Tooling
 
-The `basecamp` MCP server (bundled with this plugin) provides direct API access to Basecamp 2. Use MCP tools (`get_todo`, `list_my_todos`, `list_documents`, etc.) as the primary method. Chrome browser automation is the fallback if MCP is unavailable.
+Load `simpleapps:basecamp` for Basecamp MCP tools and Chrome fallback. Load `simpleapps:github` for `gh` CLI usage and org conventions.
 
-**First-time setup**: User MUST run `uv run basecamp-auth` once to authorize. Credentials are saved to `~/.simpleapps/basecamp.json`.
+## Creating Issues from Basecamp Todos
+
+Before creating an issue, gather context from Basecamp (see `simpleapps:basecamp` skill for full MCP tool reference):
+1. Use `get_todo` to read the Basecamp todo and summarize the client request
+2. Use `list_documents` + `get_document` to find the project's **site-info** document for siteId and domain name. If no site-info document exists, ask the user to create one in Basecamp.
+
+See the `simpleapps:github` skill for `gh` CLI usage and org conventions.
+
+Issue template for Basecamp-linked issues:
+
+```bash
+gh issue create --repo simpleapps-com/<repo> \
+  --title "<brief technical title>" \
+  --body "## Basecamp
+<basecamp_todo_url>
+
+## Client
+<client/project name> — <domain> (siteId: <siteId>)
+
+## Summary
+<technical summary of what needs to be done>
+
+## Acceptance Criteria
+- [ ] <criteria from the Basecamp request>"
+```
+
+## Cross-Linking
+
+- Include the Basecamp todo URL in the GitHub issue body (under a `## Basecamp` heading)
+- After creating the issue, provide the GitHub issue URL to the user so they can add it to the Basecamp todo comments
 
 ## References
 
-- See `basecamp.md` for MCP tools, Chrome fallback, and Basecamp navigation
-- See `github.md` for Basecamp-to-GitHub cross-linking
+- See `simpleapps:basecamp` skill for MCP tools, Chrome fallback, and Basecamp navigation
 - See `simpleapps:github` skill for GitHub org conventions and `gh` CLI usage
 - See `simpleapps:fyxer` skill for Fyxer meeting transcript processing and Basecamp posting

package/skills/simpleapps/fyxer/basecamp-index.md

@@ -1,110 +0,0 @@
-# Fyxer Index — Basecamp Document
-
-Each Basecamp project that receives Fyxer meeting transcripts MUST have a **Fyxer Index** document. This document serves as a fast lookup for duplicate detection and meeting history, accessible to all team members.
-
-## Document Format
-
-- **Title**: `Fyxer Index`
-- **Location**: Documents section of each Basecamp project
-- **Content**: One line per posted meeting, newest first
-
-Each line follows this format:
-
-```
-<meeting-uuid> | <date> | <message-id> | <subject>
-```
-
-Example:
-
-```
-52f0cf2b-fdb8-4e95-8b01-2afb6d367c69 | 2026-01-19 | 514789012 | Fyxer: 2026-01-19
-a1b2c3d4-e5f6-7890-abcd-ef1234567890 | 2026-02-10 | 514801234 | Fyxer: 2026-02-10
-d9e8f7a6-b5c4-3210-fedc-ba0987654321 | 2026-02-15 | 514823456 | Fyxer: 2026-02-15
-```
-
-Fields:
-
-| Field | Source |
-|-------|--------|
-| meeting-uuid | UUID from Fyxer URL (before the colon) |
-| date | Meeting date (YYYY-MM-DD) |
-| message-id | Basecamp message ID returned by `create_message` |
-| subject | Message subject as posted (e.g., `Fyxer: 2026-02-15`) |
-
-## Finding the Index
-
-```
-list_documents(project_id)
-```
-
-Scan for a document titled `Fyxer Index`. Use `get_document(project_id, document_id)` to read its contents.
-
-## Creating the Index
-
-If no `Fyxer Index` document exists in the project, create one before posting the first meeting:
-
-```
-create_document(project_id, "Fyxer Index", "")
-```
-
-This creates an empty document. The first meeting entry will be appended after posting.
-
-## Updating the Index
-
-After successfully posting a meeting transcript via `create_message`, append a new line to the index:
-
-1. Read the current index: `get_document(project_id, document_id)`
-2. Append the new entry to the content (newest first — add to the top)
-3. Update: `update_document(project_id, document_id, title="Fyxer Index", content=updated_content)`
-
-The `create_message` response includes the message ID needed for the index entry.
-
-## Duplicate Check
-
-Before posting a meeting transcript, check the index:
-
-1. Find the Fyxer Index document: `list_documents(project_id)` → scan for `Fyxer Index`
-2. Read it: `get_document(project_id, document_id)`
-3. Search the content for the meeting UUID
-4. If found → the meeting has already been posted. Inform the user and stop.
-5. If not found → safe to proceed with posting.
-
-If no Fyxer Index document exists, there are no posted meetings in this project. Proceed with posting and create the index.
-
-## Reconciliation — Missing Entries
-
-The index MAY fall out of sync if a meeting was posted without updating the index (e.g., manual posting, index creation after existing meetings). To reconcile:
-
-1. List all messages: `list_messages(project_id)`
-2. Filter for messages with `Fyxer:` in the title
-3. For each Fyxer message, call `get_message(project_id, message_id)` and extract the `fyxer-id` from the YAML frontmatter
-4. Compare against the index — add any missing entries
-5. Update the index document with the complete list
-
-Run reconciliation when:
-- The Fyxer Index document is first created in a project that already has Fyxer messages
-- The user suspects the index is incomplete
-- A duplicate check finds nothing but the user believes a meeting was already posted
-
-## Reconciliation — Orphaned Entries
-
-If an index entry references a message that no longer exists (deleted in Basecamp):
-
-1. Attempt `get_message(project_id, message_id)` for the entry
-2. If 404 → the message was deleted. Remove the entry from the index.
-3. Update the index document
-
-Only run orphan cleanup when explicitly requested by the user. Do not automatically delete index entries.
-
-## Updated Posting Process
-
-The full Fyxer → Basecamp posting process (see `basecamp.md`) now includes index management:
-
-1. **Check index** — find Fyxer Index doc, read it, search for meeting UUID
-2. **Check local cache** — if summary.txt and transcript.txt exist, skip extraction
-3. **Extract from Chrome** — if cache is missing (see `SKILL.md`)
-4. **Build message.txt** — frontmatter + transcript
-5. **Post to Basecamp** — `create_message` → capture message_id from response
-6. **Update index** — append new entry to Fyxer Index document (create doc if needed)
-
-Step 6 is new. If the index update fails after a successful post, warn the user — the message is posted but the index is stale. The user can run reconciliation later to fix it.

package/skills/simpleapps/fyxer/basecamp.md

@@ -1,91 +0,0 @@
-# Fyxer → Basecamp
-
-Post Fyxer meeting recordings as searchable Discussions in Basecamp projects.
-
-## Inputs
-
-- **Fyxer recording URL**: `https://app.fyxer.com/call-recordings/<meeting-uuid>:<calendar-event-id>`
-- **Basecamp project ID**: Target project for the Discussion
-
-## Process
-
-### 1. Check for duplicate
-
-Extract the meeting UUID from the Fyxer URL (the part before the colon).
-
-Find the **Fyxer Index** document in the project: `list_documents(project_id)` → scan for title `Fyxer Index`. If found, `get_document(project_id, document_id)` and search the content for the meeting UUID. If the UUID appears, the meeting has already been posted — inform the user and stop.
-
-If no Fyxer Index document exists, there are no tracked meetings in this project. Proceed with posting.
-
-See `basecamp-index.md` for full index format and reconciliation.
-
-### 2. Check local cache
-
-If `~/.simpleapps/fyxer/<meeting-uuid>/summary.txt` and `transcript.txt` both exist, skip to step 3. Otherwise, follow the Chrome extraction steps in `SKILL.md`.
-
-### 3. Build message.txt
-
-Parse `summary.txt` for frontmatter fields, extract participants (see `SKILL.md` participant extraction), and combine with the full transcript from `transcript.txt`:
-
-```
----
-meeting: SA/ClientName
-date: YYYY-MM-DD
-time: HH:MM-HH:MM
-participants: Person A, Person B, Person C
-topics: Topic One, Topic Two, Topic Three
-fyxer-id: <meeting-uuid>
----
-
-[contents of transcript.txt]
-```
-
-Frontmatter field sources:
-
-| Field | Source |
-|-------|--------|
-| meeting | Meeting title from the page header |
-| date | Recording date |
-| time | Recording time range |
-| participants | Participant dropdown (click to reveal names) |
-| topics | Section headings from the Summary |
-| fyxer-id | Meeting UUID from the URL (before the colon) |
-
-Save as `~/.simpleapps/fyxer/<meeting-uuid>/message.txt`.
-
-### 4. Post to Basecamp
-
-Use `create_message(project_id, subject, content)`:
-
-- **Subject**: `Fyxer: YYYY-MM-DD`
-- **Content**: contents of `message.txt`
-
-Capture the **message_id** from the response.
-
-### 5. Update Fyxer Index
-
-After a successful post, update the Fyxer Index document:
-
-1. If no Fyxer Index document exists, create one: `create_document(project_id, "Fyxer Index", "")`
-2. Read current content: `get_document(project_id, document_id)`
-3. Prepend a new line (newest first): `<meeting-uuid> | <date> | <message-id> | <subject>`
-4. Update: `update_document(project_id, document_id, title="Fyxer Index", content=updated_content)`
-
-If the index update fails after a successful post, warn the user. The message is posted but the index is stale. Run reconciliation later (see `basecamp-index.md`).
-
-## Format Rules
-
-- **Plain text only** — Basecamp prefers plain text over HTML
-- **YAML frontmatter** — machine-parseable so other Claude Code instances can search and parse meeting context
-- **Transcript only in body** — summary and action items belong on relevant Basecamp todos, not in this message
-- **Consistent title** — `Fyxer: YYYY-MM-DD` keeps messages uniform and sortable
-
-## Finding Posted Transcripts
-
-Check the index: `list_documents(project_id)` → find `Fyxer Index` → `get_document`
-View a specific transcript: `get_message(project_id, message_id)` using the message_id from the index
-Browse all messages: `list_messages(project_id)` — Fyxer posts use the title format `Fyxer: YYYY-MM-DD`
-
-## Dependencies
-
-- Basecamp MCP (`create_message`, `create_document`, `update_document`, `list_documents`, `get_document` tools) — see `simpleapps:workflow` skill (`basecamp.md`) for full MCP tool reference

package/skills/simpleapps/github/issues-prs.md

@@ -1,89 +0,0 @@
-# Issues & Pull Requests
-
-## Issues
-
-### Creating Issues
-
-MUST always use `--repo simpleapps-com/<repo>` to target the correct org. MUST ask the user which repo to create the issue in — never assume.
-
-### Issue Title
-
-- Use conventional commit style: `fix: description`, `feat: description`, `chore: description`
-- SHOULD be a technical description, not the client's words
-- Keep under 70 characters
-
-### Issue Body
-
-Every issue MUST include these sections:
-
-```markdown
-## Problem
-What is broken, missing, or needed? Include error messages, URLs, or screenshots if relevant.
-
-## Expected Behavior
-What SHOULD happen instead? Be specific.
-
-## Acceptance Criteria
-- [ ] Concrete, testable criteria
-- [ ] Each item is independently verifiable
-
-## Context
-Any additional info: related issues, affected files, workarounds, reproduction steps.
-```
-
-For bug reports, also include:
-- **Steps to Reproduce** — numbered steps to trigger the bug
-- **Current Behavior** — what actually happens (with error messages)
-
-### Labels
-
-Use labels to categorize: `bug`, `feature`, `enhancement`
-
-### Example
-
-```bash
-gh issue create --repo simpleapps-com/<repo> \
-  --title "fix: search endpoint returns 404" \
-  --body "$(cat <<'ISSUE'
-## Problem
-The `search` MCP tool returns HTTP 404 on every query. This prevents finding content across projects.
-
-## Expected Behavior
-Search SHOULD return matching results, consistent with the Basecamp web UI.
-
-## Acceptance Criteria
-- [ ] Search returns results for known content
-- [ ] Error handling for empty results
-
-## Context
-BCX API may not expose a search endpoint. Web UI search at `/search?q=...` works.
-ISSUE
-)"
-```
-
-### Managing Issues
-
-```bash
-gh issue list --repo simpleapps-com/<repo>                    # List open issues
-gh issue list --repo simpleapps-com/<repo> --state all        # Include closed
-gh issue view <number> --repo simpleapps-com/<repo>           # View issue details
-gh issue close <number> --repo simpleapps-com/<repo>          # Close issue
-gh issue close <number> --repo simpleapps-com/<repo> --comment "message"  # Close with comment
-```
-
-### Closing via Commit
-
-Include `Closes #N` in the commit message body to auto-close issues when pushed.
-
-## Pull Requests
-
-```bash
-gh pr create --repo simpleapps-com/<repo> --title "title" --body "description"
-gh pr list --repo simpleapps-com/<repo>
-gh pr view <number> --repo simpleapps-com/<repo>
-gh pr merge <number> --repo simpleapps-com/<repo>
-```
-
-## Cross-Linking with Basecamp
-
-When working on client tasks that originate in Basecamp, see the `simpleapps:workflow` skill for the full Basecamp-to-GitHub cross-linking process.

package/skills/simpleapps/github/project-structure.md

@@ -1,146 +0,0 @@
-# Project Structure & Wiki Workflow
-
-## Local Layout
-
-Every project MUST use this layout:
-
-```
-{project}/
-├── repo/           # Main git repo (simpleapps-com/<name>.git)
-├── wiki/           # GitHub wiki repo (simpleapps-com/<name>.wiki.git)
-├── wip/            # Work-in-progress files for active tasks (not in git)
-└── .simpleapps/    # Project-level secrets and credentials (not in git)
-```
-
-The parent `{project}/` directory is NOT a git repo — it's a local wrapper that keeps the code repo and wiki side-by-side. The `wip/` and `.simpleapps/` directories sit outside both git trees so their contents can never be accidentally committed.
-
-## Why This Pattern
-
-- GitHub wikis are separate git repos. Cloning them alongside the code keeps everything local and searchable.
-- AI agents (Claude Code) can `Read` wiki files from disk instantly instead of fetching URLs.
-- The wiki becomes the **source of truth for dev docs**. The repo stays focused on product code.
-
-## Setting Up a New Project
-
-```bash
-mkdir {project}
-cd {project}
-git clone https://github.com/simpleapps-com/<name>.git repo
-git clone https://github.com/simpleapps-com/<name>.wiki.git wiki
-```
-
-If the wiki repo doesn't exist yet, create it by adding any page via the GitHub wiki UI first, then clone.
-
-## What Goes Where
-
-| Content | Location | Examples |
-|---------|----------|---------|
-| Product code | `repo/` | Source, tests, configs, SKILL.md files |
-| Dev documentation | `wiki/` | Architecture, guides, specs, conventions |
-| Repo README | `repo/README.md` | Minimal — quick start + link to wiki |
-| Repo `.claude/rules/` | `repo/` | Minimal summaries referencing wiki pages |
-| Repo `.claude/CLAUDE.md` | `repo/` | Quick reference + wiki links |
-| Active task context | `wip/` | WIP files for Basecamp todos or GitHub issues |
-| Project secrets | `{project}/.simpleapps/` | Site-specific credentials, `{siteId}.json` |
-| Global secrets | `~/.simpleapps/` | Shared credentials across all projects |
-
-Rule of thumb: if a `.md` file isn't built into the end product, it belongs in the wiki. If it contains secrets or ephemeral task state, it belongs outside both git trees.
-
-## WIP Directory
-
-The `wip/` directory holds work-in-progress files that AI agents create when picking up tasks from Basecamp or GitHub issues. Each file tracks research, plans, and progress for an active task.
-
-### Naming Convention
-
-`{issue-number}-{short-description}.md` — e.g., `14-basecamp-mcp-auto-refresh-oauth.md`
-
-### Lifecycle
-
-1. Agent picks up a Basecamp todo or GitHub issue
-2. Creates a WIP file with research findings and implementation plan
-3. Updates the file as work progresses
-4. File remains after completion as a record of decisions made
-
-### What belongs in WIP
-
-- Research findings and code analysis
-- Detailed implementation plans
-- Decision rationale
-- Test results and verification notes
-
-### What does NOT belong in WIP
-
-- Secrets, credentials, or tokens (use `.simpleapps/`)
-- Final documentation (use `wiki/`)
-- Code (use `repo/`)
-
-## Credentials (`.simpleapps/`)
-
-Secrets and credentials live in `.simpleapps/` directories at two levels:
-
-- **`~/.simpleapps/`** (user-level) — shared credentials across all projects (e.g., `augur-api.json`, `basecamp.json`)
-- **`{project}/.simpleapps/`** (project-level) — credentials specific to that project (e.g., `{siteId}.json` with test user creds)
-
-Project-level credentials override user-level ones when both exist. Both directories sit outside git trees so nothing can be accidentally committed.
-
-MUST NOT be committed to any git repository. MUST NOT be copied into `repo/` or `wiki/`.
-
-## Referencing Wiki from Repo
-
-Repo files SHOULD use **relative filesystem paths** to reference wiki content:
-
-```markdown
-Full docs: ../../../wiki/Versioning.md
-```
-
-Relative paths work for Claude Code (local file reads). GitHub URLs require network access and are slower.
-
-## Wiki Conventions
-
-### Page Naming
-
-- Use **PascalCase** with hyphens: `Getting-Started.md`, `Plugin-Structure.md`
-- Match the pattern used in GitHub wiki URLs: `wiki/Page-Name`
-
-### _Sidebar.md
-
-Every wiki MUST have a `_Sidebar.md` for navigation. Group pages by topic:
-
-```markdown
-**[[Home]]**
-
-**Getting Started**
-- [[Getting-Started]]
-
-**Architecture**
-- [[Architecture]]
-- [[Plugin-Structure]]
-
-**Development**
-- [[Development]]
-- [[Versioning]]
-```
-
-### Linking
-
-- Use `[[Page-Name]]` wiki links for internal links (renders on GitHub wiki)
-- Use `[[Display Text|Page-Name]]` for custom link text
-
-### Content Guidelines
-
-- Wiki pages are the **full, detailed** version of documentation
-- Each page SHOULD be self-contained — don't assume the reader has seen other pages
-- Include examples, code blocks, and tables where they help
-- Use RFC 2119 keywords (MUST/SHOULD/MAY) for requirements
-
-### Committing Wiki Changes
-
-The wiki is a regular git repo. Commit and push like any other:
-
-```bash
-cd {project}/wiki
-git add -A && git commit -m "docs: add architecture page"
-git push origin master
-```
-
-Note: GitHub wikis typically use `master` as the default branch, not `main`.

package/skills/simpleapps/github/wiki-as-context.md

@@ -1,161 +0,0 @@
-# Wiki as Context
-
-The GitHub wiki is the **single source of truth** for how a project works. It is not an afterthought or a place to dump notes — it is the primary context that drives development.
-
-## The Problem
-
-Documentation scattered across a codebase creates friction:
-
-- `.claude/rules/` files, README.md, inline comments, and docs/ folders all compete as sources of truth
-- AI agents waste tokens reading large files to find relevant context
-- New team members don't know where to look
-- Docs rot because they live next to code and get forgotten
-
-## The Solution
-
-The wiki is the **spec**. The repo is the **implementation**.
-
-| Wiki | Repo |
-|------|------|
-| Architecture decisions | Code that implements them |
-| API specs | API code |
-| Conventions and standards | Code that follows them |
-| Onboarding guides | Nothing — wiki is self-contained |
-| Release processes | Automation scripts |
-| Full explanations | Minimal pointers back to wiki |
-
-## How It Works
-
-### 1. Wiki First
-
-When starting new work, check the wiki first. If the wiki doesn't cover it, write the wiki page before writing code. The wiki defines *what* and *why*. The code implements *how*.
-
-### 2. Repo References Wiki
-
-Repo files (`.claude/CLAUDE.md`, `.claude/rules/`, `README.md`) SHOULD be **minimal** — just enough to orient, then point to the wiki for details.
-
-```markdown
-# Versioning
-
-Full docs: ../../../wiki/Versioning.md
-
-`VERSION` file = source of truth. All version fields MUST match.
-```
-
-### 3. AI Agents Read Wiki Locally
-
-Because the wiki is cloned alongside the repo (see `project-structure.md`), AI agents read wiki pages as local files. No network requests, no URL fetching — just `Read ../../../wiki/Architecture.md`.
-
-This means wiki pages are both human documentation AND machine context.
-
-### 4. Wiki Evolves with the Project
-
-The wiki is not write-once. As the codebase changes:
-
-- Update affected wiki pages in the same work session
-- Add new pages when new patterns emerge
-- Remove pages when features are deprecated
-- Keep the `_Sidebar.md` current
-
-## Three Audiences
-
-Every wiki page serves three audiences simultaneously:
-
-| Audience | What they need | How they read |
-|----------|---------------|---------------|
-| **Junior devs** | Explanations of *why*, step-by-step instructions, examples they can copy | Top to bottom, following links for context |
-| **Senior devs** | Quick reference, architecture decisions, conventions to follow | Scan for the section they need, skip the rest |
-| **AI agents** | Unambiguous specs, exact commands, clear requirements (MUST/SHOULD/MAY) | Load the full wiki into context, act on it |
-
-### Writing for All Three
-
-- **Lead with a summary** — seniors and agents get what they need fast, juniors get orientation
-- **Explain the *why* before the *how*** — juniors learn the reasoning, seniors confirm their assumptions, agents get decision context
-- **Use tables for reference data** — scannable for seniors, parseable for agents, structured for juniors
-- **Use code blocks for anything copy-pasteable** — all three audiences benefit from exact commands
-- **Use RFC 2119 keywords (MUST/SHOULD/MAY)** — removes ambiguity for everyone, especially agents
-- **Include examples** — juniors learn by example, agents use them as patterns
-
-### Keep Pages Self-Contained
-
-Each page SHOULD make sense on its own. A junior dev landing on any page SHOULD be able to understand it without reading the rest of the wiki.
-
-### Follow the Writing Style Skill
-
-All wiki content MUST follow the `simpleapps:writing-style` skill:
-
-- **RFC 2119 keywords** — MUST/SHOULD/MAY in ALL CAPS for requirements, lowercase for casual suggestions
-- **Token efficiency** — action verbs first, no filler, specific over generic, Bottom Line Up Front
-- **Developer-facing tone** — technical and concise, include file references and acceptance criteria
-- **Expand for onboarding and architecture** — juniors and future devs need the "why"
-- **Cut everywhere else** — two sentences that answer the question beat two pages that fill the context window
-
-The wiki is developer-facing documentation. It is NOT client-facing. Write for devs and AI agents, not for non-technical readers.
-
-### Link with Anchor Precision
-
-When referencing other wiki pages, MUST link directly to the relevant section using `#` anchors — not just the page.
-
-```markdown
-# Good — links to exact section
-See [[Versioning#version-bump-procedure]] for the step-by-step process.
-Check [[Architecture#three-layers]] for how marketplace, plugins, and CLI relate.
-
-# Bad — links to top of page, reader has to hunt
-See [[Versioning]] for details.
-Check [[Architecture]] for more info.
-```
-
-This matters for two reasons:
-- **Devs** jump straight to the answer instead of scrolling through a page
-- **AI agents** use anchor links as an attention signal — a `#section` reference tells the agent exactly which part of a page is relevant to the current task, reducing noise in a 20K token wiki
-
-### Keep It Lean
-
-Wikis SHOULD be as small as possible while remaining complete. The goal: an AI agent can load the **entire wiki** into context at session start and keep it there throughout.
-
-Guidelines:
-- Tighten language — cut filler, use tables over prose
-- Merge overlapping pages
-- Document patterns and principles, not exhaustive implementation details (see `wiki-maintenance.md`)
-- Archive obsolete pages (delete, don't hoard)
-- Move implementation specifics back to code comments where they belong
-
-To check wiki size:
-```bash
-wc -c {project}/wiki/*.md
-```
-
-Rough conversion: 1 token ≈ 3 bytes of markdown.
-
-### Right-Size Each Page
-
-- Too short = missing context, agent has to search elsewhere
-- Too long = wasted tokens, buried signal
-- Target: enough to act on without reading anything else
-
-## The Feedback Loop
-
-```
-Wiki defines → Code implements → Learnings update wiki → Repeat
-```
-
-When code reveals that the wiki is wrong or incomplete, update the wiki immediately. The wiki MUST reflect reality, not aspirations.
-
-## When to Update the Wiki
-
-- **New feature** — Write the wiki page first (spec), then implement
-- **Bug fix** — If the fix reveals a gap in documentation, update the wiki
-- **Architecture change** — Update Architecture page before or during the change
-- **New convention** — Add to the relevant wiki page so the team adopts it
-- **Onboarding friction** — If someone asks "where is X?", the answer should be a wiki link. If it's not, create the page.
-
-## Anti-Patterns
-
-| Don't | Do |
-|-------|-----|
-| Write long README.md files in the repo | Minimal README + wiki link |
-| Duplicate wiki content in `.claude/rules/` | Thin rules that reference wiki |
-| Leave wiki pages stale after code changes | Update wiki in the same session |
-| Use the wiki as a dumping ground for notes | Structure pages with clear purpose |
-| Write wiki pages only humans can understand | Write for both humans and AI agents |