Toggl 时间追踪

需要解决的痛点

手动在 Toggl Track 里切换计时器、补录时间条目，或者批量调整项目结构，是一件琐碎但不得不做的事。直接对接 Toggl API 意味着你要自己管理 API token、处理过期刷新、处理 scope 授权，这些是业务逻辑之外的负担。当你只是想在某个任务结束时记录一条时间，或者给项目加个标签，调用链路的成本往往比操作本身还高。

技能如何工作

这个技能把 Toggl Track 的操作封装成 24 个 action，覆盖时间条目、项目、任务、标签和工作区五个对象的增删改查。它通过 oo CLI 调用 OOMOL 托管的 toggl connector，凭证由 OOMOL 在服务端注入，本地不接触原始 token。

调用分两步：先读取 connector 的 schema 拿到权威的输入输出定义，再用匹配的 JSON payload 执行 action。--data 可以接受内联 JSON 字符串或 @file.json，省略则发送空对象。响应统一包在 data 和 meta 里，meta.executionId 是本次执行的追踪 ID。

能力上分三档：

• 读取类（get_* / list_* / get_current_*）：查询当前用户、工作区、项目、任务、时间条目，安全，可直接运行。
• 写入类（create_* / update_* / stop_time_entry）：会改变 Toggl Track 状态，执行前需要和用户确认 payload 与预期效果。
• 删除类（delete_*）：破坏性操作，必须确认目标对象并获得明确批准。

适用边界

适合自动化场景：比如在脚本里批量创建项目结构、在任务完成后补一条时间条目、在周五下午拉一份本周时间报告。不适合做实时高频轮询，也不要把它当成 Toggl 的完整同步引擎——它不处理历史数据迁移，也不提供计费、报告导出等高级功能。

首次连接需要一次性配置：安装 oo CLI、登录 OOMOL、用 API key 授权 Toggl Track 连接。这些步骤只在命令因认证或连接问题失败时才需要重做。另外注意计费额度耗尽会返回 HTTP 402 / OOMOL_INSUFFICIENT_CREDIT，需要充值后才能继续。