g-ki/agent-skills

タスク分解

設計から、チーム内のどのエンジニアでも個別に着手、完了、マージできる1ストーリーポイントのチケットのバックログを作成します。

入力

$ARGUMENTS

• パスが指定されている場合は、そのドキュメントを読み込みます。
• それ以外の場合は、この会話またはディスク上にある、直近のRFCまたは生産的思考セッションの *.notes.md ファイルを使用します。これらは通常、ローカルで管理外のファイル（.gitignore で無視されたフォルダ、例えば .rfcs/ 、次いで docs/rfcs/ 、 docs/adr/ 、 rfcs/ など）です。見つからない場合は、どのドキュメントまたは設計を分解するのかを尋ねます。
• ソースに分割を妨げるギャップ（選択された設計がない、ロールアウト方法がないなど）がある場合は、それらをリストアップしてから、回答を発明する前に尋ねます。小規模なギャップは、代わりにスパイクチケットにすることができます。

ここでの「1ストーリーポイント」の意味

チケットが1ポイントであるためには、すべての条件が満たされている必要があります。1つでも満たされない場合は、分割します。

1. 1人で、約1日以内（テストとレビュー修正を含む）。
2. 1つのレビュー可能なPRであり、単一の目的を持つ。レビュアーは他のオープンなPRを読まなくても理解できる。
3. 単独でマージ可能。マージ後もmainブランチはグリーンでリリース可能な状態を保つ。これは通常、新しい振る舞いがフラグの背後にあるか、まだ配線されていないことを意味します。
4. テスト可能。作成者以外の誰かが確認できる1～5の受け入れ基準がある。
5. 隠れた未知の要素がない。実装者が何をすべきかを知る前に調査する必要がある場合、それはストーリーではなくスパイクです。

チームがポイントに関する独自の定義を持っている場合は、それに従い、その旨を出力の先頭に記載します。

分割方法

分割する前にコードを読みます。各チケットが実際に触れるファイル、モジュール、スキーマ、テストが存在することを確認し、チケットにそれらの名前を記載します。実際のパスを引用したチケットは優先的に着手されます。曖昧なチケットはバックログに残ります。

ウォーキングスケルトンから始めます。設計が本番環境で機能することを証明する、最も薄いエンドツーエンドのスライス（多くの場合、フラグの背後）を作成し、その後厚くしていきます。これにより、最後のチケットで統合問題を発見する代わりに、リスクを早期に顕在化できます。

チケットが大きすぎる場合、以下の分割が通常有効です。

• 準備、そして変更。 まず純粋なリファクタリングを切り出します（「変更を容易にし、その後容易な変更を行う」）。リファクタリングの前に、現在の振る舞いを固定するテストを追加します。
• スキーマとAPI変更のための 拡張/移行/縮小：新しいカラムやエンドポイントを追加し、バックフィルまたはデュアルライトを行い、読み取りを切り替え、その後古いパスを削除します。各フェーズが独自のチケットになります。
• フラグの背後でのレイヤー分割：データモデル → サービスロジック → API → UI。フラグがオフになっているため、それぞれマージ可能です。
• 書き込みパスよりも読み取りパスを先に、そして ハッピーパスをエッジケースやエラーハンドリングよりも先に。
• バリアントごと：最初のチケットでパターンを確立した後、プロバイダ、ファイルタイプ、クライアントごとに1チケット。
• 未知の要素に対するスパイク：タイムボックス化され（≤ 1日）、出力は決定事項と後続のチケット（プロダクションコードではない）です。各スパイクには、答えのある 質問: と時間枠を設定します。決定に依存するチケットは、安全な範囲でのみ分割し、スパイクの決定後に詳細化されることを示す注釈を付けます。スパイクは早期に配置します。それらは後続のすべてのチケットのゲートとなります。

機能コード以外の作業も忘れないでください：フィーチャーフラグのセットアップと削除、メトリクス/アラート/ダッシュボード、ランブックやドキュメントの更新、データバックフィル、段階的ロールアウトのステップ、古いパスのクリーンアップ。これらは、プロジェクトが「ほぼ完了」状態で停滞する原因としてよく見られます。

分割のために分割しないでください：一緒にマージされて初めて意味をなすチケットは、1つのチケットにするか、ペアを別の切り口で再分割する必要があります。

出力

1. templates/tasks.md を使用して、ソースRFCの隣に <rfc-name>.tasks.md としてバックログを作成します。RFCと同様、これはローカルの作業ファイルであり、デフォルトでは管理外です。そのフォルダがgitの無視対象になっていない場合は、.git/info/exclude に追加します。チケットに T-01、T-02、… と番号を付け、依存関係が参照できるようにし、すべてのステータスを open に設定し、ブランチ名に使用するプロジェクトスラッグを記入します。テンプレートのフィールド名は正確に保持します（/implement-task と /deliver-project が読み取るため）。
2. チケットをRFCのフェーズに合致するマイルストーンにグループ化します。各マイルストーンは、デモ可能またはリリース可能な何かで終了します。
3. 依存関係の図を含めます。どのチケットが並行して実行可能か、およびクリティカルパスを示します。チケットが約8枚を超える場合は、小さなMermaidグラフが適しています。
4. チャットで、マイルストーンごとのチケット数、すぐに開始できる数、クリティカルパス、スパイク、および本当に1ポイントかどうか確信が持てないチケットの短いサマリーを提供します。ユーザーに、大きすぎる、小さすぎる、順序が間違っていると思われるチケットをフラグ付けし、修正するよう促します。
5. チームのトラッカーに公開します。 チームが何らかのトラッカー（Linear、Jira、GitHub Issuesなど）を使用していることを前提とします。ユーザーが分割に満足したら、接続されたトラッカーツールを介して公開することを提案します。何も接続されていない場合は、役立つコネクタを示し、フォールバックとして、列 ID, Title, Description, Acceptance Criteria, Story Points, Milestone, Depends On, Labels を持つCSVを提供します。公開はユーザーが確認した後にのみ行います（チーム全体から見えるため）。各チケットについて、タイトル、自己完結型の説明（コンテキスト、スコープ、ファイル、スコープ外、受け入れ基準）、見積もり1、マイルストーン、およびトラッカーがサポートする場合は依存関係に対する blocked-by リレーションを持つ課題を作成します。その後、各課題のキーとリンクをローカルファイルのチケットの Tracker: フィールドに書き込みます。
6. 次のステップを示します。単一チケットの場合は /implement-task <ticket-id>、スパイクの場合は /spike-task <ticket-id>、エージェントチームでバックログ全体を実行する場合は /deliver-project <tasks-file> です。

ソースRFCに実行計画セクションがある場合は、リストを複製する代わりにタスクファイルをリンクするように更新します。

スパイク後の詳細化

決定済みのスパイクの決定レコード（ステータス decided）が与えられた場合、最初からやり直すのではなく、バックログを更新します。

1. レコードで承認されたバックログ変更を適用します。チケットを追加し（T-NN の番号を継続し、IDを再利用しない）、影響を受けるチケットのスコープ、基準、または依存関係を変更し、削除されたチケットは理由を付けて canceled に設定します（削除はしません）。
2. 変更されたチケットまたは新しいチケットすべてを1ポイントテストに照らして再確認し、サマリー、依存関係グラフ、およびクリティカルパスを更新します。
3. レコードにリストされているRFCのセクションを更新します。
4. トラッカーと同期します。新しい課題を作成し、変更された課題を更新し、削除された課題をキャンセルし、新しいキーをタスクファイルに書き込みます。ユーザーが決定とそのバックログ変更を一緒に承認した場合、その承認がこの同期をカバーします。それ以外の場合は、最初に確認します。
5. スパイクを done に設定し、変更内容を数行で要約します。