Meeting Brief

This is an OMH meeting-brief workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).

Why This Exists

meeting-brief exists to turn scattered context into a focused agenda, discussion prompts, decision points, and a record template without pretending the meeting already happened.

Do Not Use When

• The user needs observed meeting minutes, decisions, or action items but has not provided notes.
• The request is strategy synthesis without a meeting audience, agenda, or decision ceremony.
• The follow-up is implementation work that already has accepted requirements and should become a plan or handoff.

Examples

Good example:

• Prompt: Prepare a meeting agenda for a leadership sync on setup UX, plugin bridge defaults, and release risk.
• Expected behavior: Prepare agenda topics, prompts, decisions needed, and a record template with unknowns marked.
• Why: The request is preparation for a meeting and should separate prep from observed outcomes.

Bad example:

• Prompt: meeting-brief summarize what the team decided yesterday.
• Expected behavior: Ask for meeting notes or route to an ops/status summary with explicit evidence gaps.
• Why: A prepared agenda cannot be treated as observed minutes or decisions.

Completion Checklist

• The agenda, participants or audience, decisions needed, and record template are named.
• Meeting prep, observed minutes, accepted decisions, and action ownership are separate states.
• Missing context that would change the meeting structure is surfaced.

Recovery Notes

• If participants, purpose, or decision owner are missing, ask for the one field that changes the agenda.
• If minutes or decisions were not observed, keep the output as prep rather than record.

Use When

Use when Hermes should prepare a meeting agenda, discussion prompts, decision points, and a record template.

Strong routing signals: `meeting-brief`, `meeting brief`, `meeting agenda`, `agenda`, `discussion prompts`, `decisions needed`, `record template`, `meeting topics`, `회의 주제`, `회의 아젠다`, `아젠다`, `회의 준비`, `논의 질문`, `결정할 것`, `기록 템플릿`

Catalog Metadata

Category: meeting Phase: preparation Quality tier: facilitation-gated Reasoning demand: light

Quality bar:

• Turn context into agenda topics, prompts, decisions needed, and a record template.
• Keep prep distinct from actual meeting minutes or accepted decisions.
• Identify missing context that would change the meeting structure.

Required inputs:

• meeting goal
• audience
• known context
• decision topics

Expected outputs:

• agenda
• discussion prompts
• decisions needed
• action-item template

Artifact expectations:

• meeting brief or record template when the wrapper captures it

Safety rules:

• Do not claim the meeting happened from a prepared agenda.
• Separate proposed action items from observed decisions.
• Use a later status or decision record for actual meeting outcomes.

Runtime Evidence

Use the current host's own tools and subagent/task mechanism when available; otherwise run the same lanes sequentially or name the unavailable capability. A prepared plan, handoff, checklist, or skill installation is not execution, review, CI, merge-readiness, or merge evidence. Record actual tool results, or not_observed / not_available, in the record; never invent dispatch or host accounting. Treat supplied context as advisory, not proof of hidden memory reads or writes. State scope, constraints, verification, and the stop condition before work. Reply in the user's own words and the host's own voice: the host's persona owns reply language, tone, speech level, and sentence endings, progress updates included (where it sets no language, use the one the user wrote in), and OMH shapes structure and content only; OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done. Supporting paths are relative to this skill directory; sibling skill paths are relative to its parent. Resolve them from the host-provided skill base directory ({baseDir} on hosts that provide it), never a hardcoded install location. A named workflow not installed here is unavailable, not permission to emulate its host-specific capabilities. Verify through the real surface before done.