SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场ticket-creator

ticket-creator

办公与效率

查看项目

更新于 10-16 02:14

技能介绍

用途

Ticket Creator 用于创建结构良好的 Linear 工单，并针对 AI 代理（Claude Code）的实施进行优化。其遵循模式优先、模板驱动的工作流，确保实施代理能够规划并执行任务，而无需自行做出开放式架构决策。详细的质量标准与写作指南参见 references/guidelines.md。

核心原则：模式优先

工单成功与否最强的预测因素是实施代理能否从既有模式中复制并适配。每个工单必须引用一个既有代码模式，或明确标注其为首次出现的模式并需要额外说明。

AskUserQuestion 的使用

仅当答案无法从当前对话上下文、代码库或此前回复中推断时，才调用 AskUserQuestion。若信息已存在或可推断，则直接继续。这适用于所有阶段——分类、去重、信息收集、反模式处理、拆分与确认。

工作流

开始时使用 TaskCreate 规划工作流步骤，并在完成每步后使用 TaskUpdate 标记，以保持进度可见并在 /compact 后依然保留。

1. 收集上下文并分类

在提问前尽可能从当前对话中提取信息。若此前已讨论过相关工作，用该上下文预填工单内容。

对工单分类：

  • 普通（feature、improvement、refactor）→ references/template-normal.md
  • Bug（error、broken behavior）→ references/template-bug.md

从上下文或关键词识别领域：

  • UI：page、component、layout、frontend、table、form、modal、sidebar
  • Backend：server action、API、endpoint、database、schema、query、migration、job
  • Data-Engine：harvester、actor、pipeline、scraper、PDF、Python、data-engine

若分类存在歧义，使用 AskUserQuestion 进行澄清。

2. 检查重复

使用 Task 搭配 subagent_type general-purpose 在 Linear 中搜索已有的相似工单。将工单描述、关键术语和领域作为上下文传入，并附上 references/duplicate-checker.md 中的指令。该子代理负责所有 list_issues 调用并返回简明摘要。

若子代理发现匹配的工单，向用户展示并询问是继续、更新已有工单，还是作为相关工单关联。

3. 加载模板并收集信息

从 references/ 加载合适的模板。以对话方式补齐缺失的必填信息，每次 1-2 个问题，按以下优先级顺序：

  1. 我们在构建/修复什么，为什么？范围是什么？
  2. 是否有可参照的既有模式？（最关键）
  3. 技术细节——类型、契约、文件路径
  4. 副作用、集成点、权限
  5. 验收标准与验证提示

对于 Bug 工单：若有 Sentry issue ID 或 URL，使用 Task 搭配 subagent_type general-purpose 获取 Sentry 错误详情。指示子代理仅返回工单所需字段：错误消息、受影响文件/行、根本原因（若可确定）、频率/用户影响及任何相关 breadcrumbs。完整字段列表见 references/template-bug.md。这样可避免冗长的 Sentry 负载（堆栈跟踪、原始 breadcrumbs）淹没主上下文。

4. 模式发现

使用 Task 搭配 subagent_type Explore 在代码库中搜索：

  • 可作为模式引用的既有实现
  • 相关 Claude Code 技能（扫描 .claude/ 目录中的 SKILL.md 文件）

将发现的模式填入工单的「Existing pattern to follow」字段。将发现的技能按 skills: [skill-name-1, skill-name-2] 格式填入 Implementation Toolkit 部分。

5. 质量门

运行 references/anti-patterns.md 中的全部反模式检查。将任何警告呈现出来，并在继续之前与用户一起解决。

评估该工单是否应拆分（见下方工单拆分）。

6. 起草并确认

使用加载的模板编制工单。呈现简明预览——标题、摘要、关键字段、验收标准——而非完整工单正文。

在创建前请用户确认或提出修改请求。

7. 在 Linear 中创建

使用 create_issue 创建工单，参数为：team（"Sylla Tech"）、title、description、priority。仅在用户指定时才设置 assignee。

若存在依赖，使用 blockedBy 或 blocks 字段。将去重期间发现的相关工单用 relatedTo 关联。

创建后与用户共享工单链接。

工单拆分

拆分时，使用 TaskCreate 搭配 blockedBy 来建模拆分工单之间的依赖顺序（例如先后端后 UI）。使用 TaskList 查看进度，使用 TaskUpdate 跟踪每个工单在阶段 3-7 的进展。

多类别拆分

若工作跨多个领域（例如 UI + Backend + Data-Engine），为每个领域创建单独且相互关联的工单。对每个工单运行阶段 3-7，并沿用共享上下文（优先级、描述、相关工单）。使用 relatedTo 交叉关联工单。

基于文件的拆分

若一个工单将修改超过 8 个文件，建议拆分为更聚焦的小工单。每个拆分后的工单应可独立实施。

标题约定

  • Feature：Implement [thing] for [purpose]
  • UI Page：Create [page name] page at [route]
  • UI Component：Add [component] to [location]
  • API/Endpoint：Add [method] [endpoint] endpoint
  • Refactor：Refactor [what] to [improvement]
  • Bug：Fix [symptom] in [location]

参考文件

  • references/template-normal.md：功能、改进、重构的模板（含条件性 UI/Backend/Data-Engine 部分）
  • references/template-bug.md：Bug 修复模板（含 Sentry MCP 集成）
  • references/anti-patterns.md：创建工单前运行的反模式检测规则
  • references/guidelines.md：质量标准、写作指南与验证规则
  • references/layout-patterns.md：UI 布局模式决策表与组件参考
  • references/duplicate-checker.md：用于 Linear 重复搜索的子代理提示（用于步骤 2）

示例工单

参考以下真实工单示例来校准结构与细节程度：

  • examples/backend-ticket.md：Backend（server action + API），基于 S-1176
  • examples/bug-ticket.md：Bug 修复（根本原因已知），基于 S-1222
  • examples/data-engine-ticket.md：Data-engine harvester，基于 S-1149
  • examples/ui-ticket.md：UI 页面创建，基于 S-1163

质量测试

创建前验证：「实施代理能否在不做任何开放式架构决策的情况下，从该工单制定出完整计划？」

若答案为否，找出模糊之处并追问。完整质量检查清单见 references/guidelines.md。