llm-wiki-obsidian-blink: A Folder Contract for LLM-Maintained Obsidian Notes

The problem is maintenance cost, not capture

Personal wikis rarely fail because people stop reading. They fail because nobody wants to re-read forty pages to fix a stale cross-reference after a new source contradicts an old one. The README states this directly: traditional wikis fail because maintenance cost is too high, and humans are bad at tedious cross-referencing, consistency checks and content updates. The project's answer is to hand that bookkeeping to a language model and keep the human responsible only for adding source material. The intended user is someone who already accumulates papers, book excerpts and media in a folder and already has access to an agentic tool. It is not aimed at a team wanting a shared documentation site, and it is not aimed at anyone who wants a search index built for them. The wiki is described as a compounding asset rather than something re-derived on each question, which is a claim about workflow discipline, not about any code in the repository.

Three layers, and the schema is the only one you edit

The architecture is a three-way split. raw/ holds immutable source material, subdivided into papers/, books/ and media/. wiki/ holds the generated knowledge network, subdivided into sources/, entities/, concepts/, comparisons/ and overview/, plus index.md and log.md. TheSchema.md sits at the vault root and defines rules and workflows. Attachments/ holds images. The data flow implied by the README is one-directional: material lands in raw/, the agent reads it, and the agent writes or updates pages under wiki/. The README's usage guidance is explicit that raw/ should only be added to, never modified, which is what makes the wiki layer reproducible in principle. index.md is described as a categorised table of contents that helps the agent locate pages quickly, and log.md as a time-ordered record of operations. Neither file has a documented format, so how the agent maintains them is a property of your schema, not of the repository.

Ingest, Query and Lint are prompts, not subcommands

The README names three daily operations. Ingest takes new material in raw/ and produces a source summary page, updates to related entity and concept pages, cross-reference maintenance, and a log entry. Query searches relevant pages and answers with citations, optionally writing a valuable answer back as a new page. Lint audits wiki health: contradictions, outdated content, orphan pages, merge or split suggestions, and missing cross-references. There is no CLI, no Makefile and no script mentioned anywhere in the material. These operations exist only as instructions you give your agent. The README's own examples are natural-language prompts: asking the agent to ingest raw/xxx.pdf, asking a comparison question, or asking for a Lint pass over wiki. That means the boundary between the three operations is enforced by the schema text and by the agent's willingness to follow it. A weaker model will blur them, and nothing in the repository will stop it.

Getting a vault open takes four steps and one prompt

The quick start is manual. Download the latest .zip from the Releases page, unzip it into your Obsidian vault folder, then in Obsidian choose Open folder as vault and select the unzipped folder. The fourth step is configuration of the AI agent: read TheSchema.md and provide its contents to your agent, with Claude Code, OpenClaw and Trae named as examples. There are no config keys, environment variables or install commands in the README. The only invocation surface is the prompt text, and the README gives three templates: a request to ingest a specific file under raw/, a plain question about the difference between two topics, and a request to run a Lint over wiki. A Bilibili video is linked for a demonstration. The release history shows one release, 1.0, dated 2026-04-10, and the last push to the default branch is 2026-04-13, so the repository is active but has a single tagged version.

The agent is the runtime, and that is the failure mode

Because the project is a convention rather than a program, every quality property belongs to the model you attach. Three concrete failure modes follow. First, drift: if the agent writes to raw/ despite the README's rule, the immutable-source assumption breaks and later Lint passes have no clean baseline to compare against. Second, silent inconsistency: Lint is described as periodic, so between passes the wiki can accumulate contradictions that the agent will happily cite when answering a Query. Third, context limits: Ingest is specified as reading a source and updating related entity and concept pages, which means the agent must locate and rewrite existing pages, and on a large wiki that is a multi-file edit that a small context window will truncate. The README does not describe concurrency control, page naming rules, frontmatter, or how to resolve a merge conflict when two ingests touch the same concept page. Those gaps are not oversights in the write-up; they are genuinely undefined in the material.

Compared with a static site generator, it inverts who writes

A tool like MkDocs or Quartz takes Markdown you wrote and renders it into a browsable site with navigation and search. The division of labour is fixed: you are the author, the tool is the renderer. This repository inverts that. Obsidian already renders and links; what the project adds is a designated author for the derived layer, namely the agent, plus a folder boundary that separates what the agent may rewrite from what it may not. That is a different bet. With a static site generator, correctness is a build-time property and broken links surface as warnings. Here, correctness is a property of the model's behaviour across sessions, and the only audit trail is log.md, whose format the README does not specify. If you want deterministic output, a generator is the safer choice. If your bottleneck is that nobody updates the notes after the first draft, the inversion is the whole point.

Licence, maintenance and what a fork actually costs

The README declares an MIT License, but the repository metadata supplied here lists the licence as unknown, so confirm that a LICENSE file is present in the downloaded zip rather than relying on the README line. Under MIT terms you may reuse and modify the layout, and the practical implication for a fork is that the files you will actually change are TheSchema.md and your own page conventions, not source code. Maintenance cost therefore tracks your agent, not the upstream project: when you change models or upgrade an agent, re-read TheSchema.md and check whether its instructions still match what the new model does by default. The single 1.0 release and the four-day gap between the release and the last push suggest a young project, so treat the layout as a starting point you will own. There is no migration tooling mentioned, which means changing the folder taxonomy later is a manual rename across wiki/ plus a rewrite of the schema rules.

Editorial conclusion

Adopt this if you already pay for an agentic coding tool such as Claude Code, OpenClaw or Trae and you want a fixed place for it to deposit distilled notes. Do not adopt it if you expect software to run: the repository ships a layout and a schema document, not an executable, and the README's quick start is four manual steps plus a prompt. Before committing, open TheSchema.md and check whether its rules are specific enough to constrain your agent, and confirm the MIT licence text actually ships inside the downloaded zip, since the repository metadata does not report a licence.

Official sources

1. iBlinkQ/llm-wiki-obsidian-blink on GitHub
2. Issues
3. README
4. Releases