技能介绍

要解决的问题

把 Google Tasks 接进自动化脚本或 Agent 时，最先撞上的不是 API 调用本身，而是凭据：OAuth token 怎么拿、怎么存、过期了谁负责刷新、scope 不全时报错怎么定位。自己维护这套链路，代码还没写几行，安全审计和重试逻辑已经堆起来了。这个技能的思路是把这些事外包出去：你只描述要做什么，凭据由 OOMOL 在服务端注入。

技能如何工作

技能通过 OOMOL 连接的账号调用 googletasks connector，由 oo CLI 执行，一共暴露 16 个动作，覆盖任务列表与任务两个层级。

调用流程是固定的两步：

先用 oo connector schema 拉取权威的输入/输出 schema，不要凭记忆构造 payload。
用匹配 schema 的 JSON 作为 --data（可以是字符串，也可以是 @path/to/file.json），响应里的 meta.executionId 可用于追踪本次执行。

能力大致分三组：

列表管理：create_task_list、list_task_lists、get_task_list、patch_task_list、update_task_list、delete_task_list
任务操作：insert_task、list_tasks、list_all_tasks、get_task、patch_task、move_task、update_task_full、delete_task
批量清理：clear_tasks 一键清除某个列表中所有已完成的任务

适用边界与注意点

权限分层：读类动作（get / list）可以直接执行；写类动作（create / update / patch）执行前必须与用户确认 payload 和影响；delete_task、delete_task_list、clear_tasks 属于破坏性操作，必须拿到明确批准。
不要重复登录：只要 oo CLI 已安装且 Google Tasks 已连接，直接执行动作即可，不要主动跑 oo auth login。首次设置（安装 CLI、登录、OAuth2 连接、scope 补全、计费充值）只在命令确实因对应原因失败时才介入。
废弃别名：update_task 是 update_task_full 的废弃别名，新代码直接用后者。
计费约束：遇到 HTTP 402 / OOMOL_INSUFFICIENT_CREDIT 说明额度耗尽，需先在 OOMOL 控制台充值再重试，这不是代码 bug。