ticket-creator について
ticket-creatorは、Claude Codeでの実装向けに構造化されたLinearチケットを作成するスキルです。既存コードのパターン、重複確認、テンプレート、作成前の品質チェックを重視します。
主な機能
- 01バグと通常作業の分類
- 02Linear内の重複チケット検索
- 03コードパターンと関連スキルの調査
- 04テンプレートに沿ったチケット作成
- 05範囲、分割、品質の確認
活用シーン
- 01機能の議論を実装可能なチケットに整理
- 02技術情報を含むバグの記録
- 03領域別または多数のファイルにまたがる作業の分割
- 04Linearでの作成前にチケットの明確さを確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sylla-bv/ sylla-skills --skill ticket-creatorインストール後、Claude Code で/ticket-creatorを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
examples/backend-ticket.mdbug-ticket.mddata-engine-ticket.mdui-ticket.mdreferences/anti-patterns.mdduplicate-checker.mdguidelines.mdlayout-patterns.mdtemplate-bug.mdtemplate-normal.md詳細
Ticket Creator
AI エージェント(Claude Code)が実装しやすい、構成の整った Linear チケットを作成します。パターンを優先し、テンプレートに沿って作成するワークフローにより、実装エージェントが自由回答形式のアーキテクチャ上の判断を行わずに、計画と実行を進められるようにします。品質基準と作成ガイドラインの詳細については、references/guidelines.md を参照してください。
基本原則:パターン優先
チケットの成功を最もよく予測する要素は、実装エージェントが既存のパターンを参考にして応用できるかどうかです。すべてのチケットで、既存のコードパターンを参照するか、追加の仕様が必要な初回のパターンであることを明示してください。
AskUserQuestion の使用
回答を現在の会話の文脈、コードベース、または以前の回答から推測できない場合に限り、AskUserQuestion を呼び出してください。情報がすでに得られている場合や推測できる場合は、質問せずに進めてください。このルールは、分類、重複確認、情報収集、アンチパターンの解決、分割、確認など、すべての段階に適用されます。
ワークフロー
最初に TaskCreate を使ってワークフローの手順を計画し、各手順の完了時に TaskUpdate で更新してください。これにより進捗が可視化され、/compact の後も維持されます。
1. コンテキストの収集と分類
質問する前に、現在の会話からできるだけ多くの情報を抽出してください。作業についてすでに話し合われている場合は、そのコンテキストを使ってチケットの詳細を事前に埋めてください。
チケットを分類します。
- 通常(機能、改善、リファクタリング)→
references/template-normal.md - バグ(エラー、動作不良)→
references/template-bug.md
コンテキストやキーワードからドメインを特定します。
| ドメイン | キーワード |
|---|---|
| UI | ページ、コンポーネント、レイアウト、フロントエンド、テーブル、フォーム、モーダル、サイドバー |
| Backend | サーバーアクション、API、エンドポイント、データベース、スキーマ、クエリ、マイグレーション、ジョブ |
| Data-Engine | ハーベスター、アクター、パイプライン、スクレーパー、PDF、Python、データエンジン |
分類が曖昧な場合は、AskUserQuestion を使って確認してください。
2. 重複の確認
Task を subagent_type general-purpose とともに使い、Linear で類似する既存チケットを検索してください。チケットの説明、主要な用語、ドメインをコンテキストとして、references/duplicate-checker.md の指示とあわせて渡してください。サブエージェントがすべての list_issues 呼び出しを処理し、簡潔な要約を返します。
サブエージェントが一致するチケットを見つけた場合は、ユーザーに提示し、続行するか、既存のチケットを更新するか、関連チケットとしてリンクするかを尋ねてください。
3. テンプレートの読み込みと情報収集
references/ から適切なテンプレートを読み込みます。不足している必須情報は、優先順位に従って、1〜2問ずつ会話形式で収集してください。
- 何を作成・修正し、その理由は何ですか?対象範囲はどこまでですか?
- 参考にすべき既存のパターンはありますか?(最も重要)
- 技術的な詳細 — 型、契約、ファイルパス
- 副作用、統合ポイント、権限
- 受け入れ条件と検証のヒント
バグチケットの場合、Sentry のイシュー ID または URL がある場合は、Task を subagent_type general-purpose とともに使い、Sentry のエラー詳細を取得してください。チケットに必要な次の項目だけを返すよう、サブエージェントに指示します。エラーメッセージ、該当するファイル/行、根本原因(特定可能な場合)、発生頻度/ユーザーへの影響、関連するパンくず情報。項目の全一覧については、references/template-bug.md を参照してください。これにより、詳細すぎる Sentry のペイロード(スタックトレース、生のパンくず情報)がメインのコンテキストを圧迫するのを防げます。
4. パターンの発見
Task を subagent_type Explore とともに使い、コードベースを検索して次の情報を見つけてください。
- 参考にする既存の実装パターン
- 関連する Claude Code スキル(
.claude/ディレクトリを走査し、SKILL.mdファイルを探します)
見つかったパターンは、チケットの「従うべき既存パターン」フィールドに記載してください。見つかったスキルは、Implementation Toolkit セクションに skills: [skill-name-1, skill-name-2] の形式で記載してください。
5. 品質ゲート
references/anti-patterns.mdに記載されているアンチパターンチェックをすべて実行します。警告があれば提示し、次に進む前にユーザーと相談して解決します。
チケットを分割すべきかどうかを評価します(以下の「チケットの分割」を参照)。
6. 下書きと確認
読み込んだテンプレートを使ってチケットを作成します。タイトル、概要、主要な項目、受け入れ条件を含む簡潔なプレビューを提示します。チケット本文の全体は提示しません。
作成する前に、ユーザーに確認するか、変更を依頼するよう求めます。
7. Linear で作成
create_issueを使って、チーム(「Sylla Tech」)、タイトル、説明、優先度を指定し、チケットを作成します。担当者は、ユーザーが指定した場合にのみ設定します。
依存関係がある場合は、blockedByまたはblocksフィールドを使います。重複チェックで見つかった関連チケットは、relatedToを使ってリンクします。
作成後、チケットのリンクをユーザーに共有します。
チケットの分割
分割する場合は、TaskCreateでblockedByを使い、分割したチケット間の依存関係の順序を表します(例:UIより先にバックエンド)。TaskListで進捗を確認し、TaskUpdateで各チケットのステージ3~7を通じた状態を追跡します。
複数カテゴリへの分割
作業が複数のドメイン(例:UI+バックエンド+データエンジン)にまたがる場合は、ドメインごとにチケットを1件ずつ作成し、相互にリンクします。それぞれのチケットでステージ3~7を実行し、共通のコンテキスト(優先度、説明、関連チケット)を引き継ぎます。relatedToを使ってチケット同士を相互にリンクします。
ファイル単位での分割
チケットで8ファイルを超える変更が必要になる場合は、より小さく、対象を絞ったチケットへの分割を提案します。分割した各チケットは、それぞれ単独で実装できる必要があります。
タイトルの規則
| 種類 | 形式 |
|---|---|
| 機能 | Implement [thing] for [purpose] |
| UI ページ | Create [page name] page at [route] |
| UI コンポーネント | Add [component] to [location] |
| API/エンドポイント | Add [method] [endpoint] endpoint |
| リファクタリング | Refactor [what] to [improvement] |
| バグ | Fix [symptom] in [location] |
参照ファイル
| ファイル | 目的 |
|---|---|
references/template-normal.md | 機能、改善、リファクタリング用テンプレート(UI/バックエンド/データエンジンのセクションは条件に応じて使用) |
references/template-bug.md | バグ修正用テンプレート(Sentry MCP 統合を含む) |
references/anti-patterns.md | チケット作成前に実行するアンチパターン検出ルール |
references/guidelines.md | 品質基準、記述ガイドライン、検証ルール |
references/layout-patterns.md | UI レイアウトパターンの選択表とコンポーネントのリファレンス |
references/duplicate-checker.md | Linear の重複検索用サブエージェントプロンプト(ステップ2で使用) |
チケットの例
構成と詳細度の参考として、以下の実際のチケット例を参照してください。
| 例 | ドメイン | 基にしたチケット |
|---|---|---|
examples/backend-ticket.md | バックエンド(サーバーアクション+API) | S-1176 |
examples/bug-ticket.md | バグ修正(根本原因が判明済み) | S-1222 |
examples/data-engine-ticket.md | データエンジンのハーベスター | S-1149 |
examples/ui-ticket.md | UI ページの作成 | S-1163 |
品質テスト
作成前に、次の点を確認します。「実装エージェントは、このチケットに基づいて、未解決のアーキテクチャ上の判断をすることなく、完全な計画を作成できるか?」
答えが「いいえ」の場合は、曖昧な点を特定して質問します。品質チェックリストの全容については、references/guidelines.mdを参照してください。