用途：cut-tickets 把已批准的方案、规格或对话拆分为工单，使每张工单成为他人可核对的承诺，并让整批工单形成可推进的前沿（即阻塞项已完成的工单）。
主要能力与规则：一、每个真实工作项一张工单，而非每个清单步骤一张；工单是贯穿 schema、API、界面与测试的垂直切片，规模控制在一个工作会话（一个全新上下文窗口）内，预重构放最前。二、每张工单写明从用户视角要构建什么、他人可核对的验收标准、以及阻塞它的工单；跟踪器支持原生依赖链接时用链接，否则写 Blocked by 行。三、不含基础设施标识符、密钥路径、合作方 URL 或同事姓名；描述步骤并指向内部运行手册，负责人用团队或角色。四、对其他变更或工单的引用一律用完整链接，不用裸编号。五、发布前先把拆分以编号列表呈现：标题、被谁阻塞、交付什么，并就粒度、阻塞边、合并与拆分提问；仅获批后发布，发布即一次 post（ASK-3），发布时默认应用跟踪器的 ready-for-agent 标签（除非另有指示），父项绝不被拆分关闭或编辑。六、大范围重构使用 expand 与 contract：先并行添加新形式，再按影响范围分批迁移，最后删除旧形式；每批各自成工单并被 expand 阻塞，contract 被所有批次阻塞。
落位：跟踪器及其标签词表记录在 docs/agents/tracker.md（SETUP-2）。若该文件不存在，应说明并请决策者运行 /setup-conventions；在此之前把本地工单写到 .scratch/<feature>/issues/NN-slug.md，并把 .scratch/ 加入 .gitignore，避免本地工单被 git add 提交到公开仓库。
模板与限制：工单模板见 references/ticket-template.md。工单中避免文件路径和代码，因其易过时；例外是原型中比文字更精确表达决策的片段（状态机、schema、类型形状），可内联决策密集部分并注明来源。
配套技能：来源方案用 plan-project，工单文字语气用 plain-voice，落地每张工单用 thin-slices，记录跟踪器与标签用 setup-conventions。
本次资料未提供收费、价格、平台与效果信息。