gws-meet

gws-meet skill 概览

gws-meet 是 googleworkspace/cli 里面向 Google Meet 的 skill，用于通过 gws CLI 管理 Meet spaces 和会议产物。它最适合那些希望借助 workflow agent 自动化 Meet 操作，而不是手写 API 调用的用户，尤其适合需要处理会议记录、录制、转写或 space 管理的场景。

这个 gws-meet skill 不是一个泛用的“聊聊 Meet”提示词。它对应的是实际的 API 资源，并且要求输入结构化意图：你要哪个资源、需要哪个 method，以及你能提供哪些标识符或筛选条件。这让它很适合 Workflow Automation，但前提是你能给出清晰的会议上下文。

gws-meet 的适用场景

当任务是检查或管理 Meet 数据时，适合使用 gws-meet，例如列出 conference records、获取某条记录、处理参与者或录制内容，或者更新 meeting space。它也很适合你想要一套可复用的 gws-meet usage 模式，而不是零散地点网页控制台。

安装前最需要确认什么

最关键的准入门槛是环境是否就绪。gws-meet 依赖 gws 二进制文件，以及 ../gws-shared/SKILL.md 中的共享认证与安全规则。如果你的工作区满足不了这些前置条件，这个 skill 的表现就不会稳定可靠。

这个 skill 为什么不一样

gws-meet 的价值在于它和 API 对齐的结构：先发现可用 method，再调用你真正需要的精确资源动作。这样能减少猜测，但也意味着它最适合你已经知道目标对象的场景，比如 conference ID、meeting space 或日期范围。

如何使用 gws-meet skill

安装并验证前置条件

做 gws-meet install 时，先按仓库的 skill 流程安装，并确认你的环境里能正常使用 gws。然后在调用任何 Meet method 之前先阅读 ../gws-shared/SKILL.md，因为这个共享文件定义了认证、全局标志和该 skill 继承的安全约束。

一个实用的安装检查方式是先运行 Meet 入口的 CLI 帮助，再确认你的账号对计划操作的资源拥有所需权限。

先从 skill 入口文件开始

skill 的入口文件是 SKILL.md。先读它，再按它推荐的方法发现模式往下走。对于 gws-meet usage 来说，最重要的习惯是在调用资源之前先检查资源：

gws meet --help
gws meet <resource> --help
gws meet <resource> <method> --help

这样可以避免把提示词过度贴合到错误的资源上，也避免在 method 根本不存在时误以为它可用。

把模糊目标改写成好提示词

一个适合 gws-meet 的强提示词应该说明：

• 资源：conferenceRecords 或 spaces
• method：get、list、create、patch 或 endActiveConference
• 你已经知道的标识符或筛选条件
• 你想要的输出，例如摘要、指定字段集合，或后续动作

比如，不要只说“帮我查一下 Google Meet 数据”，更好的说法是：“用 gws-meet 列出最近 7 天的 conference records，然后按开始时间和参与人数总结最新的 5 条。”

先读对文件

这个仓库刻意保持轻量，所以最有信息量的阅读顺序是：

1. SKILL.md
2. ../gws-shared/SKILL.md
3. gws meet --help 的 CLI 帮助

这个顺序很重要，因为 skill 本体很短，而真正决定执行规则的是共享 skill。如果跳过共享文件，就可能把认证或安全相关行为处理错。

gws-meet skill 常见问题

gws-meet 只适合管理员吗？

不是。只要你有授权，并且需要自动化 Meet 操作，gws-meet 对任何授权用户都很有用；但访问能力仍然取决于你的账号权限和具体的 API 资源。如果你在 Google Workspace 里本来就无权读取或修改某个会议对象，这个 skill 也不会绕过这些限制。

我应该用 gws-meet，还是直接用普通提示词？

当你想要可复用、由工具驱动、尽量少假设的操作时，就用 gws-meet skill。普通提示词适合头脑风暴，但当任务需要精确选择 API method、保持一致的 CLI 用法，并且有自动化路径时，gws-meet 更合适。

最大的限制是什么？

这个 skill 的边界是有意收窄的。它只聚焦 Meet 资源，不提供宽泛的 workspace 管理能力。如果你的目标是把 Calendar、Drive 或 Chat 一起串起来跑，gws-meet 只是整个 workflow 里的其中一环。

gws-meet 适合新手吗？

如果你已经知道要处理哪个会议对象，那它是适合新手的。可如果你从“我所有会议里发生了什么？”这种模糊问题开始，它就没那么友好，因为这个 skill 最擅长的是明确的资源名称、ID 和日期范围。

如何改进 gws-meet skill

直接给 agent 明确的 Meet 目标

提升 gws-meet 结果最快的方法，就是一开始就给出具体目标：conference ID、meeting space、时间窗口或筛选条件。比如“找出 team-sync 在周一到周五之间的最后一条 conference record”就比“帮我查会议”有用得多。

一次只提一个 API 形态的任务

这个 skill 在每个请求都能清晰对应到一个资源和一个 method 时表现最好。如果你需要的是 list → inspect → update 这种链式流程，就拆成多个步骤，这样工具可以先验证每一步结果，再继续下一步。

加上输出约束

告诉 agent 你要的是原始 CLI 输出、简洁摘要，还是整理成表格的字段。这样可以减少来回沟通，也能让 gws-meet 把注意力放在真实工作流上，而不是花时间决定展示格式。

注意常见失败模式

最常见的错误是前置条件缺失、资源选择过于模糊，以及默认某个 method 支持你其实还没确认的数据。第一次失败后，下一轮提示词要补上精确的 gws meet <resource> <method> 形态、标识符，以及日期或归属范围。