Wiki Meetings — the meetings/ pattern

Part 2 of the AI Wiki Quickstart. Once the wiki exists, the next thing worth wiring up is meetings — every call, every 1:1, every standup, dropped into the same folder Claude already reads.

Meeting notes are some of your highest-signal documents — decisions made, risks flagged, action items owned, what the client actually said. Storing them in the wiki gives Claude two things: read-access, so they participate in everything else you ask, and chronology, so "when was this first raised?" or "what did I commit to last month?" return real answers, not guesses.

What follows is one way, not the way. Treat the prompts as starting points — rename paths, drop fields, change headings to suit how you actually work. The pattern is what matters: meeting notes as markdown, in a folder Claude already reads.

Set up the template (one time)

Paste this once. It creates the template every future meeting note is based on, plus a CLAUDE.md line so Claude knows where meetings live.

Set up my meeting wiki. Do all of the following:

1. Create the folder meetings/ if it doesn't already exist.

2. Create meetings/_template.md with this exact content:

---
date: YYYY-MM-DD
type: 1-1   # or: standup, client-sync, planning, etc.
attendees: [Name, Name]
tags: [topic, topic]
---

# YYYY-MM-DD — Meeting title

**When:** Day YYYY-MM-DD, HH:MM–HH:MM
**Where:** Zoom / room / location
**Attendees:** Name, Name

## Agenda
-

## Notes
-

## Action items
- [ ]

## Screenshots

## Transcript
<details><summary>Full transcript</summary>

...paste from Otter / Granola / whatever...

</details>

3. Append this to CLAUDE.md (create it at the project root if missing):

Meeting notes live flat in meetings/. Each dated note uses
meetings/_template.md as its base, and is named
YYYY-MM-DD-{name}.md (e.g.
meetings/2026-05-12-1-on-1-with-starbuck.md).

Recurring meetings also get a descriptive name-based canonical
page in the same folder, e.g.
meetings/1-on-1-with-starbuck.md, holding purpose, cadence,
attendees, and standing context. Dated occurrences cross-link
back to the canonical page with [[wikilinks]].

When asked to start a new meeting note: first check meetings/
for an existing canonical page matching the topic. If one
exists, create the dated child as part of that series and link
back. If not, default to a single dated file. When the topic
clearly indicates recurrence ("weekly", "monthly", "1:1",
"standup", etc.) and no canonical exists yet, also offer to
create the canonical page — but create the dated file either
way so I'm never blocked waiting on an answer. In all cases,
copy _template.md as the base and fill in the frontmatter
(date, type, attendees, tags) based on the meeting topic.

Attachments (screenshots, exports, anything binary) live in
meetings/attachments/.

Confirm when done.

* The structure is intentionally flat — no per-meeting subfolders. Wiki tools (Obsidian especially) resolve [[wikilinks]] globally by filename, so nesting buys nothing the backlinks aren't already doing — and it costs you cleaner search, easier renames, and a single chronological view. Subfolders feel more organised; flat scales better.

That's the whole setup. One-off meetings get a single dated file. Recurring ones (weekly 1:1s, standing client syncs) also get a canonical page the first time around — purpose, cadence, attendees, long-running threads. The CLAUDE.md line above tells Claude when to do that automatically.

Before each meeting

A few minutes before a call starts, paste this:

I'm going into a meeting about {topic} in a few minutes. Start a
meeting note for me. I'll drop screenshots, questions, and notes
for you to ingest as I go. Before I start, review existing
projects, tasks, and recent meetings — pull anything relevant
into a context block and flag any open questions worth raising.

Two things happen. Claude creates the dated note in the right place using _template.md, so every meeting starts with the same shape. And — the part that earns its keep — it reads back relevant context from the rest of the wiki: open threads from last week, project state, anything that touches the topic. You walk in primed, not staring at a blank page.

During the meeting

Drop things into the chat as they come up. A few prompts worth keeping handy:

Capture a screenshot. Paste an image, then:

Add this screenshot to today's meeting note under Screenshots.
OCR any text in the image and include it as alt-text so it's
searchable later.

Capture a decision and the action that follows.

Just decided: billing rewrite slips to Q3. Add it to Notes
under today's meeting, and create an action item: me, draft
the new headcount ask by Friday.

Look something up without leaving the call.

While we're still talking — check what Starbuck said about Q3
capacity in our last two 1:1s and summarise it in one line.

Quick mid-call recap.

Summarise what's been discussed so far and list the threads
I should make sure to close before the call ends.

At the end of the call, paste the transcript into the <details> block. You'll almost never re-read it yourself — but Claude can, and that's what makes "when did Starbuck first mention the billing concern?" answerable two years from now.

What it earns over time

Once meetings have lived in the wiki for a while, the questions you can ask change shape. "What did we agree about pricing across the last three Acme calls?" is a normal prompt. "What action items am I still on the hook for from last month?" is a checkbox grep. "Draft a follow-up email referencing the open thread from my 1:1 with Starbuck" works because the threads are already in the canonical page.

None of this requires giving up other tools. Keep Otter or Granola for transcription, Notion or anything else that suits the workflow — drop the markdown into the wiki when you want Claude to see it too.

Pair it with your calendar

Hook Claude up to your calendar and you can stop typing the topic. "Start the note for my next meeting" is enough — Claude reads the invite, fills in the frontmatter, and primes the wiki context.