# Wikismith > Maintains a persistent personal knowledge base (wiki) on the local filesystem using Karpathy's LLM Wiki pattern and Forte's PARA and CODE methods. Trigger when the user wants to build or query a knowledge base, capture notes or sources, or produce output from accumulated knowledge. Key phrases: "my wiki", "add this to my wiki", "capture this", "distill", "what do I know about X", "write a draft from my notes". - Skill: `dougcallaway/wikismith` (Agent Skill, multi-file: 10 files) - Install (CLI): `npx skillmds@latest add dougcallaway/wikismith` - Raw SKILL.md: https://api.skillmd.com/api/skills/dougcallaway/wikismith/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: dougcallaway (https://skillmd.com/u/dougcallaway) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dougcallaway/wikismith --- # Wikismith An agent-maintained personal knowledge base. The agent does all the writing and bookkeeping; the user does the sourcing and thinking. See README.md for conceptual background. Throughout this document, **"the agent"** means whichever AI agent is running this skill. Claude Code is the tested reference; any Agent Skills–compatible tool that can read and write files should work. --- ## Directory layout ``` / ├── capture/ # All incoming content — quick captures and source documents │ └── assets/ # Locally downloaded images ├── wiki/ # agent-maintained markdown pages │ ├── index.md # Content catalog — read first on every query │ ├── log.md # Append-only chronological record │ ├── overview.md # High-level synthesis of the whole wiki │ ├── projects/ # Active deliverables (one folder per project) │ ├── areas/ # Ongoing responsibilities │ ├── resources/ # Shared reference-document pool │ └── archive/ # Inactive projects/areas (created on demand) └── schema.md # The schema — wiki conventions and domain config ``` ### Organizing model Three orthogonal axes make the wiki easy to browse and query for both humans and machines: | Axis | Encoded by | |------|-----------| | **Location** | **PARA bucket** (project/area/resource/archive) — the directory the page lives in | | **Links** | **Cross-references** from effort pages (projects/areas) to the resources they depend on | | **Tags** | **Namespaced tags** (e.g. `technology/x`, `vendor/y`) drawn from `schema.md`'s `## Tag vocabulary` | Analyses and member pages live **inside** their owning project/area folder. `schema.md` is authoritative on all conventions. **The agent maintains everything in `wiki/` and never modifies `capture/`. All of it belongs to the user.** **The capture directory is `capture/` by default.** `schema.md`'s `## Capture` section may rename it or point at a folder the user already saves into (a web clipper's target, for example). Wherever it lives, the operation is still Capture and the items are still captures — throughout this document, `capture/` means the configured capture directory. If it lies outside the wiki root, git in the wiki root won't track it; cover it with rclone or its own backup. And if it points at a folder inside another git repository (an already-tracked Obsidian vault, say), leave that repository's ignore rules alone — they aren't this wiki's to configure. `capture/` holds two kinds of content: - **Quick captures** — timestamped notes/links/quotes dropped in without processing, named `-.md` - **Source documents** — articles, PDFs, transcripts, and other raw material ready to organize Both are immutable once written. --- ## Startup: finding or creating a wiki When the user invokes this skill, the agent should: 1. **Locate the wiki root.** Check if a `schema.md` or `wiki/index.md` exists in the current directory or a parent. If found, that's the wiki root — read `schema.md` and `wiki/index.md` to orient. **Never the skill's own repository:** the folder holding this `SKILL.md` (the repo the skill was installed from) is not a wiki root, and its files are not a schema — if invoked there, say so and ask where the wiki should live. **Legacy fallback:** a wiki created with an earlier version names its schema file `CLAUDE.md`. If `schema.md` is absent but `CLAUDE.md` exists at the root, use `CLAUDE.md` as the schema and offer once to rename it to `schema.md` (an ordinary file any agent reads, not just Claude Code). 2. **If no wiki exists,** ask the user: - What topic/domain is this wiki for? - Where should the root directory live? Then initialize the structure (see **Init** below). 3. **If ambiguous** (multiple candidates), ask the user which one. --- ## Init When creating a fresh wiki: ```bash mkdir -p /capture/assets /wiki ``` If the user wants captures somewhere else — or already has a folder a clipper saves into — skip creating `capture/` and record the location in `schema.md`'s `## Capture` section instead. Create `/schema.md` using the following template, filled in with the user's domain details: ```markdown # — Wiki Schema ## Domain ## Page types - **entity** — a person, organization, model, tool, or named thing - **concept** — an idea, technique, or principle - **source** — a processed reference document (article, paper, transcript, note); lives in `resources/` - **analysis** — a comparison, synthesis, decision doc, or express output; owned by one area/project - **overview** — a high-level synthesis page ## Organizing model Three orthogonal axes make the wiki easy to browse and query for both humans and machines: | Axis | Encoded by | |------|-----------| | **Location** | **PARA bucket** (Projects/Areas/Resources/Archives) — the directory the page lives in | | **Links** | **Cross-references** from effort pages (projects/areas) to the resources they depend on | | **Tags** | **Namespaced tags** (e.g. `technology/x`, `vendor/y`) drawn from `## Tag vocabulary` below | ## Frontmatter fields All pages use: `type`, `title`, `tags` (namespaced topics only, from `## Tag vocabulary` below), `last_updated`, `source_count`, `distill_level` ## Domain-specific notes ## Tag vocabulary Namespaced topic tags only. Add here before using; one canonical spelling per concept. People and companies are entities (a page + a link), not tags. ### technology/ ### vendor/ ### process/ ## Writing style Base: ## Capture Directory: capture/ ## Backup Pattern: Command: rclone sync : ``` Also create `/wiki/projects/`, `areas/`, `resources/` directories. Create `/wiki/index.md`: ```markdown # Index _Last updated: _ ## Resources | Page | Summary | Date | |------|---------|------| ## Entities ## Concepts ## Analyses _Grouped by parent area/project._ ``` Create `/wiki/log.md`: ```markdown # Log ## [] init | Wiki created Domain: ``` Create `/wiki/overview.md` as a brief placeholder. Finally, check whether the wiki root is already inside a parent git repo. **If it is, do not offer git setup** — a nested repo is rarely intended. **If it isn't**, ask the user: *"Do you want to track this wiki with git version control? It keeps a full history, so you can see what changed and restore any earlier version of any page. If unsure, say yes — it's invisible day to day, and it gives you undo."* If yes, read `setup-git.md` and follow its setup steps. Then ask about cloud backup: *"Do you want to back up this wiki to cloud storage via rclone? Options: (1) binaries only — rclone backs up your raw capture files, and git covers the wiki pages (pushed to a remote like GitHub); (2) full repo — rclone syncs everything including git history, no GitHub needed (good for single-user wikis); (3) rclone only — no git, rclone is your only backup. Or skip for now."* If the user chooses a pattern, read `setup-rclone.md`, ask for the rclone remote name and destination path, then add a `## Backup` section to `schema.md`: ``` ## Backup Pattern: Command: rclone sync : ``` For **binaries-only**, `` is the capture directory (default `/capture/`). For **full-repo** and **rclone-only**, it is `/`. If the user skips backup setup, omit the `## Backup` section entirely. If git was set up **and** an rclone pattern was chosen, also create the post-commit hook (see `setup-rclone.md` for the hook script). Skip this step for the **rclone-only** pattern (no git, no hook). --- ## Operations ### Capture Triggered by: "capture this", "quick note", "save this for later", "add to inbox", or any short idea/link/quote the user tosses over without asking for full processing. **Flow:** 1. Save the item to `capture/-.md` with minimal structure: ```markdown --- captured: source: --- ``` 2. Confirm: "Captured to capture/. You have N unprocessed items — want me to organize any?" --- ### Organize _(O in CODE)_ Triggered by: "organize this", "process my inbox", "add this to the wiki", "read this article/paper/transcript", dropping a file in `capture/`, or pasting content directly with the intent to integrate it. **Flow:** 1. **Read the source.** If it's in `capture/`, read it from there. If pasted, save to `capture/.md` first. 2. **Discuss with the user** — but only if the content is surprising, contradicts existing wiki pages, or the user's intent is unclear. Surface one key takeaway and ask one focused question at most. Skip discussion entirely if: the user pasted content directly and gave no other instruction, the user said "just organize it", or the source is straightforward (a single clear topic, no contradictions). Default is to proceed, not to ask. 3. **Read `wiki/index.md`** to understand what already exists. 4. **Assign topic tags + note which efforts it serves.** Scan `schema.md`'s `## Tag vocabulary` for existing namespaced tags. Choose the topics that fit, adding new ones to `schema.md` first. Separately, note which projects/areas the document serves — record that as forward links on those project/area pages (step 6), not as a tag. Confirm briefly if unclear: > "Topics `vendor/tektelic` + `technology/lorawan`; serves `project/migration`. OK?" 5. **Write a source summary page** in the reference pool — `wiki/resources/.md` (`schema.md` is authoritative on the pool's folder name and conventions): ```markdown --- type: source title: date_organized: <date> tags: [vendor/tektelic, technology/lorawan] distill_level: 0 --- # <Title> **Summary:** <2–4 sentence synthesis> **Key claims:** bullet list **Cross-references:** links to entity/concept pages this touches ``` 6. **Update existing wiki pages** that this source extends, contradicts, or enriches. A single source typically touches 5–15 pages. For each affected page: - Add new information - Note contradictions inline: `> ⚠️ Contradiction: <source> says X, but <other> says Y` - **For each project/area page that uses this source:** add a forward cross-reference link to the source page (e.g. in a "Resources" or "References" section). This is how the resource-effort relationship is recorded — on the effort side, not on the resource. 7. **Create new pages** for any entity, concept, or theme that appears significantly in the source and doesn't have a page yet. File each in the right bucket directory. 8. **Update `wiki/index.md`** — add the source to the sources table, add/update entries for any new or significantly changed pages. 9. **Append to `wiki/log.md`**: ``` ## [<date>] organize | <Source Title> Pages updated: <list> New pages: <list> ``` **If a `.git` directory exists in the wiki root**, suggest: `git add . && git commit -m "organize: <Source Title>"`. Wait for user confirmation before running. 10. **If the source came from `capture/`,** leave it in place — `capture/` is immutable. The wiki now contains the processed knowledge; the capture file is its provenance. 11. **Optionally update `wiki/overview.md`** if the source meaningfully shifts the overall synthesis. --- ### Distill _(D in CODE)_ Triggered by: "distill this page", "distill my notes on X", "progressive summary", or automatically suggested by the agent when a page reaches 5+ sources. **Not** triggered by questions like "what are the key ideas on X" — that's a Query. Forte's progressive summarization: each pass bold-highlights the most important sentences, then a further pass extracts those into a short executive summary at the top. The agent applies this to wiki pages. **Flow:** 1. **Identify pages to distill.** Either the user names a page/topic, or the agent suggests candidates: pages with high `source_count`, pages last distilled long ago, or pages the user is about to use for Express. 2. **Read the page** and its current `distill_level` (0 = raw, 1 = bolded, 2 = summary added, 3 = condensed). 3. **Apply the next distillation level:** - **Level 0 → 1:** Bold the most important phrases and sentences (≈20% of content). Don't remove anything yet. - **Level 1 → 2:** Add a `## ✦ Distilled Summary` block at the top — 3–5 bullets capturing the essential claims. The full content remains below. - **Level 2 → 3:** Condense the body, removing detail that is fully captured in the summary. Preserve anything the summary doesn't cover. The page should now be significantly shorter without losing meaning. 4. **Update `distill_level`** in frontmatter and `last_distilled` date. 5. **Show the user the before/after** for approval before writing. Or if the user said "just distill it", write directly. 6. **Append to log:** ``` ## [<date>] distill | <Page Title> Level: <N> → <N+1> ``` **If `.git` exists in the wiki root**, suggest: `git add . && git commit -m "distill: <Page Title> (level <N>-><N+1>)"`. Wait for user confirmation before running. --- ### Express _(E in CODE)_ Triggered by: "write a draft about X", "create a report on Y", "I need to make a decision about Z", "turn my wiki into something I can share/publish/send". The key signal is a finished artifact for an audience or purpose outside the wiki. **Not** triggered by "summarize what I know about X" — that's a Query. Every Express output is a starting draft: the agent assembles it from the wiki; the user reviews, finishes, and owns it. **Flow:** 1. **Clarify the output type** if not obvious: - **Draft** (blog post, essay, article) — flowing prose, argument-led - **Report** (research summary, briefing) — structured, comprehensive, cited - **Decision doc** (options + recommendation) — problem statement, options, criteria, recommendation, risks The agent picks the most fitting type based on context and confirms briefly. 2. **Read `wiki/index.md`** and pull all relevant pages — prioritize pages with high `distill_level` (already refined) and pages in the relevant project/area folder or tagged with related topics. If key pages are at `distill_level` 0, suggest distilling first. 3. **Apply the user's voice, then draft.** If a voice profile exists (see **Calibrate**), load the base `wiki/style.md`, then layer the named profile matching the output type on top — `schema.md`'s `## Writing style` maps types to profiles; the named profile wins on conflicts, and "do not" rules from both apply. Draft the output in that composed voice, drawing on wiki content with inline citations to source pages. Do not reproduce wiki content verbatim — synthesize and rewrite for the target format. Before finalizing, run the draft against the **union of both files' Hard rules** and fix any violations. If no profile exists, write in a clean neutral voice, then offer once: *"Want me to calibrate a writing-style profile so future drafts sound like you?"* 4. **Determine the filing location.** Every analysis belongs to exactly one area or project — the one it serves. Infer it from context (the user's active project, the folder/topics of the source pages used) and confirm briefly if unclear: > "I'll file this under `project/methanetrack-infra-migration` — correct?" 5. **For drafts/reports:** write the output **inside that project/area's folder** alongside its `index.md` (e.g. `wiki/projects/<name>/<slug>.md`, `wiki/areas/<name>/<slug>.md`), and give it namespaced topic tags. Promote a flat area/project page to a folder if needed. `schema.md` is authoritative on placement. Then update index + log. 6. **For decision docs:** use this structure: ```markdown ## Decision: <Question> **Context:** ... **Options:** | Option | Pros | Cons | |--------|------|------| **Criteria:** ... **Recommendation:** ... **Risks & open questions:** ... **Sources:** links to wiki pages used ``` File it under its parent, same as drafts/reports (step 5). 7. **Link the analysis from its parent page** (an "Analyses" section on the area/project page) so it isn't an orphan, and add it under the matching parent group in `wiki/index.md`. 8. **Append to log:** ``` ## [<date>] express | <Output Title> Type: draft | report | decision Parent: <area-or-project> Filed: <path to the analysis> Sources used: <list of wiki pages> ``` **If `.git` exists in the wiki root**, suggest: `git add . && git commit -m "express: <Output Title>"`. Wait for user confirmation before running. **External references:** When citing code, PRs, or artifacts outside the wiki, prefer stable pointers over fragile ones. A branch name or local file path will go stale; a commit hash + path or a full URL to a specific revision will not: - Stable: `https://github.com/org/repo/blob/abc1234/src/auth.py`, a PR link, a tagged release - Fragile: `/path/to/repo/src/auth.py`, a branch name, a bare line number --- ## Utilities Operations that support the wiki but are not part of the CODE workflow. --- ### Query Triggered by: a question about the wiki's domain — "what does my wiki say about X", "what do I know about Y", "compare X and Y", "what's the connection between X and Z". The key signal is retrieval and synthesis in chat, not producing a finished artifact (that's Express) and not improving a page (that's Distill). **When the intent is ambiguous** (e.g. "summarize what I know about transformers"), ask one question before proceeding: *"Is this for your own reference, or a finished artifact for someone else?"* — and route to Query or Express accordingly. **Flow:** 1. **Read `wiki/index.md`** to find relevant pages. 2. **Read those pages** — up to 5–7 pages maximum. Prioritize pages whose titles most directly match the query; follow links only if the linked page is clearly necessary to answer. On large wikis, breadth-first reading without a cap can silently exhaust the context window. 3. **Synthesize an answer** in chat with citations to wiki pages (relative links). 4. **Offer to file non-trivial answers back** — if the answer involved a comparison, a connection, or an analysis the user hadn't made explicit: > "Want me to save this as a wiki page? It would live inside its parent area/project, > e.g. `wiki/projects/<name>/<slug>.md`." If yes, write it as an analysis (namespaced topic tags, file it inside the owning project/area's folder per the Express rules) and update the index + log. If the answer is outward-facing (something the user will share or send), apply the voice profile per Express step 3. **If the answer was filed and `.git` exists in the wiki root**, suggest: `git add . && git commit -m "express: <Answer Title>"`. Wait for user confirmation before running. (Use `express:` since a filed query answer is conceptually an express output.) **Output formats:** Prose by default. Tables for comparisons. Lists for timelines. If the answer is dense enough to be reused, offer to write it as a full wiki page — at that point it's become an Express output. --- ### Calibrate Triggered by: "make this sound like me", "set up my writing style", "learn my voice", "calibrate my style", or the agent offering after an uncalibrated Express output. Builds and refines a **voice profile** that Express applies to outputs so they sound like the user. Profiles affect **outputs only** — never internal entity/concept/source pages. **Base + overrides.** Shared preferences live once in a base profile; named voices carry only what differs: - **`wiki/style.md`** — the base layer. Preferences true of everything the user writes (banned words, formatting rules, general diction). If a wiki only ever needs one voice, this is the whole profile. - **`wiki/style/<name>.md`** — named voices (e.g. `blog`, `formal`) that carry **only the delta** from the base: the tone, rhythm, or structure that differs in that context. They do not repeat base rules. Express composes them: load `style.md`, then layer the selected named profile on top, with the named profile winning on conflicts. **"Do not" rules accumulate** — base prohibitions always apply, and a named profile may add more (the enforced **Hard rules** checklist is the union of both). A named profile cannot silently drop a base prohibition; keep a rule in the base only if it is genuinely universal, and put context-specific bans in the named profile. If a named voice truly needs to lift a base ban, state it explicitly, e.g. `Allowed (overrides base): contractions`. Profiles are registered in `schema.md`'s `## Writing style` section. **Flow:** 1. **Pick the input mode:** - **From samples (preferred).** Ask the user to drop 2–3 representative samples (past posts, emails, a doc they like) into `capture/`. Read them and extract recurring patterns: diction, sentence rhythm, structural habits, signature phrases, and — just as important — what they avoid. - **From description.** The user describes their preferences directly; the agent drafts the profile from that. 2. **Write the profile** using the template below. Make every entry a concrete, checkable directive — not a vague adjective like "professional". The **Hard rules** section is the checklist Express runs each draft against. When adding a named voice, put a preference in the base (`style.md`) only if it should hold everywhere; otherwise put it in the named profile so the base stays universal and the named file stays a small delta. 3. **Register it** in `schema.md`'s `## Writing style` section: list the profile, and for named profiles which output type maps to it (e.g. `draft → blog`, `report → formal`). 4. **Confirm with a quick test.** Offer to rewrite a short passage — a sample the user gave, or a paragraph from a recent Express output — in the new voice so they can sanction it before it's used for real. 5. **Append to log:** ``` ## [<date>] calibrate | <profile name> Source: samples | description ``` **If `.git` exists in the wiki root**, suggest: `git add . && git commit -m "calibrate: <profile name>"`. Wait for user confirmation before running. **Refining over time:** When the user edits an Express draft, notice the pattern and offer to fold it back in — *"You cut every em-dash and tightened the intro — add those to your style profile?"* The voice sharpens with use. **Profile template.** The base `wiki/style.md` uses all sections below. A named profile (`wiki/style/<name>.md`) includes **only the sections it overrides or adds** — omit the rest; they're inherited from the base. ```markdown # Writing Style — <profile name> _Calibrated <date> from <samples | description>._ <!-- Named profile only: list what it changes, e.g. "Overrides base rhythm; adds one Hard rule." --> <!-- Named profile only, to lift a base ban: "Allowed (overrides base): contractions" --> ## Voice & tone - <e.g. First person, direct. Confident without hedging — "I think maybe" → "I'd".> ## Rhythm - <e.g. Short sentences. Vary length deliberately; one long sentence per paragraph max.> ## Diction - Prefer: <plain Anglo-Saxon words, concrete nouns, ...> - Banned: <"leverage", "utilize", "delve", "in today's landscape", ...> ## Structure - <e.g. Lead with the conclusion. No throat-clearing intros.> ## Formatting - <e.g. No em-dashes. Bold sparingly. Oxford comma.> ## Examples - Instead of: "<stiff version>" → "<their version>" ## Hard rules (self-check before finalizing any output) - [ ] <No banned words> - [ ] <Opens with the point> - [ ] <No em-dashes> ``` --- ### Lint Triggered by: "health check", "audit the wiki", "clean up", "find gaps", "lint". **Flow:** 1. Read `wiki/index.md` and all wiki pages. 2. Check for and report: - **Contradictions** — pages making conflicting claims - **Orphans** — pages with no inbound links from other wiki pages - **Unused resources** — resource pages that no project/area page links to (may be general-purpose, or may be forgotten after an effort ended) - **Stale claims** — pages that haven't been updated despite newer sources that touch the same topic (check `log.md` for ordering) - **Missing pages** — concepts mentioned frequently across pages but lacking their own page - **Dead links** — `[[wikilinks]]` or relative links pointing to non-existent pages - **Thin pages** — pages with less than 3 meaningful claims 3. Produce a lint report: ```markdown ## Wiki Lint Report — <date> ### Contradictions (needs human decision) - ... ### Orphan pages - ... ### Unused resources (no project/area links to these) - ... ### Missing pages (suggested) - ... ### Dead links - ... ### Thin pages - ... ``` 4. Ask the user which issues to fix now. Fix the approved ones and append to `log.md`: ``` ## [<date>] lint | Lint pass Issues found: <N> Issues fixed: <list> Deferred: <list> ``` **If any fixes were applied and `.git` exists in the wiki root**, suggest: `git add . && git commit -m "lint: <date> (<N> fixed)"`. Wait for user confirmation before running. If everything was deferred, no commit is needed. --- ## Page conventions ### Frontmatter (YAML) Every wiki page should have: ```yaml --- type: entity | concept | source | analysis | overview title: <human-readable title> tags: [<namespace/topic>, <namespace/topic>] last_updated: <date> source_count: <N> # how many sources have touched this page distill_level: 0 # 0=raw, 1=bolded, 2=summary added, 3=condensed last_distilled: <date> # omit if never distilled --- ``` `tags` carry **namespaced topic keywords only**, drawn from `schema.md`'s `## Tag vocabulary` (e.g. `technology/postgres`, `vendor/acme`, `compliance/soc2`, `process/hiring`). ### Cross-references Use relative markdown links: `[Concept Name](../concepts/concept-name.md)` Also support `[[wikilink]]` style if the user is using Obsidian. Resource pages use `**Cross-references:**` for entity/concept links. Which efforts use a resource is recorded as links **on the project/area page** (in a "Resources" or "References" section), not on the resource itself. A resource's usage is therefore discoverable by checking which project/area pages link to it — Lint flags resources with no inbound project/area links as potentially orphaned. ### Contradiction markers ``` > ⚠️ **Contradiction:** [Source A](../sources/a.md) claims X while [Source B](../sources/b.md) claims Y. Unresolved. ``` ### Confidence markers (optional) If the wiki domain benefits from epistemic tagging: ``` > 🔵 **Well-established** | 🟡 **Contested** | 🔴 **Speculative** ``` --- ## index.md format Keep it scannable — one-line summaries only. ```markdown # Index — <Wiki Name> _<N> resources | <M> pages | Last updated: <date>_ ## Resources | Page | Summary | Organized | |------|---------|---------| | [Title](resources/slug.md) | One sentence | 2026-04-01 | ## Entities | Page | Summary | |------|---------| ## Concepts | Page | Summary | ## Analyses _Analyses live inside their parent area/project; grouped here by parent for discoverability._ ### <parent area or project> | Page | Summary | |------|---------| ``` --- ## log.md format Append-only. Each entry starts with `## [YYYY-MM-DD]` so it's grep-parseable. Operation types: `init`, `capture`, `organize`, `distill`, `express`, `query`, `calibrate`, `lint`. ```markdown # Log ## [2026-04-01] init | Wiki created Domain: AI Research ## [2026-04-02] organize | Attention Is All You Need Pages updated: transformer, attention-mechanism, encoder-decoder New pages: multi-head-attention, positional-encoding ## [2026-04-03] distill | transformer Level: 0 → 2 ## [2026-04-04] express | Draft: The Case for Attention-Only Architectures Type: draft Parent: project/attention-post Filed: wiki/projects/attention-post/attention-only-draft.md Sources used: transformer, multi-head-attention, attention-is-all-you-need ``` --- ## Optional tooling ### Office document support (optional) To ingest office files (PDF, PPTX, XLSX, etc.) during **Capture** or produce a formatted document during **Express**, add whatever document-reading capability your agent offers. On **Claude Code**, that's the `document-skills@anthropic-agent-skills` plugin. Other agents have their own equivalents — this skill needs only plain markdown, so office support is a convenience, never a requirement. ### Setup guides Setup guides live in separate files — load the relevant one on demand, not on every wiki operation: | File | When to load | |------|-------------| | `setup-git.md` | User asks about git setup, rollback, or commit conventions; or during Init when git is requested | | `setup-rclone.md` | User asks about cloud backup or sync; or during Init when a backup pattern is requested | | `setup-obsidian.md` | User mentions Obsidian, web clipping, or asks about the clipper workflow | **Operational reminders (no file load needed):** - If the user asks to update this skill ("update wikismith", "get the latest version"): run `git -C <skill-directory> pull` — the skill directory is wherever this `SKILL.md` lives — then summarize what changed from the new commits. If the skill was installed without git (no `.git` there), point the user at the repo's Install section instead. - If `.git` exists: suggest a commit after organize, distill, express, and calibrate — wait for confirmation - If `.git/hooks/post-commit` exists: skip rclone sync reminders — the hook fires automatically - If no hook but `schema.md` has a `## Backup` section: remind the user to sync after each operation using the exact command from `schema.md` - If `rclone-only` pattern (no git): skip git commit suggestions entirely --- ## Behavioral principles - **The agent never modifies `capture/`**. That's the source of truth — both quick captures and source documents live there, immutable. - **Capture is frictionless.** New captures require zero processing — save first, think later. - **Be thorough on cross-references.** A page that isn't linked to is nearly invisible. - **Never silently pick a side.** Mark contradictions and let the user decide. - **PARA reflects the user's current life, not the content.** The same resource may serve multiple efforts — record those dependencies as forward links on each project/area page. When in doubt about which efforts a resource serves, ask. - **Distillation is lossy by design.** Optimize for resonance, not completeness — keep what the user would want to rediscover six months from now. - **Distill before Express.** If asked to express from pages at distill_level 0, suggest distilling first — the output will be sharper. - **Voice is for outputs only.** Apply the user's writing-style profile to Express artifacts (and outward-facing filed answers) — never to internal entity/concept/source pages, which stay in a neutral reference voice. - **Express produces starting drafts.** The user finishes, approves, and owns every outward-facing artifact — the agent assembles; the judgment stays the user's. - **File good answers and outputs back.** Insights and drafts shouldn't disappear into chat history — they're wiki pages now. - **Keep the index lean.** One-line summaries only. Detail lives in the pages. - **The log is append-only.** Never edit past entries. - **When in doubt about page structure, consult `schema.md`** — that's the domain configuration for this specific wiki. - **Prefer updating existing pages over creating new ones** unless the topic genuinely warrants its own page (recurring, substantial, cross-referenced by multiple sources).