Files
chill_notes/Prompts/Meeting Research Prompt.md
2026-04-27 23:13:16 +08:00

6.9 KiB
Executable File

Meeting Research Prompt

Standalone prompt for pre-meeting research. Reads selected vault notes (People profiles, prior meeting notes, project docs) and the meeting note, then writes a structured research briefing into the meeting note so the user is prepared before the meeting starts.

Invocation pattern:

claude --dangerously-skip-permissions 'Follow the instructions in /abs/path/Meeting Research Prompt.md. Meeting note: Meetings/2026-03-25 - Weekly Team Sync.md. Research notes: People/Alice Smith.md, Meetings/2026-03-18 - Weekly Team Sync.md, Projects/Alpha.md.'

Optional parameters:

  • People Folder: — folder name for People notes (default: People)
  • Additional instructions: — free-text user instructions appended to the invocation

Step 1: Parse Invocation Parameters

Extract from the calling message:

  • Meeting note: → vault-relative path to the meeting note file
  • Research notes: → comma-separated list of vault-relative paths to context notes
  • People Folder: → folder for People notes (optional)
  • Additional instructions: → free-text guidance from the user (optional)

Vault root: The current working directory is the vault root. All vault-relative paths in the calling message resolve from there.

Path resolution: Try each path as-is first. If not found, prepend vault root and try again. If a research note is not found, skip it with a warning rather than failing — the user may have renamed or moved it.


Step 2: Read Meeting Note

Use the Read tool to open the meeting note. Extract from frontmatter:

Field Purpose
meeting_subject Meeting title for context
meeting_date Meeting date
meeting_start Start time
meeting_end End time
meeting_invitees Attendee list (wikilinks)
is_recurring Whether this is a recurring meeting

Error conditions:

  • File does not exist → error: "Meeting note not found: [path]. Check the path and try again."

Step 3: Read Research Notes

Use the Read tool to open each research note. For each note, capture:

  1. Frontmatter metadata — any structured data (role, title, email, dates, etc.)
  2. Body content — the full note content

Categorize each note by type:

  • Person note — has frontmatter with name/role/email fields, or is in the People folder
  • Meeting note — has meeting_subject and meeting_date in frontmatter
  • Project/other note — everything else

Step 4: Gather Additional Context

If a People Folder was provided, cross-reference meeting invitees with People notes:

  1. Parse meeting_invitees wikilinks from the meeting note
  2. For any invitee whose People note was NOT already included in the research notes, do a quick read of their note (if it exists) to get their role/title
  3. This provides baseline context on all attendees without requiring the user to manually select every person

Step 5: Follow Additional Instructions

If Additional instructions were provided, incorporate them into the research. These may include:

  • Specific questions to answer about attendees or topics
  • Directions to focus on particular aspects (e.g., "focus on project status updates from the last month")
  • Requests to cross-reference with other vault content
  • Context about why this research is needed

Treat additional instructions as high-priority guidance that shapes the research output.


Step 6: Generate Research Briefing

Create a structured research briefing with these sections:

Briefing Structure

## Research

### Attendees

| Name | Role | Context |
|------|------|---------|
| [[Name]] | Title / Team | Key context from People note or prior meetings |

### Background

[2-4 paragraphs synthesizing relevant context from the research notes. Connect the dots between attendees, prior meetings, and project context. Focus on what the user needs to know going into this meeting.]

### Prior Meeting Outcomes

- **YYYY-MM-DD — Meeting Subject** — Key outcomes, open action items, unresolved topics
- [One bullet per prior meeting note provided]

### Open Questions

- [Questions the user might want to raise based on the research]
- [Unresolved items from prior meetings]
- [Gaps in context that could be clarified in this meeting]

Briefing Guidelines

  • Be actionable: Focus on information that helps the user prepare, not exhaustive summaries
  • Wikilink all names: Wrap ALL person names in [[Name]] wikilinks
  • Connect the dots: Don't just summarize each note in isolation — identify relationships, continuity from prior meetings, and evolving topics
  • Highlight changes: If a person's role or a project's status has changed since the last meeting, call it out
  • Respect the user's time: Keep it scannable. Use tables for structured data, bullets for lists, and bold for emphasis
  • Omit empty sections: If there are no prior meetings to reference, skip "Prior Meeting Outcomes". If the attendee list is trivial (1:1 with someone well-known), keep the table minimal
  • Additional instructions first: If the user provided specific instructions, make sure those are addressed prominently in the briefing

Quality Checklist

Before writing the briefing, verify:

  • ALL person names wrapped in [[Name]] wikilinks
  • Attendee table includes all meeting invitees (not just those in research notes)
  • Prior meeting outcomes include any open action items still relevant
  • Additional user instructions have been addressed
  • No important context from the research notes is missing

Step 7: Write Research to Meeting Note

Use the Edit tool to insert the research briefing into the meeting note.

Placement: Insert the ## Research section after the frontmatter closing --- and any existing template content (like attendee lists or meeting links). Place it BEFORE any ## Notes, ## Summary, or other user/LLM-generated sections.

If a ## Research section already exists: Replace it entirely with the new briefing. Preserve all other sections.

Strategy:

  1. Read the current meeting note content
  2. Identify the insertion point (after frontmatter/template header, before other content sections)
  3. If ## Research already exists, replace only that section
  4. If it doesn't exist, insert the new section at the appropriate location
  5. Use a single Edit call to write the briefing

Step 8: Update Frontmatter

After successfully writing the research briefing, update the meeting note frontmatter:

The research_notes field should already be set by the plugin (listing the selected notes as wikilinks). No additional frontmatter changes are needed.


Step 9: Report Results

Summarize to the user:

Meeting research complete for: [meeting note filename]

Research sources:
- [N] vault notes analyzed
- [N] attendees profiled

Sections written:
- Attendees ([N] people)
- Background ([N] paragraphs)
- Prior Meeting Outcomes ([N] meetings referenced)
- Open Questions ([N] items)