/preparation -- Meeting Preparation

Generate a structured preparation document for an upcoming meeting or call. Pulls context from previous interactions stored in the contact's folder.

Standalone skill -- works with any vault that uses a _contacts/ directory containing contact folders (e.g. _contacts/firstname-lastname/).

Integration: Output files follow the YYMMDD-{strings.filename_keywords.preparation}-*.md naming convention — agenda in every language since CR-089 (older förberedelse/preparation files are still read).

Subcommands

/preparation <input> (the default)

Write the agenda for a meeting with a contact — the config-free form of /ops prepare. The argument parsing below is that one action.

/preparation help

Print usage: the input this skill takes, the file it writes (YYMMDD-agenda-<description>.md), and when to use /ops instead — a folder with a config.

Argument Parsing

1. Contact name (required): Name of the person. Matched using the name resolution algorithm:
   • First, check _contacts/*/_meta.yaml for display_name or aliases matches
   • Then, match against folder names inside _contacts/:
     • Exact match: david matches _contacts/david-ekberg/ (partial match on first name)
     • Full match: erik sandberg matches _contacts/erik-sandberg/
     • Fuzzy: bob l matches _contacts/bob-lindgren/
   • Matching is case-insensitive with Swedish character folding ("Andre" matches "André")
   • If ambiguous, list matching folders and ask the user to choose
2. Date (optional): When the meeting is. Default: today.
   • today or no argument -> current date
   • tomorrow -> next day
   • YYMMDD -> specific date (e.g. 260220)

Examples

/preparation david                    -> David's folder, today's date
/preparation david tomorrow           -> David's folder, tomorrow
/preparation erik sandberg 260219    -> Erik Sandberg's folder, specific date
/preparation bob l 260220           -> Bob Lindgren's folder, Feb 20

Execution Steps

Step 0: Frozen Prep Check (CR-005)

Before writing or modifying any preparation file, check the file's target meeting date:

• Meeting date is today or in the future -> proceed normally

• Meeting date is in the past -> refuse with this message:

  This prep file is for a past meeting (YYMMDD). Mid-meeting or post-meeting notes belong in the transcript file. Use /transcript or /ops to capture them. To override, pass --force.

Rationale: preparation files must be frozen at meeting time. Mutating a prep doc with mid-meeting updates destroys the trace and contaminates the document. Live notes belong in the transcript file, which is the canonical post-meeting record.

The --force override exists for legitimate fix-ups (e.g., correcting a typo found post-meeting) but should be rare.

Step 1: Locate Contact Folder

Find the matching folder inside _contacts/ at the vault root using the name resolution algorithm.

Resolution order:

1. Scan _contacts/*/_meta.yaml files for display_name or aliases match
2. Match against folder names (case-insensitive, partial first name, fuzzy)
3. Swedish character folding: "Andre" matches "André"

When match found:

• If _meta.yaml exists, use display_name for document headings and filenames
• If no _meta.yaml, derive display name from folder name (title-case, hyphen -> space)

If no match found:

• Suggest creating the folder: _contacts/firstname-lastname/
• Ask the user for the canonical name spelling (display_name)
• Offer to create _meta.yaml with display_name and any aliases

Creating _meta.yaml (optional but recommended):

version: 1
display_name: "David Ekberg"
aliases:
  - "Dave"
  - "David E"

See Contact Metadata Schema for full specification.

Step 2: Gather Context

Read existing files in the contact folder to build context:

1. CHANGELOG.md (if exists) -- scan for recent entries to understand interaction history
2. Recent transcripts -- read the 2-3 most recent YYMMDD-samtal-*.md, YYMMDD-call-*.md, or other YYMMDD-*.md files (sorted by date, newest first). Search for both Swedish and English filename keywords.
3. Previous preparations -- read any existing YYMMDD-förberedelse-*.md or YYMMDD-preparation-*.md files, especially the most recent one for continuity
4. Other files -- note any other relevant documents (project files, notes, etc.)
5. Company profile (CR-125) -- if the contact's company has a _company/ folder, read its company and positioning facets as standing context (who they are, what they sell, where they stand) and cite the facet; do not copy text in. Silent when there is none. Never write to it.

Extract from these sources:

• Open action items (unchecked - [ ] items)
• Decisions made in recent meetings
• Topics discussed recently
• Unresolved questions or threads
• Relationship context (role, company, how you know each other)
• Previous meeting outcomes vs. preparations (what was expected vs. what actually happened)

Step 2.4: Triage Scan (CR-022)

If the vault has a registered triage doc (an _inbox/ working document with type: working_doc + tag do-not-process -- see docs/schemas/inbox.md, CR-022 section), scan it for open items belonging to this meeting's contact/participants:

1. Match bracket tags: open ([ ]) bullets whose bracket-tag second segment resolves to the contact via standard name resolution -- [Möte · X], [Uppföljning · X], [E-post · X], [Samtal · X] and similar.
2. Match body mentions: open bullets in the UPPFÖLJNINGAR section that name the contact without a tag.
3. Pull matched items into the prep -- [Möte · X] items become agenda/suggested-topics candidates; [Uppföljning · X]/[E-post · X] items go under open actions (yours). Keep the bullet wording; note the source (från triage).
4. Stamp each pulled bullet in the triage doc with a one-line suffix: → i prep YYMMDD. This is the ONLY write this skill may make to the triage doc -- never reorder, reword, re-bucket, or check off items. The human closes triage items, not the prep.
5. No triage doc registered, or no matches: skip silently.

This closes the loop the triage doc creates: meeting items collect there between meetings, and the prep is where they surface -- previously a by-hand collection step.

Step 2.5: Cross-Context Scan -- mandatory with explained relevance (CR-005)

After gathering context from the contact's own folder, scan the vault for lateral mentions relevant to this meeting. This step is mandatory when the vault has 3+ contact folders -- the prior optional treatment caused the skill to silently skip cross-references in most prep files.

Procedure:

1. Glob YYMMDD-*.md files across the vault (last 60 days by date prefix). Include _contacts/*/, venture meeting folders, and _projects/*/. Skip .archive/, .transcripts/, .handoff/, .ephemeral/ and clones/ — frozen handoff snapshots (CR-033) share the YYMMDD- prefix and would otherwise match this glob; they are never cross-referenced.
2. Exclude files from the target contact's own folder -- those are history, not lateral references. We want references elsewhere.
3. Grep the result set for: the contact's display name, the contact's company name, and the 2-3 top topic keywords from the upcoming meeting context (gathered in Step 3).

4. For each hit, read the matching section and write one line:

   - [filename](path) -- [one-sentence explanation of why this is relevant to the upcoming meeting]

5. The explanation is mandatory. A bare link with no explanation is forbidden -- it forces the reader to open the file to know if it matters, which defeats the purpose. If you cannot articulate the relevance in one sentence, do not include the link.

Skip the entire section (omit the heading) if:

• The vault has fewer than 3 contact folders
• No relevant lateral mentions found after the procedure above

Do NOT add an empty "Cross-references" header. Either the section has explained references, or it does not exist.

Step 2.6: Register Scan -- the truth, not only the generated view (CR-106)

Step 2.4 reads the triage document. That is a generated view of the register, and a view is filtered -- it carries what has a date or a P0/P1 and leaves the rest in YAML. A prep built on the view alone sees a subset, and sees it silently.

Query the vault's task register (_tasks.yaml, or whatever ops-config declares) for every open row naming the contact, then split:

Short and overdue beats important and new. An item that takes under a minute and has waited weeks belongs in front of the person now. Where the card is full at five, these go in a separate two-to-three-line block titled "while you are both here" (or its declared equivalent) -- it is not an agenda item and does not consume one of the five.

Always state the remainder. When more rows require the person than fit, say so with a count and point at the full list:

*Nine more open rows require them but do not belong in a lunch card -- see `Open actions` below.*

The failure this prevents is not omission -- a card of 24 items is useless. It is a card that gives no sign that anything was left out.

Step 3: Ask for Additional Context

After gathering file-based context, ask the user. Use the resolved language (see Language section below) for this prompt:

Swedish (default):

Jag har läst igenom [N] filer i [contact]s mapp. Här är vad jag har som underlag:

• Senaste samtalet: [date] -- [brief summary]
• Öppna punkter: [list key open items]
• [Any other relevant context found]

Vad handlar morgondagens/dagens samtal om? Ge mig gärna:

• Anledning till samtalet (uppföljning, nytt ämne, planerat möte?)
• Specifika frågor du vill ta upp
• Eventuell ny information sedan senast (mejl, händelser, etc.)

English:

I've read through [N] files in [contact]'s folder. Here's what I have as context:

• Latest conversation: [date] -- [brief summary]
• Open items: [list key open items]
• [Any other relevant context found]

What is tomorrow's/today's meeting about? Please share:

• Reason for the meeting (follow-up, new topic, scheduled?)
• Specific questions you want to raise
• Any new information since last time (emails, events, etc.)

If the user provides additional context (email threads, voice notes, specific topics), incorporate that.

Step 4: Generate Preparation Document

Create the file using the template below.

Step 5: Save and Report

1. Save to _contacts/contact-folder/YYMMDD-{keyword}-[context].md where {keyword} is the resolved filename keyword (förberedelse for Swedish, preparation for English -- see Output Filename section)
2. Offer to update CHANGELOG.md if one exists in the contact folder
3. Report what was created

Document Template (CR-005: agenda-card-first)

Two-tier structure:

• Top of file (60-second walk-in card): Agenda + Open actions. Self-sufficient -- a reader who only sees this can lead the meeting.
• Below the fold: Context, cross-references, deep-dive sections, background. Read if you have 5 more minutes.

A horizontal rule (---) separates the two tiers visually and conceptually.

# {strings.changelog.preparation_label}: [{strings.meeting_types.call}|{strings.meeting_types.meeting}] Alex-[Contact Name] -- [DD] [month] [YYYY][, HH:MM if known]

## {strings.preparation.agenda}

1. [{tag}] [One-sentence question or deliverable]
2. [{tag}] [One-sentence question or deliverable]
3. [{tag}] [One-sentence question or deliverable]
4. [{tag}] [One-sentence question or deliverable]
5. [{tag}] [One-sentence question or deliverable]

[5 items max in the walk-in card. Top 5 must be the most critical -- if there are more, they go in an appendix below.]

## {strings.preparation.open_actions}

**{strings.preparation.your_actions}:**
- [ ] [Action item -- status/context]

**{strings.preparation.their_actions}:**
- [ ] [Their action item -- what to follow up on]

*{strings.preparation.recording_names}: [contact display_name, company, 1-2 key entity/topic names from Step 2.5] -- put these in the calendar event title so the transcriber's ASR has the vocabulary and spells the proper nouns right.*

---

## {strings.preparation.deep_dive_separator}

## {strings.preparation.context}

[2 sentences max: When was last contact? What was discussed? What has changed since?]

## {strings.preparation.cross_references}

[Only include if Step 2.5 found relevant lateral mentions. Each line must include an explanation of why it matters -- bare links are forbidden.]

- [filename](path) -- [one-sentence explanation of why this is relevant to the upcoming meeting]

## 1. [{tag}] [Agenda item 1 title]

[Deep-dive content for agenda item 1: framing, options, what to push for, anticipated objections.]

**Suggested framing:** [How you might open this topic]
**Key question:** [The actual decision point]
**If they push back:** [Counter-frame or fallback]

## 2. [{tag}] [Agenda item 2 title]

[Deep-dive for item 2.]

## [N]. [More deep-dive sections as needed -- one per agenda item]

## {strings.preparation.background}

- [3-5 bullets on the relationship and longest-running threads]
- [Their role, company, what you collaborate on]

*{strings.metadata.created}: [YYYY-MM-DD]*

Template Notes

• Walk-in card on top: The agenda + open actions block at the top of the file is self-sufficient. If a reader has only 60 seconds before the meeting, they read this and walk in prepared. Everything below the --- is context they can read if they have more time.
• Tagged questions, not topics: Each agenda item must start with a tag ([DECISION], [DEMO], [STATUS], [QUESTION], [FYI]) and be phrased as a question or a clear deliverable -- NOT a noun phrase like "ProjectX status". See Agenda Tag System below.
• 5 items max in the walk-in card: If the meeting needs more topics, the top 5 are the most critical (P0 blockers, decisions that must happen today). Additional items go in a numbered "Appendix" or "Övriga punkter" section below the deep dives.
• Open actions visible without scrolling: Split by person (Yours / Theirs). The reader needs to see what they owe before walking in.
• Background moves to the bottom: It's reference material, not navigation. A reader doesn't need to know the relationship history to lead the meeting -- they need to know what to ask.
• Cross-references with explanation: Each cross-reference link must explain why the link matters in one sentence. Bare links are forbidden (see Step 2.5).
• Deep-dive sections include framing, not just facts: For each agenda item, suggest how to open the topic, what the actual decision point is, and how to handle pushback. This is the difference between briefing (backward) and preparation (forward).

Agenda Tag System (CR-005)

Every agenda item in the walk-in card must start with one of these five tags. The tag tells the reader the intent of the item without reading the deep-dive section.

Resolved labels come from strings.agenda_tags in the config (English defaults: DECISION/DEMO/STATUS/QUESTION/FYI; Swedish: BESLUT/DEMO/STATUS/FRÅGA/FYI).

Format rules:

• One tag per item, written in square brackets at the start
• Item text after the tag must be a question or deliverable, not a topic noun phrase
• Bad: [STATUS] ProjectX -- no question, no deliverable
• Good: [STATUS] ProjectX -- klart för Fortnox-integration?

Why this matters: The audit found that ~40% of preparation files were unusable in a 2-minute walk-in because the agenda was a list of topics rather than a list of questions. Tags + question framing fix both problems at once.

Single-Document Principle (CR-005)

A preparation file must be self-contained. It is not allowed to reference another preparation file as required reading.

If two prep streams converge (e.g., a weekly sync that needs both topic A and topic B context), merge them into a single prep document rather than creating two and linking. The reader should never need to open a second prep file to walk into the meeting.

Cross-references to transcripts, meeting summaries, strategic docs, or vertical docs are fine -- those are reference material. Cross-references to other prep files are not.

Prioritisation Rules (CR-005)

The walk-in card holds at most 5 agenda items. They must be the most critical items, not the first 5 reported.

Procedure for selecting the top 5:

1. Collect all candidate agenda items from gathered context + user input
2. Tag each candidate with priority signals: P0 blockers, time-sensitive decisions, items where the user is waiting on the contact
3. Sort by criticality
4. Top 5 go in the walk-in card
5. Items 6+ go in an "Övriga punkter" / "Additional items" section after the deep dives, NOT in the walk-in card

A 17-item agenda card (the audit found one in the wild) is a failure. If you have 17 candidate items, the prep file's job is to help the reader prioritise -- not to list them all at the top.

External-Counterpart Preparation (CR-032)

Everything above applies to every preparation file. This section applies only when the counterpart is external -- a prospect, customer, partner, competitor, or any first contact.

Detect the condition first. A counterpart is external when the document asserts claims about a person or organisation outside the user's own team: contact folders classified professional or confidential in _meta.yaml, _customers/ and _partners/ folders, and any first-contact meeting. It is not external for colleagues, direct reports, internal 1-on-1s, standups, or team meetings -- there these mechanisms are noise, and the CR-005 template alone is correct.

Why the distinction matters. Internal preparation describes shared facts. External preparation asserts things about a person the author has not verified -- their mandate, their tenure, who they must get sign-off from -- and being confidently wrong about that is expensive in the room. This is the same failure mode CR-015 and CR-016 address in /transcript: a confident wrong claim is worse than an honest gap, because it propagates into every document built on top of it.

1. Verification marker

Any claim about the counterpart that could not be grounded in a vault file or a source the user supplied is written inline as [UNVERIFIED] -- never silently omitted, never asserted.

**Beslutsroll:** C-level med sannolikt eget mandat inom AI-budgeten. Mandatgräns: [UNVERIFIED], fråga.
**Tid i roll:** [UNVERIFIED]

Where the gap is worth closing in the meeting, follow the marker with an instruction to ask. The marker is the same convention /transcript uses (? for an unconfirmed owner, Name? for an unverified proper noun) -- one vocabulary across the suite.

No-op condition: everything resolves against vault files. Then the section is silent.

2. Source-conflict resolution

When two sources disagree about the same fact, do not silently pick one. State the conflict, reason about which value is implausible given known context, and issue an explicit instruction about what may be said in the room. Then state the reduced claim that actually holds.

**Omsättning:** källorna anger 27,9 respektive 22,4 MUSD ARR, utan samstämmig valuta.
Den senare är orimlig för ett bolag av den här storleken. **Redovisa ingen av siffrorna
i rummet.** Det som håller: noterat, grundarlett, i storleksordningen 50-60 anställda.

The instruction is the point. A conflict noted without guidance leaves the reader to improvise with numbers that may be wrong.

3. Reliability grading

When the available material is thinner than for comparable prior preparations in the same folder, say so at the top of the speculative section and tell the reader how to carry it:

> Underlaget är tunnare än för [tidigare motpart]. Punkterna nedan följer av bolagets
> storlek och produkt, inte av något motparten sagt. Lägg fram dem som förväntningar
> och räkna med att bli korrigerad på minst en.

A preparation document that grades its own confidence is more useful than one that reads uniformly certain.

4. Sensitive ground

A per-counterpart negative list: what not to say, and why. This is distinct from the existing **If they push back:** field -- that is a response to something they raise; this is a prohibition on something the reader might volunteer.

**Känslig mark:** nämn inte prissättning innan syftet med mötet är klarlagt.
Beröm inte deras produkt -- beröm av kompetens läses ofta som misstanke.

Sources: a _meta.yaml note, a prior transcript where a topic landed badly, or a known third-party relationship (see Step 2.5).

5. Branched opening

For a first contact, or a meeting whose purpose is genuinely unknown, the opening is a qualifying question plus branches -- not a script.

**Öppning:** "[Kvalificerande fråga]" -- vänta på svaret.
- **Om A:** kör agendapunkt 1-3 som de står.
- **Om B:** släpp punkt 2 och 3. Det här är ett annat samtal -- ställ öppen fråga och lyssna.

Where an answer invalidates the premise of the prepared material, say so explicitly. Instructing the reader to abandon the prepared agenda is a legitimate and often correct output.

6. What they are measured on

One line on the counterpart's own success metric -- frequently not the same as their job description. It shapes what will land.

**Mäts på:** om produkten faktiskt blir bättre, inte på hur mycket AI de pratar om.

Where these land in the document

No new sections, no second file -- the single-document principle holds.

Out of scope

Do not infer intent from behavioural signals (when the counterpart booked, from which address, how quickly they replied). It is technically available and it is not this skill's job. Preparation reads the vault and what the user supplies.

Output Filename

Format: YYMMDD-{strings.filename_keywords.preparation}-[context].md

The keyword is agenda in every language (CR-089): a role keyword is an identifier that scripts select files by, so it comes from terms: in English, while the rest of the filename stays in the working language. Files written earlier as förberedelse/preparation are never renamed and are still found by every reader.

Contact name in filename:

• If _meta.yaml exists, use display_name (e.g., "David Ekberg" -> David-Ekberg)
• Otherwise, derive from folder name (title-case, hyphen -> space -> hyphen)
• Always use correct Swedish characters in names (e.g., "André" not "Andre")

The [context] part should be descriptive but concise. Examples:

Swedish-language folder:

• 260219-agenda-Alex-David-Ekberg.md
• 260219-agenda-erik-sandberg-antigravity-doable.md

English-language folder:

• 260303-agenda-daily-standup.md
• 260219-agenda-erik-sandberg.md

Use lowercase with hyphens. Include participants and optionally the main topic if there is a clear focus.

Slug contract (CR-021): keep å/ä/ö in every slug token, not only names -- möte not mote, utlösen not utlosen, never digit-substitutions like m0te, never mixed policy within one filename. Run the Swedish driftword check against the slug before saving. See ops-base General Naming Rules.

CHANGELOG Update

If a CHANGELOG.md exists in the contact folder, offer to add an entry:

- **YYMMDD: {strings.changelog.preparation_label} [type] [Contact]** - [ONE sentence describing key topics]. *(förberedelse, keyword1, keyword2, ...)* -> [filename.md]

Post-Meeting Lifecycle

Automatic: Superseded by /ops

When /ops processes a meeting transcript for the same date and folder, it automatically adds a superseded marker to the top of the preparation file:

> **Superseded** by [YYMMDD-meeting-summary.md](YYMMDD-meeting-summary.md)

The preparation file is not moved or archived -- it stays in place to preserve cross-reference links. The marker makes it immediately clear that the meeting has been processed. Monthly cleanup can later archive old superseded preparations in bulk.

Manual: Post-Meeting Update (Optional)

Separately, the user may ask to update the preparation with outcomes. When this happens:

1. Add {strings.annotations.outcome} annotations to relevant sections with what actually happened
2. Add a ## {strings.preparation.new_actions_post} section
3. Add a ## {strings.preparation.reflections} section if useful
4. Update the footer: *{strings.metadata.updated}: [date] ({strings.preparation.post_meeting_note})*
5. Update CHANGELOG if applicable

This turns the preparation into a complete meeting record that combines preparation + outcome.

String Resolution

Template strings marked as {strings.section.key} are resolved at runtime.

Resolution order:

1. Config strings section (if loaded via /ops or project config)
2. Language-matched defaults from base.yaml:
   • swedish -> strings_sv
   • english -> strings
   • input -> match detected language of existing files in the target folder
   • per_claude_md -> look up the target file path in the project CLAUDE.md LANGUAGE POLICY table (see Language section below)
3. Hardcoded strings already in template (fallback -- current Swedish defaults)

When no config is loaded (standalone use in a personal vault), the hardcoded Swedish strings apply unchanged.

Language

Language Determination (priority order)

Determine the output language before generating any content. Check these rules top-to-bottom, use the first match:

1. Config language: per_claude_md -- Look up the target file path in the project CLAUDE.md LANGUAGE POLICY table. The table maps file locations to languages. For example, if CLAUDE.md says projects/acme-mobile-v3/meetings/ -> English, then a preparation file saved there MUST be in English. This is the most common source of language errors -- always check the target path, not just the vault default.
2. Config language: english or language: swedish -- Use the explicitly configured language.
3. Config language: input -- Match the detected language of existing files in the target folder.
4. No config, target folder has existing files -- Match the language of existing files in the folder (check the most recent 2-3 files).
5. No config, no existing files -- Default to Swedish (personal vault convention).

Rules

• When language resolves to English: use English strings, English filename keyword (preparation), English headings, English content
• When language resolves to Swedish: use Swedish strings, Swedish filename keyword (förberedelse), Swedish headings, Swedish content. Swedish text MUST use correct characters (å, ä, ö) -- never substitute
• Technical terms and proper nouns stay as-is regardless of language
• Status labels (IN PROGRESS, TODO, COMPLETE, etc.) stay English regardless of language
• Bold formatting for questions and action items in either language

Common mistakes to avoid in Swedish output

• "forberedelse" -> "förberedelse"
• "mote" -> "möte"
• "pagaende" -> "pågående"
• "atgard" -> "åtgärd"
• "nasta" -> "nästa"
• "samtalsamnen" -> "samtalsämnen"
• "oppna" -> "öppna"

Why This Matters

The /preparation skill can be invoked from different contexts:

• Personal vault (_contacts/ folders) -- typically Swedish
• Org vault via /ops (e.g., acme/projects/*/meetings/) -- language depends on CLAUDE.md policy
• Direct invocation in a project folder -- check folder conventions

The same skill must produce the correct language for each context. When in doubt, check the CLAUDE.md LANGUAGE POLICY for the target vault.

Notes

• The skill works with the _contacts/contact-name/ folder structure -- no special setup needed
• Also works within org vaults (e.g., acme/projects/*/meetings/) when invoked via /ops -- language is determined by the config and CLAUDE.md policy
• Previous preparations provide continuity: the skill checks what was prepared last time and what actually happened
• Agendas can be created days in advance
• The numbered topic sections are the most valuable part -- they structure the conversation and prevent important items from being missed
• Full meeting lifecycle: /preparation (before) -> meet -> /ops or /transcript (after) -> preparation auto-marked as superseded