什么是 会议协调员？

会议协调员是一个精致的技能工具，旨在作为 Openclaw Skills 生态系统中的高保真行政助手。它通过 gog CLI 直接集成 Google Calendar 和 Gmail，同时通过 Google Places 进行智能场地调研，从而实现复杂的调度自动化。该技能旨在减少调度摩擦，同时通过对每次外部沟通和日历变更的严格人工确认环节，确保用户保持绝对控制。

除了简单的预订，此工具还通过处理复杂的时区转换、提议优化选项并维护所有调度状态的细致本地记录来管理专业声誉。它专门考虑了旅行时间和会议后的缓冲时间，确保您的日历保持现实，并防止连续会议带来的疲劳。

下载入口:https://github.com/openclaw/skills/tree/main/skills/voshawn/meeting-coordinator

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

会议协调员 应用场景

• 安排新的虚拟或面对面会议，同时防止日历冲突。
• 使用经过批准的专业电子邮件模板重新安排或取消现有承诺。
• 为面对面的咖啡、午餐或晚餐会议寻找并建议高评分场地。
• 自动生成 Google Meet 链接或为确认的活动包含详细物理地址。
• 管理复杂的邮件往来，在无需手动反复沟通的情况下就会议时间达成共识。

1. 代理执行摄取过程以提取会议详情，并从本地上下文文件中交叉引用用户偏好。
2. 它使用专门的 Python 脚本搜索用户的日历可用性，以识别候选时段。
3. 对于面对面会议，它查询 Google Places API 以根据社区和交通偏好寻找合适的场地。
4. 向用户呈现一份全面的审批包，详细说明选项、时区和旅行影响。
5. 获得批准后，代理创建暂定日历占位并起草专业的沟通邮件。
6. 一旦对方回复，代理将最终确定日历活动，删除未使用的占位，并发送最终确认。

会议协调员 配置指南

确保您的系统上安装了 gog、goplaces 和 python3，以便在 Openclaw Skills 环境中使用此功能。

# 设置必要的环境变量
export GOG_ACCOUNT="your-email@gmail.com"
export GOOGLE_PLACES_API_KEY="your_api_key_here"

# 验证身份验证状态
gog auth list
test -n "$GOOGLE_PLACES_API_KEY"

您还必须在 USER.md 中定义您的偏好（姓名、时区、持续时间默认值），并在 SOUL.md 或 IDENTITY.md 中提供语气指南。

会议协调员 数据架构与分类体系

该技能在 memory/scheduling/in-progress.md 中使用标准化的 Markdown 架构维护状态，以确保透明度：

name: meeting-coordinator
description: Executive scheduling assistant for meeting coordination (email, calendar, venues, confirmations).
metadata:
  openclaw:
    emoji: "??"
    requires:
      bins:
        - gog
        - goplaces
        - python3
      env:
        - GOG_ACCOUNT
        - GOOGLE_PLACES_API_KEY
    primaryEnv: GOG_ACCOUNT
    homepage: https://github.com/voshawn/meeting-coordinator-skill

Meeting Coordinator

Operate as a high-precision executive assistant for scheduling.

Use This Skill When

Use this skill when the human asks to:

• Schedule a new meeting
• Reschedule or cancel an existing meeting
• Respond to or manage a forwarded scheduling email thread
• Find venues for in-person meetings
• Send meeting confirmations or follow-ups

Objective

Minimize scheduling friction while protecting the human's time and reputation:

• Propose high-quality options quickly
• Prevent calendar conflicts and duplicate bookings
• Keep every external message on-brand and approved
• Maintain a complete tracking record

Required Context

USER.md must provide

• Human full name
• Human email
• Calendar ID (may not match email)
• Home timezone (IANA, e.g. America/New_York)
• Preferred scheduling windows (days + hours)
• Default meeting durations by type
• Travel and post-meeting buffer preferences
• Location/transit preferences
• Venue preferences

SOUL.md or IDENTITY.md must provide

• Assistant tone guidelines
• Email signature block

Tools

• gog CLI with calendar and Gmail access
• goplaces CLI for venue lookup
• Local scripts:
  • scripts/check-availability.py
  • scripts/find-venue.py

If required context is missing, ask concise clarification questions before taking action.

Runtime + Credential Model

This skill relies on local CLI authentication and local config state.

• Required binaries: gog, goplaces, python3
• Required environment variables:
  • GOG_ACCOUNT: agent Gmail account identity used by gog
  • GOOGLE_PLACES_API_KEY: API key used by goplaces
• Required local config directories:
  • $HOME/.config/gog
  • $HOME/.config/goplaces
• If GOG_ACCOUNT or GOOGLE_PLACES_API_KEY is unset, stop and ask the human to configure credentials before continuing.

Credential handling expectations:

• gog uses OAuth credentials/tokens tied to the account selected by GOG_ACCOUNT.
• goplaces uses GOOGLE_PLACES_API_KEY.
• Never assume default account selection. Resolve and display the active account before running scheduling actions.

Preflight checks (required before first mutation in a session):

1. Verify account binding: echo "$GOG_ACCOUNT" and confirm it matches the intended agent Gmail account.
2. Verify gog auth state: gog auth list.
3. Verify goplaces key is present: test -n "$GOOGLE_PLACES_API_KEY".
4. Verify target calendar access with a read action before writes.

Non-Negotiable Rules

Approval gates

• Always get explicit human approval before:
  • Sending any email
  • Creating, updating, or deleting any counterparty-visible calendar event
  • Cancelling or rescheduling confirmed meetings
  • Making or modifying reservations
  • Moving existing events that create conflicts
• For every mutating action, present the exact command(s) first and wait for explicit approval tied to that action. Prior approvals do not carry forward if details change.
• Draft Review Checklist: When presenting a draft for approval, you must explicitly highlight and confirm:
  1. Recipients: Who exactly is on the To: and CC: lines.
  2. Dates & Times: The specific proposed or confirmed dates and times (clearly labeled with timezones).
  3. Location: The venue name and full address for in-person, or the virtual link for remote meetings.

Data integrity

• Never fabricate attendee emails, addresses, reservation details, or message IDs.
• Never use primary calendar unless the human explicitly instructs it.
• Always use timezone-aware timestamps.
• Always capture and track event IDs after create/update/delete actions.

Calendar construction

• In-person event: include full street address in --location.
• Virtual event: use --meet to auto-generate a Google Meet link and leave --location unset.
• Never include both physical location and virtual link for the same event.
• Travel and buffer blocks are private events with no attendees.
• CRITICAL: Ensure all Travel and Buffer blocks are marked as Busy (Opaque) so they block availability. Use the --transparency busy flag in the gog CLI.

Communication

• Draft first, then get approval, then send.
• CC the human on outgoing scheduling messages.
• Reply in-thread when a thread exists.
• Match tone and signature from SOUL.md/IDENTITY.md.
• Send outbound emails as HTML using gog gmail send --body-html.
• For email time display, use standard US labels (ET, CT, MT, PT) instead of IANA timezone IDs.
• If the counterparty is in a different timezone, include both in one line (example: 3:00 PM ET / 12:00 PM PT).

Canonical Meeting Record

Tracking file: memory/scheduling/in-progress.md Archive file: memory/scheduling/archive.md

Create one entry per meeting and update on every state change. Never delete active entries from in-progress.md.

Required fields:

• meeting_id (stable local identifier)
• counterparty_name
• counterparty_email
• meeting_type (virtual | coffee | lunch | dinner | other)
• purpose
• timezone
• status
• proposed_options
• selected_option
• calendar_event_ids_active:
  • tentative
  • main
  • travel_to
  • buffer_post
  • travel_home
• calendar_event_ids_deleted (list of {event_id, deleted_at, reason})
• venue (name + full address, if in-person)
• reservation (none | details/confirmation code | phone-needed | walk-in)
• thread_context (subject + message/thread identifiers when available)
• created_at
• updated_at
• activity_log (append-only)

Status lifecycle: intake -> awaiting-human-approval -> awaiting-counterparty -> confirmed -> completed Alternative terminal states: cancelled, closed-no-response

Allowed transitions:

• intake -> awaiting-human-approval | cancelled
• awaiting-human-approval -> awaiting-counterparty | cancelled
• awaiting-counterparty -> confirmed | awaiting-human-approval | closed-no-response | cancelled
• confirmed -> completed | awaiting-human-approval | cancelled
• completed | cancelled | closed-no-response -> eligible for archive move after retention window

Tracking Entry Template

Use this structure for each meeting entry:

##  — 
- meeting_id: 
- counterparty_name: 
- counterparty_email: 
- meeting_type: 
- purpose: 
- timezone: 
- status: 
- proposed_options: 
- selected_option: 
- calendar_event_ids_active:
  - tentative: []
  - main: []
  - travel_to: []
  - buffer_post: []
  - travel_home: []
- calendar_event_ids_deleted: []
- venue: 
- reservation: 
- thread_context: 
- created_at: 
- updated_at: 

### Activity Log
-  Entry created.

Editing Protocol (Strict)

1. Locate existing entry by meeting_id. If missing, create a new entry.
2. Update only the relevant entry. Do not rewrite, reorder, or remove unrelated entries.
3. On every change, update updated_at and append a one-line Activity Log entry.
4. Never erase event IDs after calendar deletions.
5. When an event is deleted/cancelled, move its ID from calendar_event_ids_active to calendar_event_ids_deleted with timestamp and reason.
6. Keep terminal entries in in-progress.md until retention rules permit archival.

Retention and Cleanup Policy (14-Day Rule)

Retention is based on updated_at.

• Only remove an entry from in-progress.md when BOTH conditions are true:
  • Status is terminal: completed | cancelled | closed-no-response
  • updated_at is at least 14 days old
• Preferred action is move (not delete) to memory/scheduling/archive.md.
• Non-terminal entries are never auto-deleted, regardless of age.
• If a non-terminal entry is stale for 14+ days, ask the human what to do; do not auto-close and do not delete.

Standard Workflow

1. Intake

• Extract: who, purpose, meeting type, deadline/urgency, constraints, location context.
• Resolve missing essentials before proceeding:
  • Counterparty email
  • Preferred date range
  • Meeting type (virtual or in-person)
• Apply defaults from USER.md only when the human has not specified values.

2. Availability Search

• Determine duration by meeting type (from request or USER.md defaults).
• Check multiple candidate dates inside preferred windows.

python3 scripts/check-availability.py r
  --calendar  r
  --date YYYY-MM-DD r
  --duration  r
  --start-hour <0-23> r
  --end-hour <1-24> r
  --tz 

• Conflict triage:
  • Hard conflict: multi-attendee commitments, immovable commitments
  • Soft conflict: personal/focus blocks that may be moved
• Never move conflicts without explicit approval.

3. Venue Search (In-Person Only)

python3 scripts/find-venue.py r
  --location "Neighborhood, City" r
  --type coffee|lunch|dinner r
  --min-rating 

• Generate 2-3 strong venue options.
• Validate full street address before using it in invites/emails.
• Filter by transit convenience and stated preferences.

4. Build Approval Packet For Human

Present a concise options table including:

• Date/time with display timezone labels (ET, CT, MT, PT)
• Dual-time display when counterparty timezone differs (example: 3:00 PM ET / 12:00 PM PT)
• Duration
• Venue + full address (if in-person)
• Travel/buffer impact
• Known conflicts and required moves
• Reservation feasibility

Do not contact the counterparty until the human approves.

5. Create Tentative Holds (After Human Approves Options)

• Create one tentative hold per approved option.
• Use color 8 for tentative.
• Record every hold event ID immediately.

gog calendar create  r
  --summary "HOLD:  ()" r
  --from "YYYY-MM-DDTHH:MM:SS" r
  --to "YYYY-MM-DDTHH:MM:SS" r
  --event-color 8

6. Outreach Email

• Use templates in references/email-templates.md.
• Draft message for approval first.
• After approval, send and store thread/message identifiers in tracking.
• Use --body-html when sending email.

7. Handle Counterparty Response

• accepted: move to confirmation workflow.
• counter-proposed: re-run availability and return to human for approval.
• declined without alternatives: ask human whether to close or send fresh options.
• No response after 2 business days: ask human whether to send follow-up.

8. Confirm Meeting

1. Delete unused tentative holds.

gog calendar delete   --force

Record each deleted hold in calendar_event_ids_deleted with timestamp and reason. Do not delete the meeting entry.

1. Create confirmed main event.

In-person:

gog calendar create  r
  --summary " // " r
  --from "YYYY-MM-DDTHH:MM:SS" r
  --to "YYYY-MM-DDTHH:MM:SS" r
  --location ", " r
  --description "" r
  --attendees 

Virtual:

gog calendar create  r
  --summary " // " r
  --from "YYYY-MM-DDTHH:MM:SS" r
  --to "YYYY-MM-DDTHH:MM:SS" r
  --attendees  r
  --meet

1. Add travel and post-meeting blocks when required by preferences.

gog calendar create  r
  --summary "Travel: Home -> " r
  --from "" r
  --to "" r
  --event-color 10

gog calendar create  r
  --summary "Buffer: Post-meeting" r
  --from "" r
  --to "" r
  --event-color 10

gog calendar create  r
  --summary "Travel:  -> Home" r
  --from "" r
  --to "" r
  --event-color 10

1. Reservation handling (in-person):

• Try online booking first.
• If online booking unavailable, ask human whether to call.
• Add reservation details to main event description when confirmed.

1. Send confirmation follow-up email (after approval).
2. Update tracking record with final event IDs and status confirmed.

9. Reschedule

1. Get explicit human approval.
2. Propose new options via Steps 2-4.
3. Send approved reschedule outreach.
4. On acceptance: update or recreate events, then move obsolete event IDs to calendar_event_ids_deleted.
5. Do not delete the meeting entry from in-progress.md.
6. Update reservation and tracking.

10. Cancel

1. Get explicit human approval.
2. Cancel or delete all related events.
3. Cancel reservation when applicable.
4. Send approved cancellation email.
5. Mark tracking entry cancelled with reason and timestamp.
6. Keep the cancelled entry in in-progress.md until 14-day retention threshold is met, then archive it.

11. Day-Before Confirmation

For in-person or high-stakes meetings:

1. Draft confirmation message.
2. Get approval and send.
3. Re-verify reservation details (if any).

Command Usage Notes

• Prefer absolute timestamps with explicit UTC offsets (-05:00, -08:00, etc.).
• Always read command output and capture created/updated event IDs.
• If a command fails, report the error and request next instruction; do not guess.
• Use IANA timezones internally for calculations and API calls; use ET/CT/MT/PT labels in outbound email copy.

Email Template Reference

Use references/email-templates.md for:

• Initial proposals
• Invite follow-ups
• Day-before confirmations
• Reschedule and cancellation messages
• No-response nudges

Quality Bar

Before finishing any scheduling task, verify:

• Human approvals are documented for every outbound action
• Calendar is conflict-checked and internally consistent
• Counterparty communications are concise, accurate, and timezone-clear
• Tracking file is updated with status, IDs, and timestamps
• No non-terminal tracking entries were removed from in-progress.md