用途
Tracker Sync 是 GSDL 的跟踪器写入路径。它接收一个已经决定好的载荷——切片标题、评论正文、目标状态——并把它应用到项目所配置的跟踪系统上。这个技能不做任何判断：它不撰写评论、不选择切片边界、也不决定关闭哪些条目。由调用方决定，本技能负责执行。
定位与调用方式
该技能属于 SMALL 层级。每一项操作都是：解析一个 ID、发送一次变更、报告结果，无需使用更大的模型进行推理。由于这类跟踪器往返在流水线中调用频繁，成本差异是实际存在的。编排器会为这些操作各生成一个 SMALL 子代理。
本技能是非交互的：从不向用户提问。如果凭据缺失、ID 无法解析或变更失败，会返回一个 BLOCKER，精确描述失败内容以及调用方应做的处理，包括人类可以手动粘贴到跟踪器中的确切文本。
提供方解析
按照 gsdl 技能的 config.md，读取 .planning/gsdl.config.md（以及任何按项目的覆盖配置）。其中 ## Tracker 小节决定一切，包括 provider、子项的定义、父子关系方式、状态表示方式。支持的提供方包括：
- linear：子项是带 parentId 的 issue，采用原生子 issue，状态是团队上的工作流状态。
- jira：子项是 Sub-task issue，通过 fields.parent 关联，状态是 issue 工作流上的 transition。
- github：子项是同一仓库中的 issue，通过在父 issue 正文中的任务列表条目关联，状态为 open / closed（可选加状态标签）。
- notion：子项是跟踪器数据库中的一个页面，通过指向父页面的 relation 属性关联，状态是 Status/Select 属性值。
- none：子项是 tasks.md 中的一行，归属于其父切片，状态即复选框，外加 worklog.md 条目。
使用配置中记录的访问方式（mcp 或 api）。如果未记录，则先尝试 MCP，再尝试凭据路径，并将成功的方式写回配置。一次调用中对所有请求使用同一种方式。无论使用哪种方式，约束都完全相同——MCP 并非宽松路径。
操作 A — 创建子项（由 gsdl-decompose 第 4 步调用）
输入包括：PARENT_ITEM_ID（来自 seed.md 的条目，或 none）、PROJECT_ID（Linear 团队 ID / Jira 项目键 / owner/repo / Notion 数据库 ID）、SLICES（调用方已写好的有序 { title, description } 列表）。
适用于所有提供方的不变量：
- 应用配置的标签（
## Tracker → labels，默认为 gsdl），使代理生成的条目可被过滤。解析该标签；如果提供方要求标签必须预先存在，则先创建一次再复用。 - 给定 PARENT_ITEM_ID 时，将每个子项挂到其下。未给定时，仅在调用方明确要求的情况下创建独立条目，否则返回 BLOCKER。
- 绝不分配 sprint、cycle 或 iteration。父条目才是规划单元，其切片不是。仅当调用方为某个切片明确提供时才传递。
- 绝不发明状态。新的子项落在项目的默认/待办状态。
- 幂等性：如果调用方为某个切片传入了已存在的标识符，则更新该条目而不是创建重复项。
各提供方的具体实现细节（Linear 使用 save_issue / create_issue 或 GraphQL API；Jira 使用 REST API 创建 Sub-task，描述为 ADF 格式；GitHub 使用 gh issue create 并双向链接；Notion 为每个切片创建页面并设置 relation；none 不调用 API）在官方文档中有详细说明。返回时按顺序给出每个切片的标识符和 URL，以便调用方标记 tasks.md。部分失败时，明确说明哪些切片已创建及其 ID，方便调用方重试其余部分而不重复。
操作 B — 评论与状态转换（由 gsdl-execute 第 6 步和 gsdl-close-loop 第 9 步调用）
输入包括：ITEM_IDS（一个或多个条目标识符）、COMMENT（调用方写好的确切 markdown 正文）、TARGET_STATE（要移动到的状态名，如 Done、In Review，或 none 表示仅评论）。
如果 TARGET_STATE 为 none，则完全跳过状态转换——发布评论后返回。none 不是状态名；绝不将其与真实状态匹配，也绝不将其视为解析失败。状态名因团队、项目和工作流而异，绝不硬编码 ID。针对条目的真实可用状态对 TARGET_STATE 进行大小写不敏感匹配。若无任何匹配，返回 BLOCKER 并列出可用名称；不要猜测近似匹配。
各提供方的评论与转换方式在文档中有详细说明（Linear 通过 GraphQL 查询状态、评论、转换；Jira 评论为 ADF，转换按 to.name 匹配；GitHub 仅有 open/closed；Notion 评论为追加段落块，转换为设置 Status/Select 属性；none 追加到 worklog.md）。返回时按条目给出评论 URL（或 worklog 路径）、结果状态名（或 unchanged（comment-only））以及任何失败原文。
操作 C — 读取条目
供需要当前条目数据（状态、标签、父项、项目/团队 ID、建议分支）的调用方使用。各提供方的读取调用在文档中有说明，返回字段按原样返回，不做汇总或解释。
规则
- 绝不撰写内容——原样发布给定的评论正文。若缺失，则是 BLOCKER，而非撰写邀请。
- 绝不发明状态——针对条目的真实状态解析 TARGET_STATE，若不匹配则报告可选项。none 表示仅评论：不解析、不转换、不阻塞。
- 每一种方式都执行相同的不变量——MCP、API、本地 none 路径以及手动粘贴 blocker 都包含标签规则和无 sprint 规则。静默丢弃其中之一即是本技能的 bug。
- 除非调用方明确传入，绝不将父条目移至终态完成状态——GSDL 默认父项→配置的评审状态，子项→配置的完成状态。
- 除非调用方传入，绝不分配 sprint/cycle/iteration。
- 诚实报告部分失败——如果 5 个子项中创建了 3 个，准确说明是哪 3 个及其 ID，方便调用方重试其余而不重复。
- 报告提供方变通做法——例如 Jira 用 Task 代替 Sub-task 的回退、GitHub 状态只能表示为标签、Notion 属性不存在等，应在返回中说明，而不是让调用方以为写入一切正常。
- 首次解析出可用的访问方式后，将其写回配置。