ticket-craft

ticket-craft skillの概要

ticket-craft は、ざっくりしたプロダクト意図を AI が実行できる作業チケットに落とし込むための ticket-writing skill です。Jira、Asana、Linear、GitHub issues を作成していて、チケット自体に十分な文脈を持たせ、Claude Code や他のエージェントが追加確認をあまり挟まずに着手・完了できる状態にしたい人に向いています。

主な役割は「より読みやすい issue を書くこと」ではありません。目的は、チケットを自己完結させることです。つまり、明確なゴール、スコープ、制約、受け入れ条件、そしてエージェントが推測せずに動けるだけの実装文脈を入れることです。だからこそ ticket-craft は、曖昧さが実行の遅れにつながりやすい epics、機能分解、仕様書に近いチケットで特に効果を発揮します。

ticket-craft が一般的なプロンプトと違うのは、agent-readiness に重点を置いている点です。INVEST、Given-When-Then、Definition of Ready といったおなじみのソフトウェア記述パターンに、AI 実行向けの明示的な指示を組み合わせています。そのため、問題が文章力ではなく「指示の不足」にある場合に特に相性が良い skill です。

AI実行向けチケットに最適なケース

ticket-craft は、人間が読むだけのメモではなく、エージェントに渡すチケットを作るときに使います。欲しい結果はすでに分かっているが、それを境界、文脈、検証可能な完了条件を持つ構造化タスクに変換したい、という場面で最も力を発揮します。

向いていないケース

ticket-craft は、プロダクト方向性のブレスト、軽いタスクメモの作成、ひと言とリンクだけで足りる小さなチケットの管理には最適ではありません。まだ作業内容が固まっていない段階で、無理に完全仕様の agent-ready ticket を作ると、かえって「確定したつもり」の誤認を生みます。

この skill が重要な理由

ticket-craft の実用価値は、やり取りの往復を減らせることにあります。チケットの形が整っていれば、確認のループが減り、スコープの想定外も減り、コメント欄で文脈を何度も説明し直す時間も減ります。実装に Claude Code を使うチームでは、その差が「すぐ着手できるチケット」になるか、「止まるチケット」になるかを分けます。

ticket-craft skill の使い方

ticket-craft をインストールして有効化する

リポジトリの skill インストール手順に従ってから、Claude Code もしくは skill 対応のワークフローで ticket-craft を有効化します。ソースで示されている基本のインストール例は次のとおりです。

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

環境で別の skill manager や別のパスを使っている場合でも、skill 名はそのまま維持し、インストール方法だけ自分の構成に合わせてください。ticket-craft install で本当に重要なのはコマンドそのものではなく、チケットを作る場所でこの skill が使える状態になっていることです。

曖昧な依頼ではなく、実際の作業項目を渡す

ticket-craft usage で最も成果が出るのは、雑でも具体性のあるゴールから始めるときです。よい入力には通常、次のような情報が含まれます。

• 機能、バグ、epic の名前
• 対象システムまたは repo の範囲
• ユーザーへの影響やビジネス上の理由
• 分かっている制約、依存関係、非ゴール
• 変えてはいけない既存動作
• 受け入れテスト、スクリーンショット、リンク

「オンボーディングを改善する ticket を書いて」のような弱いプロンプトでは、未確定要素が多すぎます。より良い例は次のようなものです。「モバイルでの signup 離脱率を下げるための AI-executable な Linear ticket を作成してください。email autofill support を追加し、現在の step order は維持し、social login の変更は除外し、iOS と Android の acceptance criteria を定義してください。」

先に読むべきファイル

まず SKILL.md を確認してください。チケット構造と、そのフレームワークの考え方が定義されています。次に、skill が参照している repository ファイルを確認します。特に、Core Principle、INVEST+C criteria、ticket types、feature-ticket examples を説明している内容は重要です。この repository では SKILL.md が主な情報源であり、rules/、resources/、scripts/ フォルダはありません。そのため、主なワークフローは skill ドキュメントそのものから読み取る形になります。

skill を活かすプロンプトの形にする

最良の結果を出すには、エージェントがそのまま実行できる形式で ticket を依頼します。例えば、次のようなプロンプトが有効です。

“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 skill の FAQ

ticket-craft は Claude Code 専用ですか？

いいえ。skill は Claude Code での実行に最適化されていますが、明示的な文脈と acceptance criteria を活かせる AI agent や ticket system ならどれでも使えます。ticket-craft skill が特に価値を持つのは、下流の作業者が自動化または半自動化されている場合です。

通常のプロンプトと何が違いますか？

通常のプロンプトでも、それなりの issue summary は作れます。ticket-craft は、実行に耐える ticket を作るための skill です。定義、制約、測定可能な完了条件をしっかり求めるので、曖昧なプロンプトが原因で implementation drift が起きるのを防ぎやすくなります。

技術ライターでないと使えませんか？

いいえ。欲しい変更内容を説明できるなら、プロダクトマネージャー、エンジニア、運用責任者にとって有用です。必要なのは、何を起こしたいのか、何を変えてはいけないのか、そして “done” の意味を伝えられるだけの元文脈です。

どんなときに使わないべきですか？

探索的な作業でスコープが意図的に流動的なとき、または structured ticket を作るほどでもない小さな依頼のときは ticket-craft を飛ばして構いません。小さなフォローアップ task では、オーバーヘッドのほうが利点を上回ることがあります。

ticket-craft skill を改善するには

元になる文脈をもっと具体的にする

品質を大きく左右するのは、入力の質です。repo の対象範囲、現在の動作、制約、issue link やユーザーレポートなどの根拠を入れてください。既存のパターンに沿う必要があるなら、その名前を明記します。リスクの高い領域を避ける必要があるなら、それもはっきり書きます。

タスクだけでなく、境界条件を指定する

よくある失敗は、スコープが広がりすぎることです。non-goals、禁止する変更、エージェントが勝手に置いてはいけない前提を明示すると ticket-craft の結果は改善します。たとえば、「database schema は変更しない」「修正に必須でない限り、現在の UI copy は変更しない」といった指定です。

完了の合図を早めに入れる

安定した実行を求めるなら、ticket が書かれる前に success の定義を示してください。よい signal には、test case、acceptance criteria、rollout notes、edge cases があります。これは、issue が AI agent に直接割り当てられる ticket-craft for Issue Tracking では特に重要です。

最初の下書きのあとに詰める

最初の ticket が広すぎるなら、もう一段だけ詳細を足してプロンプトを直します。たとえば、正確な user flow、影響を受ける files、期待する出力形式です。最適な ticket-craft guide の使い方は反復です。まず下書きし、スコープを絞り、そしてエージェントが確認待ちなしで始められるように ticket を書き直します。