Organize Meetings
Usage
/organize-meetings— SweepMeetings/_inbox/and propose destinations for every file./organize-meetings <path>— Categorize a single file (in or out of_inbox/)./organize-meetings --auto— Apply only high-confidence proposals (≥ 4/5 majority); leave the rest in_inbox/for next sweep.
When to run
| Caller | When |
|---|---|
| Standalone | Whenever you want to drain Meetings/_inbox/ (e.g. after /mail-transcripts created some stubs). |
/meeting wrap pending |
Step 1.5 — between /mail-transcripts and pending discovery, so triaged files are included in the pending scan. |
Why this skill exists
The Gemini-emailed archiver (.scripts/gmail_ai_transcripts_to_meetings.py) only knows deterministic patterns: daily standups, sprint ceremonies, recurring team meetings, etc. Everything name-dependent — 1:1s with anyone, cross-team syncs, novel meeting titles — lands in Meetings/_inbox/ and waits here for triage.
Routing is agent-driven, not script-driven: similarity (via qmd-vector_search) finds where the new note's siblings live; memory (feedback_meeting-routing.md) captures learned exceptions so future runs apply them automatically.
Frontmatter Conventions
Files in _inbox/ are normal meeting notes with Notes: and created: frontmatter. The skill does not modify frontmatter — it only moves files (git mv) and updates the H1 inside when renaming.
Workflow
Step 1: Discover candidates
See vault-context for vault discovery conventions.
- No args: query the live Base view —
obsidian base:query path=Meetings.base view=Inbox format=paths. Returns every file underMeetings/_inbox/(the.gitkeepis excluded automatically since it's not a.md). <path>arg: single-file mode — operate on that path.- If the candidate list is empty, print
Nothing to organize.and exit.
Step 2: Read memory for learned conventions
Check memory/feedback_meeting-routing.md (if present). It contains routing hints the user has confirmed over time, e.g.:
Titles with both "" and "" →
Meetings/Tech Syncs/(not One-on-ones/), filename<Name A> x <Name B> Sync - YYYY-MM-DD.md.
Apply these before qmd similarity so they always win.
Step 3: For each candidate, propose a destination
For each candidate file:
- Extract the title: filename minus the trailing
- YYYY-MM-DD.md(or use the H1 inside the body if cleaner). - Apply memory overrides (Step 2). If a memory rule matches confidently, skip to Step 4 with
confidence = high (memory). - Otherwise, run qmd-vector_search on the title — return top 5 most similar meeting paths.
- Aggregate:
- Count how many of the 5 matches live in each folder. Pick the mode.
- Inspect filenames in that folder to infer naming pattern:
- All siblings end in
- YYYY-MM-DD.md→ keep date suffix. - All siblings use
YYYY-MM-DD.mdonly (e.g.Engineering/Scrum/) → use date-only. - Siblings share a prefix (e.g.
Tech Leads Weekly -) → consider renaming to match.
- All siblings end in
- Score confidence:
Match count Confidence 5/5 or 4/5 same folder high 3/5 same folder medium < 3/5 or no matches low
Step 4: Present proposals to the user — MANDATORY CONFIRMATION
⚠️ Never move files without confirmation, except in --auto mode (where only high-confidence proposals run, low/medium skip).
Display a numbered table:
| # | File | → Folder | New filename | Confidence | Reasoning |
|---|------|----------|--------------|------------|-----------|
| 1 | _inbox/Jane x Me - 2026-06-02.md | One-on-ones/ | Jane x Me - 2026-06-02.md | high (5/5 qmd) | siblings: John x Me, Alex x Me, Sam x Me |
| 2 | _inbox/PatMe Sync - 2026-06-02.md | Tech Syncs/ | PatMe Sync - 2026-06-02.md | high (memory) | memory: Pat/Me → Tech Syncs |
| 3 | _inbox/Foo Bar - 2026-06-01.md | ? | ? | low (1/5 qmd) | no clear majority — needs user |
Ask the user: "all", "high-confidence only", "1,3", "none", or per-file corrections (e.g. "2 → Engineering/").
Step 5: Apply moves
For each approved proposal:
git mv "<old path>" "<new path>"— preserves history.- If the new filename differs from the old, update the H1 inside the file. Skip if H1 already matches the new filename.
Step 6: Capture corrections to memory
When the user overrides a proposal ("don't put Pat/Me in One-on-ones, it goes to Tech Syncs"), this is feedback worth saving. Write or update memory/feedback_meeting-routing.md:
---
name: meeting-routing-conventions
description: Learned routing rules for /organize-meetings — overrides qmd similarity
metadata:
type: feedback
---
When triaging Meetings/_inbox/ via /organize-meetings:
- Titles containing both "<name-a>" and "<name-b>" → `Meetings/Tech Syncs/`.
**Why:** It's a recurring manager sync, not a standard 1:1.
**How to apply:** Apply before qmd similarity. Filename pattern: `<original> - YYYY-MM-DD.md`.
- (more learned rules append here over time)
Always include a Why: (the user's reasoning, if given) and How to apply: (the precondition + filename pattern). Capture one rule per bullet so future updates are atomic.
Step 7: Commit
See /commit. Skip when called as part of /meeting wrap pending — the parent sequence commits at the end.
When called standalone: commit with update: /organize-meetings — N files moved (or similar). Skip if nothing was moved.
Edge Cases
- No qmd matches at all (e.g. truly novel meeting type): low confidence. Ask the user; do NOT default to a folder.
- Multiple folders tied: low confidence. Ask the user.
- File already wrapped (
NotesCached,Participants,TodosExtractedalready set in frontmatter): still route it — wrapping doesn't lock the file location. Frontmatter survives the move. - H1 inside the file is generic (e.g. just
# Meeting): leave it alone; don't fabricate a new H1. - Filename collision at destination: append
.dup-Nor ask the user.
Important Notes
- Always use
git mv, nevermv— history matters. - Never auto-move
lowconfidence proposals, even in--automode. - Memory entries are cumulative: append, don't overwrite. Each entry is a separate rule.
- If qmd's index is stale (a recent batch of renames hasn't been reindexed), low-confidence proposals may be common — note this in the proposal reasoning and suggest the user reindex.
- This skill does NOT modify the
Notes:,Participants:,NotesCached:, orTodosExtracted:frontmatter. Those belong to/cache-notes,/fill-participants, and/followup-todos.