Tailor the vault to its owner

This vault is a foundation. Its rules, skills and tools were built for one person's use: capture everything about a life, and answer any question about it for a few hundred tokens. But the agent that runs it can do far more than file notes. It can take work off the owner's plate across their whole life — plan their day from their calendar, catch them up on their field's news, sort their finance email, prepare them for the week's meetings — whatever their own days and weeks actually hold, with every result recorded in the vault so nothing is lost. This skill gets to know the owner, proposes only what would make a noticeable difference, and builds what they choose, without breaking what makes the vault cheap and safe.

Work through the six steps in order. During setup, SETUP.md sends you here once the base vault builds clean and before anything is compiled (SETUP.md § 4A.6 or § 4B.4): run all six then. The setup facts — name, topics, spelling, NotebookLM, GitHub and the rest — belong to SETUP.md's own interview (§ 2); never ask them here. On a later run, read HANDOFF.md § Tailoring and § Decisions first, and ask only about what has changed.

The owner may decline at any point — before the free talk, mid-interview, or at the proposal. Stop there, and go straight to step 6 to record "declined by the owner": that is a complete run, and setup goes on.

1. Study

1a. The design — always

Do not ask your owner a single question until you understand how every part of this vault works — the owner's order, not a suggestion. You cannot propose good additions to a design you only half understand, and the reasons behind the rules are spread across the rules, the skills, the ledger of what broke and the tooling notes. If this setup already wrote output/tailor-study.md and nothing in the design has changed since, it stands — go on to 1b.

1. Read the design, in full — about 87,000 tokens at version 1.0.0 (September 2026); reading every file of the template would be about 390,000, most of it code and the benchmark's corpus, and is not needed:
   • AGENTS.md (which CLAUDE.md imports), the four .claude/rules/ files, HANDOFF.md and SETUP.md — what the vault runs by;
   • every skill in .claude/skills/ with its references/ — this file's references/extending.md is the guide for adding to the vault —, the two agents in .claude/agents/, .claude/settings.json and tools/hooks/;
   • tools/README.md and tools/DEFECTS.md — what each tool guarantees, and every rule's reason: each exists because something broke;
   • every node in wiki/tooling/ — the architecture, the query ladder and its costs, the capture protocol, the image and drawing rules, NotebookLM;
   • docs/how-it-works.md, bench/README.md and the baseline scorecard, bench/results/baseline.json.
2. Prove you understand how all of it works. Write a study brief to output/tailor-study.md (outside the query path) that explains, in your own words, each point below, and names the file or files each explanation comes from:
   • how a question is answered cheaply: the five index files, the query ladder and what each rung costs, and what is banned at query time;
   • the node kinds, the one hard cap and why bodies are uncapped;
   • how a capture flows in — the capture table, logs, daily notes, raw/ and a compile — and how a correction is swept and fenced;
   • what every skill does, who may start it, and why each is a skill;
   • what each agent, hook and rules file does, and when each loads;
   • what the builder, the self-test and the audit each check, and how a defect becomes a guard and a ledger row;
   • how drawings, images and NotebookLM fit, and what the benchmark measures.
3. Close every gap. Any point you cannot explain with confidence goes back to the files — the code in tools/, a wiki node, a ledger row — until it is clear. A point you only guessed at is a gap. The study is done when every point is explained and sourced.

You will draw on the brief all through the interview, to explain the vault to your owner in plain words whenever a question needs it.

1b. What already exists about the owner

What you can learn before asking anything depends on the case:

• An existing vault, during setup. It is plain linked Markdown — no index, no rules, no code of ours — still in the owner's own folders, because tailoring runs before SETUP.md § 4A.7 moves the notes into raw/. Survey it cheaply: the folder tree and how many notes each holds; the note titles; the tags and aliases in their frontmatter; the most-linked notes, counting [[links]] with a short script in a scratch folder outside the vault; the most recently edited notes (when every file carries the same date, as a copied or synced vault can, go by the dates in daily-note names instead); their daily notes, if they keep them. Then read a small sample in full — the ten or so most-linked and most recent — for what the owner actually tracks and does. A vault of a few dozen notes can simply be read whole; in a large one, never read every note.
• A new vault, during setup. Nothing to read yet.
• A later run, in a vault built on this architecture. HANDOFF.md § Tailoring and § Decisions, then the owner's notes through wiki/_index.tsv (every node's summary and tags), reading a note only where a question needs it; and the machinery as it is now, including any skills or rules the owner added since.

Add what you learned to the study brief under The owner, each point naming the note it came from. Then tell your owner in one line that the study is done and where the brief is.

2. Offer the free talk

Always offer it — whatever 1b found, even in a rich existing vault. It is a suggestion, never a requirement, and it never replaces step 3: it only makes your questions about them instead of about anyone. Say, in your own words:

Before I ask you anything, would you like to tell me about your days and weeks, in your own words, for ten to twenty minutes? Everything you do, at work and outside it: what repeats, what you keep forgetting, what you dread or put off, and the apps and accounts behind it all. If you have a voice-to-text tool, just talk and paste the text in; if not, type it — in any order, as roughly as you like. It's optional: say "skip" and I'll go straight to my questions.

If they talk, let them finish without interrupting. Then ask whether they would like the talk kept in raw/ as a capture for /vault-compile — their choice; if not, it lives only in this session. Either way, go on to step 3.

3. Grill the owner

The interview method below is adapted from Matt Pocock's grilling skill (https://github.com/mattpocock/skills, MIT License, © 2026 Matt Pocock; the notice is at the end of this file). Follow it exactly.

Interview the user relentlessly until reaching a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it. Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers you haven’t heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round. Format a round like so: [❓ Q1 - <question title>: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>

❓ Q2 - <question title>: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>] Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one. Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent or check it yourself to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report or you to finish looking it up yourself; ask the rest of the frontier now. The decisions are the user's: put each to them and wait. The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

The branches this tree must reach. Start from these; follow wherever the answers lead. Build every question from the free talk and 1b: quote what they said back to them, so each question is about their life, not a form.

• Their days and weeks, work and personal: what fills them, in the order it happens; what repeats daily, weekly, monthly.
• Each recurring task: what it is, how often, how long it takes, what is tedious or error-prone about it, and whether they forget, dread or put it off.
• What they would hand off, and what they would never hand off.
• The tools and accounts behind each task — calendar, email, messaging, finance, code hosts, video, news — and which of them this agent can already reach. Finding that out is your job: check the connectors and tools available to you in this session yourself, never ask the owner.
• Tasks with separate steps, where one skill could gather, the next summarise, a third file the result — candidates for a skill chain.
• What should happen without being asked, and when — candidates for an automation.
• Delegable reading or checking that could become a subagent, with what it may and may not touch.
• Rules of their own: how sources are cited, what counts as verified, what must never leave the machine, naming, tone, anything they correct you on twice.
• Cost and control: which procedures are expensive enough that only they should start them, and how much a task or a month of automations may spend.
• Their agent and harness: Claude Code, Codex or another — it decides what a skill, subagent, hook or schedule can be (references/extending.md § Other agents).
• On a later run: what has changed since the last dated line in HANDOFF.md § Tailoring, and whether anything waiting on a connector can now be built.

4. Propose

When the frontier is empty, state the shared understanding back in a short paragraph and ask your owner to confirm it, or correct it. Propose nothing until they confirm. Then propose a numbered list, each item in this shape:

**1. Plan my day** — a skill (or: a skill chain `gather-agenda → plan-day`; an automation; a subagent; a rules file; a topic; a capture-table row; probe terms; a hook)
- **Takes over**: "every morning I copy my calendar into a to-do list and still miss things" — your words, from the talk
- **How often · time saved**: every weekday · about 1 hour 15 minutes a week
- **Needs**: Google Calendar (connected); Gmail (missing — to connect it: …)
- **Cost**: about … tokens a run; guarded by …; records its plan in the journal

• The bar. Propose an item only if the task comes up at least weekly and saves real time, or it is something they said they forget, dread or put off. An automation must also be worth doing without being asked. A skill chain is judged as a whole, and proposed only when the task truly has separate steps — steps that are useful on their own, or that run at different times or with different tools; one skill is the default when one skill will do.
• The owner's own rules come first. Where one keeps something off the machine or out of the repository — work email, say — the item records only what that rule allows (a summary, a pointer, nothing), and says so under Cost.
• Cost is in tokens per run and per month, with anything else it spends.
• Everything else goes below the list as Considered, not proposed, one line each with the reason, so they can overrule you.
• If nothing clears the bar, say so and propose nothing. That is a good outcome, not a failure.
• Say which needs the existing vault already covers, and prefer the smallest change that meets each need.

Then ask which to build.

5. Build what they chose

First ask the building questions below — where each skill lives, how each automation runs — for every chosen item together, in one round, so nothing waits on them later. Then build one addition at a time, following references/extending.md. For each:

• Where a skill lives — ask every time. Ask whether it should live in the vault only, or globally so it works from any folder; recommend one and do what they choose. Recommend the vault unless they clearly need it elsewhere: there it is versioned, copied to other agents by agents-sync, and rebuilt with the vault. A global skill keeps its source in the vault and is copied into the agent's user-level skills folder — ~/.claude/skills/ for Claude Code; for another agent, the folder its documentation names — and it still records its results in the vault by the vault's full path.
• Every skill records its results in the vault through the capture table in AGENTS.md: a day plan goes to the journal, a finance summary to its node, a news digest to its log — within the owner's own rules on what may leave the machine.
• A skill chain is several skills, each usable alone: each link's SKILL.md ends with a ## Next section naming the skill it calls and exactly what it hands over. Build and test each link alone, then the chain.
• How an automation runs — list every option, and they choose. Say which ways exist on this owner's machine and agent — the agent's own scheduler (Claude Code has scheduled tasks), a cloud routine that runs while the computer is off, the operating system's scheduler (Task Scheduler on Windows, cron on Linux, launchd on macOS) running the agent in the background, or running it themselves when they want it — recommend one, and set up the one they choose. An automation is an ordinary skill or skill chain plus a schedule: it also runs by hand, the schedule starts the chain's first skill, no gated skill (compile, audits, handoff) is anywhere in it, and each run records its result in the vault. Set it up only after they approve its schedule and its estimated monthly cost. If their agent cannot run in the background, say so and offer it as a skill they start. A cloud routine cannot reach a vault on their computer: offer it only when the vault is in a git repository the routine can clone and push to, and say that each run's result lands in the vault through that repository.
• Connectors. A skill whose connector is still missing is not built yet: it is recorded as waiting on a connector, with the steps to connect it, and a later run builds it. Your owner signs in to every account themselves; you never handle a password or a token.
• A skill is modelled on the vault's own: a SKILL.md with a description that says exactly when to use it, the procedure in numbered steps, and disable-model-invocation: true only when your owner wants to be the one who starts it — usually because it is expensive.
• A subagent is read-only unless it must write, carries its own brief, and sets omitClaudeMd: true so it does not pay for the whole manual.
• A rule goes where it loads only when needed: a .claude/rules/ file with paths: when it concerns certain files, AGENTS.md only when every session needs it. Every new rule gets a mechanical guard — the builder, the self-test or a hook — and a row in tools/DEFECTS.md (this vault's own rows start at D200); a rule no code can check is written as one and marked so.
• A topic is registered in tools/build-index.js before any node uses it, with a folder icon.

After each: node tools/selftest.js and node tools/build-index.js must pass, and node tools/agents-sync.js must run after any change to .claude/. During a conversion the build still lists the owner's own notes as NOTE OUTSIDE THE INDEXED FOLDERS until SETUP.md § 4A.7 moves them, and warns that tailoring has no record until step 6: neither counts against an addition.

6. Record it

Under ## Tailoring in HANDOFF.md — create that exact heading above ## Decisions if it is missing, as it is in a vault set up before this skill recorded its runs — add this run's entry, newest last. Its first line is dated, in exactly one of three forms:

- **2026-09-28 — proposed**: …
- **2026-09-28 — nothing cleared the bar**: …
- **2026-09-28 — declined by the owner**

Beneath it: what was proposed, chosen, built, and considered but not proposed; which skills are global; which automations run, how and when; and what waits on a connector. Until the vault's first dated line exists, the build warns and the audit fails (D95) — that is what stops a setup from reaching its compile without ever proposing anything. Add one line per addition under § Decisions, with why. Then tell your owner, in a few lines, what changed and how to use it — and that they can run /vault-tailor again whenever their life or work changes.

The interview method in § 3 is adapted from grilling, in https://github.com/mattpocock/skills, under this licence:

MIT License

Copyright (c) 2026 Matt Pocock

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.