技能介绍

解决什么问题

团队在 Worksnaps 上记录工时、管理项目与任务，但数据困在网页后台里。人肉导出、跨系统对齐、给自动化脚本补认证逻辑，都是实打实的成本。当你想让 AI Agent 读取当前用户参与的项目、某个项目下的任务与分配、时间条目或项目报告时，还得自己处理 token、请求格式和响应结构。这个技能把这一层封装掉：凭证由 OOMOL 服务端注入，你只关心"执行哪个动作、传什么参数"。

它如何工作

核心是一个 worksnaps connector，通过 oo CLI 调用，OOMOL 在服务端注入凭证，本地不接触原始 token。目前暴露 10 个动作，全部是读取类：

get_current_user：读取当前 Worksnaps 用户 profile
get_project / get_task / get_project_time_entry：按 ID 读取单个项目、任务或时间条目
get_project_time_report：在限定时间窗口和用户集上读取项目报告
list_projects / list_project_tasks / list_project_task_assignments / list_project_time_entries / list_project_user_assignments：按项目维度列出项目、任务、任务分配、时间条目和用户分配

调用流程是固定的两步：先检查动作契约，拿到权威的输入/输出 schema，再构造匹配 schema 的 JSON payload 运行动作。--data 接受 JSON 对象字符串或 @path/to/file.json，省略则发送 {}。响应统一为 { "data": ..., "meta": { "executionId": "..." } }，执行 id 位于 meta.executionId，可用于对账和排障。每个动作的参考文件里写明了用途和确切命令；构造请求前建议先拉取一次实时 schema，避免本地理解与线上契约漂移。

适用边界与注意点

当前动作全部是读取类（get / list），可以直接运行。若以后接入会改变 Worksnaps 状态的动作，运行前必须与用户确认确切 payload 和影响；delete / remove 类破坏性操作要拿到明确批准。
oo CLI 的登录与 Worksnaps 连接是一次性步骤，不要每次调用都重复执行，只在命令因认证或连接错误失败时才回退处理。
排障时先区分失败原因：是 payload 与 schema 不匹配，还是凭证过期、scope 不足或计费中断。