技能介绍

解决什么问题

让 AI Agent 在 Slack 里干活，最大的坑是凭据管理：给模型一个 bot token，等于把一把钥匙交给它，泄漏、过期、scope 越权都接踵而至。另一个问题是 API 琐碎——Slack Web API 几十个端点、参数各异，模型要在每次调用前记住完整契约，出错率不低。

@user_15292d5a/yjkj-oo-slack 的思路是：把认证挡在 Agent 之外。凭据由 OOMOL 服务端注入，模型只通过 oo CLI 调用 Slack connector，从不接触原始 token，agent 只需要关心「做什么」而不是「怎么鉴权」。

核心能力

该技能暴露了 14 个动作，覆盖典型的 Slack 操作：

消息读写：post_message 发消息、reply_message 跟帖回复、update_message 修改 bot 自己发的消息、delete_message 删除消息。
信息查询：get_channel_messages 拉频道消息、get_thread 取整个线程、get_message_permalink 生成永久链接、get_conversation 和 get_user 拿元数据。
枚举列表：list_channels、list_conversations、list_users 列出 bot 可见的频道与用户。
特殊发送：post_ephemeral_message 发只有目标用户可见的临时消息，schedule_message 定时发送。

调用方式很直接：先用 oo connector schema 拿当前动作的权威输入/输出契约，再用 --data 传入符合 schema 的 JSON payload（可以是 JSON 字符串或 @path/to/file.json）。响应统一为 { "data": ..., "meta": { "executionId": ... } }，执行 id 在 meta.executionId 里，便于追踪。

关键原则：不要预跑认证流程。 假设用户已装好 oo CLI、已登录并连好 Slack，直接执行动作；只有命令真的报认证或连接错误时，才回退到一次性的首次配置。

适用边界与注意点

只读动作安全，写动作要确认。 get/list 类可以直接跑；create/update/post 类会改变 Slack 状态，执行前必须和用户确认 payload 与预期效果；delete 类属于破坏性操作，必须拿到明确批准。
bot 的可见范围就是动作的边界。 bot 没被邀请的频道、没权限看到的用户，列表和查询都覆盖不到——这不是技能 bug，是 Slack 权限模型决定的。
消息修改与删除仅限 bot 自己发的，update_message 和 delete_message 对其他成员的消息无效。
schedule_message 的定时任务受 Slack 侧规则约束，过期时间、目标频道权限都会影响实际效果。
额度与计费：凭据和额度由 OOMOL 服务端管理，遇到额度不足时需要在 OOMOL 控制台处理，技能本身不解决计费问题。