mcpField
T
to-tickets

to-tickets

github.com/leandrocfe开发4195 次安装12 周前更新
代码仓库

关于 to-tickets

用于将计划、规格说明或对话拆分为纵向切片工单的技能,并标明工单间的阻塞依赖。它要求先让用户确认拆分,再按依赖顺序发布到已配置的工单跟踪器或本地文件。

主要功能

  1. 01整理对话、规格或代码库背景
  2. 02拆分可独立验证的纵向切片
  3. 03标注工单阻塞依赖
  4. 04通过用户反馈迭代拆分
  5. 05按依赖顺序发布工单

适用场景

  1. 01把功能计划整理为可执行工单
  2. 02安排跨架构层的增量交付
  3. 03规划大型重构的扩展与收缩步骤
  4. 04将已批准工单发布到跟踪器

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/leandrocfe/skills --skill to-tickets

安装后在 Claude Code 中输入/to-tickets确认已加载。

附带文件agents/openai.yaml

详细介绍

创建工单

将计划、规范或对话拆分为一组 工单——采用 tracer bullet 风格的垂直切片,每个工单都说明会阻塞它的工单。

工单跟踪器和 triage 标签词汇表应该已提供给你;如果没有,请运行 /setup-leandrocfe-skills。

流程

1. 收集上下文

利用对话中已有的上下文。如果用户提供了参考资料作为参数(规范的路径、工单编号或 URL),请查找并阅读其完整正文和评论。

2. 探索代码库(可选)

如果还没有探索代码库,请进行探索,以了解代码的当前状态。工单标题和描述应使用项目领域词汇表中的术语,并遵循你负责区域的 ADR。

寻找可以预先整理代码的机会,以简化实现。“先让改动变得容易,再轻松完成改动。”

3. 起草垂直切片

将工作拆分为 tracer bullet 工单。

  • 每个切片都要贯穿所有层(架构、API、UI、测试),形成一条狭窄但完整的路径——要纵向贯穿,而不是只覆盖单一层的横向切片
  • 每个已完成的切片都能独立演示或验证
  • 每个切片的规模都应能在一个新的上下文窗口中完成
  • 任何预先整理代码的工作都必须先进行

为每个工单指定其 阻塞关系——必须先完成的其他工单。没有阻塞项的工单可以立即开始。

大范围重构是垂直切片的例外。 大范围重构是指一项机械性改动——例如重命名一列或更改共享符号的类型——其影响范围遍及整个代码库:一次编辑就会破坏成千上万个调用点,任何垂直切片都无法单独通过测试。不要强行将其拆成 tracer bullet;应按 expand–contract 顺序进行。首先扩展:在保留旧形式的同时加入新形式,避免破坏现有代码。接着,按影响范围(例如按软件包、按目录)分批迁移调用点;每批都作为独立工单,并依赖扩展阶段。由于旧形式仍然存在,每批迁移完成后 CI 都能保持通过。最后收缩:当不再有任何调用方使用旧形式时,在一个依赖所有迁移批次的工单中删除旧形式。如果各批次无法单独通过测试,就保留这个顺序,但让它们共用一个集成分支,并让所有批次都阻塞最终的集成与验证工单——只有在那里才承诺通过测试。

4. 征求用户意见

用编号列表展示提议的拆分。每个工单都要列出:

  • 标题:简短且能说明内容的名称
  • Blocked by:必须先完成的其他工单(如果有)
  • 交付内容:该工单实现的端到端行为

询问用户:

  • 粒度是否合适?(太粗 / 太细)
  • 阻塞关系是否正确——每个工单是否只依赖确实会阻塞它的工单?
  • 是否应该合并某些工单,或进一步拆分?

反复调整,直到用户批准拆分结果。

5. 在配置的跟踪器中发布工单

发布已批准的工单。具体方式取决于 /setup-leandrocfe-skills 配置的跟踪器——两种情况下工单都相同,只是阻塞关系的表示方式不同:

  • 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下为每张工单编写一个文件,从 01 开始,按依赖顺序编号(阻塞项优先)。每个文件的“Blocked by”列出其依赖项的编号/标题。使用下面的单张工单文件模板——每个文件一张工单,绝不合并到单个文件中。
  • 真实工单跟踪器(GitHub、Linear 等) → 按依赖顺序(阻塞项优先)为每张工单发布一个 issue,以便每张工单的阻塞关系可以引用真实标识符。平台支持原生阻塞关系/子 issue 时,请使用该功能;否则,在每张工单的“Blocked by”中填写阻塞它的 issues。除非另有指示,否则添加 triage 标签 ready-for-agent——这些工单在设计上可由 Agent 领取。

按前沿推进:所有阻塞项均已完成的工单。对于纯线性链,这意味着从上到下推进。

不要关闭或修改任何父 issue。

— <工单标题>

**要构建的内容:**从用户视角描述此工单实现的端到端行为,而非逐层罗列实现步骤。

**Blocked by:**阻塞此工单的其他工单编号/标题,或者“无 — 可立即开始”。

**状态:**ready-for-agent

  • 验收标准 1
  • 验收标准 2

父级

跟踪器中父 issue 的引用(如果源自现有 issue;否则省略本节)。

要构建的内容

从用户视角描述此工单实现的端到端行为,而非逐层描述实现。

验收标准

  • 验收标准 1
  • 验收标准 2

Blocked by

  • 对每个阻塞工单的引用,或者“无 — 可立即开始”。

无论采用哪种方式,都应避免具体文件路径或代码片段——它们很快就会过时。例外:如果 prototype 生成的片段比文字更准确地表达了某项决策(状态机、reducer、schema、类型格式),请将其包含在内,并简要注明它来自 prototype。只保留决策信息丰富的部分——这不是可运行的演示,只需包含重要内容。

评论

支持 Markdown