ticket-craft

ticket-craft 概览

ticket-craft 是一款 ticket 编写技能，用于把零散的产品意图转成 AI 可执行的工作项。它特别适合需要在 Jira、Asana、Linear 或 GitHub issues 里创建任务的人：让 ticket 本身就承载足够上下文，方便 Claude Code 或其他 agent 更少追问、直接开工并完成。

它的核心任务不是“把 issue 写得更好看”，而是让 ticket 自成一体：目标清晰、范围明确、约束具体、验收标准清楚，并提供足够的实现背景，让 agent 不用靠猜就能行动。也正因为如此，ticket-craft 尤其适合 epics、功能拆解和偏 spec 风格的 ticket，因为这类任务最容易因为歧义而拖慢执行。

ticket-craft 和普通 prompt 的区别，在于它专注于 agent readiness。它把 INVEST、Given-When-Then、Definition of Ready 这类常见的软件写作模式，和面向 AI 执行的明确指令结合起来。若你的主要风险不是文案写得差，而是指令不完整，那么它会很合适。

适合 AI 可执行 ticket 的场景

当 ticket 不是只给人看，而是要交给 agent 执行时，使用 ticket-craft 最合适。它最强的场景是：你已经知道想要什么结果，但需要帮助把它翻成一个有边界、有上下文、且可验证完成的结构化任务。

不适合的场景

ticket-craft 并不适合拿来做产品方向头脑风暴、写轻量任务备注，或者处理那种只需要一句话加一个链接的超小 ticket。如果工作本身还没定下来，却硬要写成一份完整、面向 agent 的 ticket，往往会制造一种虚假的确定性。

为什么这个技能有价值

ticket-craft 的实际价值在于减少来回沟通。更好的 ticket 结构意味着更少的澄清循环、更少的范围意外，也更少在评论里反复解释上下文。对于用 Claude Code 做实现的团队来说，这可能就是“ticket 一发就能开工”和“ticket 卡住不动”之间的区别。

如何使用 ticket-craft 技能

安装并启用 ticket-craft

先按仓库提供的 skill 安装流程完成安装，然后在 Claude Code 或支持 skill 的工作流里启用 ticket-craft。源文档中展示的基础安装方式是：

npx skills add alinaqi/claude-bootstrap --skill ticket-craft

如果你的环境使用的是别的 skill 管理器或路径，保留同一个 skill 名称即可，安装方式按你的实际环境调整。ticket-craft install 这一步真正重要的不是命令本身，而是确保你在写 ticket 的地方就能用到这个 skill。

输入真实工作项，不要给模糊需求

ticket-craft usage 最强的输入，通常不是一个空泛请求，而是一个有点乱但足够具体的目标。好的输入一般会包含：

• 功能、bug 或 epic 的名称
• 目标系统或 repo 区域
• 用户影响或业务原因
• 已知约束、依赖项或非目标
• 需要保持不变的现有行为
• 任何验收测试、截图或链接

像“写一个改进 onboarding 的 ticket”这样的弱 prompt，留下的空间太大。更好的写法是：“Create an AI-executable Linear ticket for reducing signup drop-off on mobile. We want to add email autofill support, keep the current step order, exclude social login changes, and define acceptance criteria for iOS and Android.”

先看这些文件

先从 SKILL.md 看起，因为它定义了 ticket 结构，以及这个框架背后的逻辑。然后检查技能引用的任何仓库文件，尤其是描述 Core Principle、INVEST+C criteria、ticket 类型和 feature-ticket 示例的内容。就这个仓库而言，SKILL.md 是主要来源；没有配套的 rules/、resources/ 或 scripts/ 文件夹，所以主要工作流都来自技能文档本身。

使用有利于技能发挥的 prompt 形式

想要更好的结果，就要用 agent 能直接执行的格式来要 ticket。一个强 prompt 可以这样写：

“Using ticket-craft, draft a Jira ticket for adding webhook retries. Include problem statement, scope, non-goals, implementation notes, acceptance criteria, and edge cases. Assume the agent will work in a Node.js monorepo and should not change API contracts.”

这类输入能提升输出质量，因为它明确告诉技能最重要的东西：范围控制、运行环境，以及完成信号。

ticket-craft 技能常见问题

ticket-craft 只适用于 Claude Code 吗？

不是。这个 skill 针对 Claude Code 做了优化，但它生成的 ticket 格式同样适用于任何受益于明确上下文和验收标准的 AI agent 或 ticket 系统。ticket-craft skill 在下游执行者是自动化或半自动化时最有价值。

它和普通 prompt 有什么不同？

普通 prompt 也能生成一份还不错的 issue 摘要。ticket-craft 的目标则是产出一份能扛住执行过程的 ticket：它会强调定义、约束和可衡量的完成标准。当模糊 prompt 可能导致实现偏航时，这一点尤其重要。

我需要是技术写作者才能用吗？

不用。只要产品经理、工程师或运维负责人能描述清楚想要的变化，就可以使用这个 skill。关键要求是：有足够的源上下文，能说清楚应该发生什么、什么不该变，以及“完成”到底意味着什么。

什么时候应该跳过它？

当工作还在探索阶段、范围本来就会变化，或者需求小到不值得写一份结构化 ticket 时，可以跳过 ticket-craft。对于很小的后续任务，这种额外开销可能超过收益。

如何改进 ticket-craft 技能

提供更清晰的源上下文

质量提升最大的来源，是更好的输入。把 repo 区域、当前行为、约束条件，以及 issue 链接或用户反馈这类证据一起提供出来。如果 ticket 依赖某个已有模式，就把它点名；如果必须避开某个高风险区域，也要明确写出来。

要边界，不只是要任务

一个常见失败模式是范围膨胀。想让 ticket-craft 的结果更好，就要明确非目标、禁止变更项，以及 agent 不该自行假设的内容。比如：“Do not alter database schema,” 或 “Keep the current UI copy unchanged unless required for the fix.”

尽早加入完成信号

如果你希望执行可靠，就要在 ticket 写出来之前先定义成功长什么样。好的完成信号包括测试用例、验收标准、上线说明和边界情况。对于 ticket-craft for Issue Tracking 尤其如此，因为这个 issue 可能会直接分配给 AI agent。

第一版之后继续迭代

如果第一版 ticket 还是太宽泛，就在 prompt 里再补一层细节：精确的用户流程、受影响的文件，或者期望的输出格式。最好的 ticket-craft guide 工作流是迭代式的——先起草，再收紧范围，然后重写 ticket，这样 agent 才能不用澄清就直接开始。