ticket-craft

ticket-craft 技能概覽

ticket-craft 是一個用來把粗略產品意圖轉成 AI 可執行工作項目的 ticket 寫作技能。它最適合那些會建立 Jira、Asana、Linear 或 GitHub issue，並且希望 ticket 本身就帶有足夠脈絡，讓 Claude Code 或其他 agent 能少問幾個來回就直接開始、甚至完成任務的人。

它真正要解決的，不是「把 issue 寫得更漂亮」。重點是讓 ticket 具備自給自足性：目標清楚、範圍明確、限制條件、驗收標準，以及足夠的實作脈絡，讓 agent 不必靠猜測就能動手。這也讓 ticket-craft 對 epic、功能拆解、以及類規格書型的 ticket 特別有用，因為這類工作最常被不確定性拖慢。

ticket-craft 和一般 prompt 的差異，在於它強調 agent-ready。它把 INVEST、Given-When-Then、Definition of Ready 這些熟悉的軟體撰寫模式，和明確的 AI 執行指令結合起來。當你的主要風險不是文筆不好，而是指示不完整時，它會特別合適。

適合 AI 可執行 ticket 的情境

當 ticket 不是只給人看，而是要交給 agent 執行時，就該用 ticket-craft。它最強的使用場景，是你已經知道想要的結果，但需要把這個結果整理成一個有邊界、有脈絡、而且可測試完成條件的結構化任務。

不適合用在什麼情況

ticket-craft 不是拿來腦力激盪產品方向、寫輕量任務備註，或管理那種只需要一句話加一個連結的超小 ticket。若工作本身還沒定案，硬要做成一份完整、agent-ready 的 ticket，反而會製造假的確定感。

為什麼這個技能有價值

ticket-craft 的實際價值，在於減少來回溝通。更好的 ticket 形狀，代表更少的釐清迴圈、更少的範圍驚喜，也更少在留言裡重複解釋背景。對使用 Claude Code 來做實作的團隊來說，這可能就是 ticket 能立刻開工，或是卡住不動的差別。

如何使用 ticket-craft 技能

安裝並啟用 ticket-craft

先走該 repo 的技能安裝流程，再在你的 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，會留下太多空白。更好的說法是：「請建立一個 AI 可執行的 Linear ticket，用來降低 mobile 端 signup 流失。要新增 email autofill 支援、維持目前步驟順序、不包含 social login 變更，並為 iOS 與 Android 定義驗收標準。」

先讀這些檔案

先從 SKILL.md 開始，因為它定義了 ticket 結構，以及這個框架背後的邏輯。接著檢視 skill 參考到的任何 repo 檔案，特別是說明 Core Principle、INVEST+C criteria、ticket 類型，以及 feature-ticket 範例的內容。在這個 repository 中，SKILL.md 是主要來源；沒有 rules/、resources/ 或 scripts/ 資料夾，所以主要工作流程就是直接從 skill 文件本身來。

用能幫助 skill 發揮效果的 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.”

這類輸入能提升輸出品質，因為它清楚告訴 skill 什麼最重要：範圍控制、執行環境，以及完成訊號。

ticket-craft 技能 FAQ

ticket-craft 只適用於 Claude Code 嗎？

不是。這個 skill 雖然是為 Claude Code 執行做最佳化，但只要下游工作者是自動化或半自動化，且票務系統能受益於明確脈絡與驗收標準，這種 ticket 格式都能派上用場。ticket-craft skill 在這些情境下特別有價值。

這和一般 prompt 有什麼不同？

一般 prompt 可以產生一份還不錯的 issue 摘要；ticket-craft 則是設計來產生能撐過實作過程的 ticket。它會主動推你補上定義、限制，以及可衡量的完成條件。當模糊的 prompt 可能讓實作方向漂掉時，這點就很重要。

我需要是技術寫作者才能用嗎？

不用。只要產品經理、工程師或營運主管能描述想要的變更，就能使用這個 skill。主要門檻是你要有足夠的原始脈絡，能說清楚應該發生什麼、不應該改什麼，以及「完成」代表什麼。

什麼情況下應該跳過它？

當工作偏探索性、範圍本來就會浮動，或請求太小，不值得寫成結構化 ticket 時，就可以跳過 ticket-craft。對於很小的後續任務來說，額外流程帶來的成本可能大於好處。

如何改進 ticket-craft 技能

提供更精準的原始脈絡

品質提升最大的來源，其實是更好的輸入。請加入 repo 區域、目前行為、限制條件，以及 issue 連結或使用者回報等佐證。如果 ticket 依賴既有模式，直接點名那個模式；如果必須避開高風險區域，也要明確寫出來。

要求邊界，不要只描述任務

常見失敗模式是範圍膨脹。要改善 ticket-craft 的結果，就要明確寫出非目標、禁止變更，以及 agent 不應自行假設的前提。例如：「不要修改 database schema」，或「除非修正必須，不要改動目前的 UI 文案」。

及早加入完成訊號

如果你想要穩定執行，就要在 ticket 寫出來之前先定義成功長什麼樣子。好的完成訊號包括測試案例、驗收標準、上線備註與邊界情境。這一點對 ticket-craft for Issue Tracking 特別重要，因為 issue 可能會直接指派給 AI agent。

第一版之後再迭代

如果第一版 ticket 太寬，請在 prompt 裡再補一層細節：精確的使用者流程、受影響檔案，或預期輸出格式。最好的 ticket-craft guide 工作流是迭代式的——先起草、再收斂範圍，最後重寫 ticket，讓 agent 不需要釐清就能直接開始。