Three things you can do, in the order they happen

Walkthrough one

A meeting happened. You have a Teams transcript.

1 — Get the file

In Teams, open the meeting, then Recap → Transcript → Download → .vtt. Any other tool works the same way; a .vtt is a .vtt.

2 — Open a session where your notes live

$ cd ~/notes/acme/meetings
$ claude

Where you start matters and is the first thing the orientation page covers: a session started above your folder searches everything beside it too.

3 — Hand it the file

> /transcript ~/Downloads/meeting-2026-09-24.vtt

Or paste the contents straight into the session after the command. There is no import step and nothing is uploaded anywhere.

4 — What comes back

A single markdown file, named for its date, its participants and its topic — 260924-acme-quarterly-review.md — with the sections in this order:

1. Next steps — a table of actions with an owner and a date. First, because it is what a reader scans first.
2. Decisions — what was decided and why. Present even when nothing was decided, saying so: honest absence is searchable, silent omission is not.
3. Outcome — one or two sentences on what changed.
4. Discussion — the narrative of what was talked about.
5. Background — reference material, at the bottom, because background is reference rather than navigation.

Names are resolved, not transcribed: the speaker labels a transcription tool invents get matched against whatever roster your folder knows about. That is the first thing a summary has to get right, and the first thing an unaided model gets wrong.

Total setup: none. This works with the framework installed and nothing else configured.

Walkthrough two

Four meetings later. What do we actually have?

You have been doing the above for a few weeks, across a few folders. Now the question is not about one meeting but about the pile — and it is the question nobody can answer from the outside, because a folder holding a running project and a folder holding old transcripts look identical: same depth, same naming, both with a meetings folder.

Ask it

> /ops project list

What comes back is a grouping, and the grouping is the answer

Each row carries how many dated meetings it holds and when the record last moved — read from the changelog where there is one, because a changelog entry is a deliberate act and a file timestamp is whatever a sync did last.

Why this is the useful answer

Measured on one real vault: forty project-shaped folders, five configured, four with the loop wired. The value is not the four. It is that thirty-five folders that looked like projects were not, and now say so — several of them correctly, because a pile of material is a legitimate thing for a folder to be.

Read-only. It changes nothing and is safe to run on a folder you have never configured.

Walkthrough three

Six weeks in. It starts telling you things you did not ask.

The first two walkthroughs are you asking questions. This one is the corpus answering one you never typed — which is the part that only exists because the notes accumulated in a shape something can read.

What has been quietly happening

Every processed meeting leaves observations behind: a decision's rationale, a pattern in how someone raises things, a correction to an assumption. Each starts as a hypothesis — noted, and trusted with nothing.

Compile: when three observations make a rule

> /insights compile

When three hypotheses in one folder make the same claim, the earliest is promoted to a rule. The others are marked superseded, pointing at it, and the rule records where each confirmation came from. Its count is the number of separate days it was observed — five entries from one afternoon are one observation.

"The same claim" is judged, not counted. The summaries are written by a model and phrased fresh every time, so two entries saying one thing rarely share their words — an earlier version required 60 % word overlap and, on a real vault, never promoted anything.

What compile refuses to promote, and says so: a group held together only by a topic (seo, payments) rather than a claim; a group that contains a decision and its later reversal — the earliest entry would be the revoked one; and a group from a single session. Each skipped group is reported with its reason. Expect a handful of promotions a run, not dozens: most observations are observations.

And then the rule comes back. A confirmed rule is loaded as standing context by /ops and /transcript when you work in that folder — so the next meeting is processed by something that has read the last twenty.

That is the loop closing, and it is the whole reason this is not a note-taking app. A note-taking app has no opinion about your twenty-first meeting.

Names it keeps hearing

A name the transcript could not place is flagged in the summary. On its own that flag is read once and forgotten. Compile counts them across folders and lists every name flagged twice or more that no roster or contact resolves — a list for you, never a write: whether a name is a person is a claim only you can make. Add the ones that are to the roster, and the flags stop.

Demotion, which matters more than promotion

When a correction contradicts a rule, the rule drops back to hypothesis, records what contradicted it, and stops being loaded. A system that can only accumulate confidence is a system that gets more wrong over time, more certainly.

Synthesize: from entries to articles

> /insights synthesize

Clusters related insights across folders and writes a topic article for each cluster above the threshold — living documents, named by topic and never dated. Each carries its sources, how the thinking evolved, where insights contradict each other, and an open-questions section.

An article you have edited by hand is never overwritten. It is flagged and you are asked.

And no retrieval infrastructure

A session answering a question reads the index first, then opens only the relevant article. No vector store, no embeddings, no scanning the whole vault. The index is a file; the articles are files. That is the entire mechanism.

Run compile weekly and synthesize when it says a cluster crossed the threshold. Both are idempotent — running them twice changes nothing twice.

In practice

Four situations it is used in

The walkthroughs show the moves. These are the situations people put them to. Each runs today, and each uses only what the walkthroughs above already cover.

A team project with a meeting every day

Eight to twelve people, a standup or a weekly. Before the meeting, /ops prepare writes the agenda, starting with what did not land last time. The facilitator sheet (which question to ask) is written by hand, because that is judgement, not generation. The agenda goes up on screen and the meeting is recorded. Afterwards /ops process turns it into the summary and the action list with owners, and offers a recap. Whether one goes out is your call; the contract leaves that step to a person on purpose.

Needs a folder with the loop wired. Walkthrough two shows which of yours are.

Holding suppliers to what they said

A project with outside suppliers, where the risk is that what was agreed quietly shifts. Every summary records the decisions and why they were made, and what did not land becomes the top of the next agenda. So you walk in with the points that should be ticked off, and when a supplier's account drifts from what was said before, the earlier version is one file away. Nothing detects the drift for you. It is visible because it was written down.

Needs the same as walkthrough one, done after every meeting.

Fifteen minutes of talking

Knowledge that only exists in one person's head: why the brands are positioned the way they are, where the style guide and reality disagree. Record yourself talking it through for a quarter of an hour, hand the transcript to /transcript, then ask the material questions in the same session. For some people this was the step that made the rest make sense.

Total setup: none, as in walkthrough one.

A project from the first client meeting to the close

/ops project new creates the folder and registers it. The brief goes in as the first document, and each meeting after that adds its summary and moves its tasks. Closing the project (the review, the register rows, deciding what happens to open tasks) is done by hand today. That half is proposed in the framework, not built.

Opening is a command. Closing is a checklist you keep yourself, for now.