dida365-todo-agent

Dida365 待办 Agent

在配置 Dida365 账号、路由规则，或查询、创建、更新、移动、完成、删除任务、管理标签及拆分 Checklist 时使用本 Skill。

本 Skill 与具体框架无关。它假定宿主 Agent 能调用 references/adapter-contract.md 中定义的逻辑能力；适配器可以通过函数、REST 封装、插件、MCP 工具或其他集成方式提供。

授权与首次配置

1. 每轮第一次执行 Dida365 操作前，先检查授权状态。
2. 应用凭证和 OAuth 令牌必须保存在操作系统 keyring 或其他平台认可的安全密钥管理器中。绝不要让用户把 Client Secret、access token 或 refresh token 粘贴到聊天中。
3. 在实际运行适配器的同一运行环境中配置应用凭证。若安全凭证存储不可用，先检查会话或服务环境并修复集成；不得退回明文文件，也不得打印已保存的凭证。
4. OAuth 必须使用 Dida365 开发者后台登记的准确 Redirect URI。若客户端登记了固定回调地址，动态选择 loopback 端口会失败。始终使用登记的主机和端口；从其他电脑授权时，必须通过端口转发或登记的服务器地址等获准方式确保回调能到达授权主机。
5. 若未授权，启动适配器的 OAuth 流程，只展示授权 URL，并等待用户完成授权。绝不要暴露授权码或令牌。若浏览器出现 invalid_request 或 Invalid redirect，立即停止并修正开发者后台的 Redirect URI，不要猜测地址后重试。
6. OAuth 完成后再次检查授权状态。浏览器到达回调页面不代表授权成功。
7. Dida365 凭证和适配器配置必须与其他服务的凭证、配置隔离保存。

前置条件

1. 写入任务前，读取路由配置并使用其中准确的 revision。
2. 如果没有有效配置，必须先完成首次路由配置流程，再创建任务。

首次路由配置流程

1. 通过适配器列出项目和现有标签。
2. 一次只问一个问题，了解每个可路由项目的用途、正例、反例和优先级。
3. 询问兜底项目、时区、置信度阈值、优先级策略和最多使用的现有标签数量。
4. 使用适配器返回的稳定 Project ID 构建完整配置，绝不自行编造 ID。
5. 提交配置进行校验和确认。用户明确确认前，保存配置不得改变状态。
6. 展示完整规则摘要并请求确认。
7. 只有在用户明确确认后，才能通过适配器的确认机制提交配置。
8. 校验已保存的路由配置；校验有效前不得写入任务。

创建任务的决策

按以下顺序处理：

1. 保留用户明确指定且有效的项目、优先级、标签、日期和 Subtasks。
2. 未指定时，根据配置中的描述、示例、优先级和兜底项目分类。
3. 独立于项目生成优先级：无优先级 0，低 1，中 3，高 5。
4. 从适配器返回的现有标签中选择不超过配置上限的标签。
5. 如果有用标签不存在，把“新标签 + 任务创建”合并为一次确认；用户确认前绝不写入任何一项。
6. 任务包含多个交付物或阶段、涉及多人、不太可能一次完成、跨越多天，或不拆分就难以跟踪时，视为大型任务。
7. 对大型任务，提出 2–7 个以具体行动开头且互不重复的 Subtasks，展示后等待用户确认或修改。
8. 调用适配器前，生成符合 references/routing-decision.schema.json 的内部决策记录。

普通个人提醒和分类明确的日常工作，如果使用现有标签且无需 Subtasks，可以直接创建。以下情况必须先询问：重要任务置信度不足、时间无法解析、多个项目并列、疑似重复任务、需要新标签，或需要提出 Subtasks。

创建任务

1. 向适配器提交选定的 Project ID、当前路由 revision、标准化字段、优先级、现有标签和决策审计字段。
2. 包含 Subtasks 或新标签的请求在改变状态前必须返回 confirmation-required。展示准确摘要，并明确说明新标签会 inline 写入任务；请求一次用户确认。
3. 只有适配器返回 confirmation token 且用户明确确认完全相同的摘要后，才能提交。确认提交时把新标签随任务 tags 字段写入，不调用独立的标签创建端点。
4. 成功后报告标题、项目、优先级、标签、日期时间、Subtasks 和任务 ID。
5. 真实验收时，必须再读取一次并核对远端状态后，才能报告成功。

查询与修改

1. 尽可能使用有界的项目、日期和状态条件搜索任务。
2. 如果只有一个任务匹配，读取它并使用其 task ID、Project ID 和版本。
3. 如果多个任务匹配，展示简洁候选项并请用户选择；绝不只凭标题猜测。
4. 只更新发生变化的字段，并携带预期版本。
5. 移动任务必须使用准确的 task ID、源/目标 Project ID 和预期版本。
6. 完成和删除始终先准备确认操作，展示摘要、获得明确确认后再提交。