What happens when you hand Claude Code a 285-line operating manual and leave it running inside your notes vault for a month? One developer found out, and the short answer is: it now handles their entire work documentation automatically.
The setup targets three specific problems: scrambling to compile accomplishments during review season, scattered incident documentation, and brag sheets that never get updated. After 30 days of daily use, those documents write and maintain themselves.
Structure Beats Prompts
The developer's core finding: vault structure matters more than prompt engineering. When notes follow a consistent schema - predictable field names, predictable locations, predictable date formats - Claude can synthesize across hundreds of entries accurately. Without consistent structure, no amount of clever instructions produces reliable results.
This makes sense once you see it. Claude Code reads files the same way you would - scanning what's there and working with what it finds. If your incident notes from six months ago use different fields than last month's entries, the model has to guess what maps to what. The operating manual can't fix structural chaos; it can only describe order that already exists.
What the 285 Lines Actually Do
The operating manual lives as a CLAUDE.md file - Claude Code's built-in configuration format, read automatically every time you open a project. At 285 lines, it's thorough: naming conventions, note schemas, directory purposes, and how to handle edge cases.
The five lifecycle hooks handle the automation. Lifecycle hooks are shell commands that run at specific moments during a Claude Code session - when a session starts, when a task completes, before writing files. In this setup, they update a running work log, flag notes that have drifted from the expected schema, and maintain a last-modified index.
The manual explains the system; the hooks enforce it. Together, they mean Claude Code can open the vault, understand what's there, make updates, and leave everything consistent - without re-explanation each session.
Build Schema First, Then Write Instructions
For anyone considering a similar setup, the schema-first lesson is the one to internalize before writing a single line of instructions.
Pick your note fields and commit to them. Date formats, status labels, project identifiers - consistent fields let Claude filter, group, and summarize across an entire vault. Inconsistent ones require manual corrections that defeat the purpose.
The lifecycle hooks are a secondary investment. They require knowing what you want to automate before you can configure them, which means they come after the manual is stable. Writing the manual itself forces you to articulate the structure you want - and that clarity has value independent of Claude.
For review season prep, the synthesis capability is the highest-value output. When every work note has matching project and impact fields, "summarize my contributions for the past quarter" becomes a reliable operation rather than a guessing game. That alone justifies the month of iteration.