タスク実装スキル

タスクの実装

1ポイントのチケット1つを、チケットで要求された内容のみを含むレビュー用PRとして納品します。

入力

$ARGUMENTS

• チケット、必須: トラッカーキー（例：ENG-123）またはローカルID（例：T-04）。 指定がない場合は、準備のできたチケット（ステータスが open、依存関係がマージ済み）をクリティカルパス順にリストアップし、どれを取得するか尋ねます。 無人モードでは、代わりに blocked を報告します。
• --tasks <file>: ローカルタスクファイル。 指定がない場合は、プロジェクトのローカルでgit管理外のRFCフォルダ（例：.rfcs/）、次に docs/rfcs/ から、該当チケットを含む *.tasks.md ファイルを探します。
• --base <branch>: 開始元ブランチおよびPRのターゲットブランチ。 デフォルトは main。 main以外のベースブランチは、PRが別のチケットの未マージPRにスタックしていることを意味します。
• --branch <name>: 使用するブランチ名。 指定がない場合は、ステップ1の命名規則に従います。
• --feedback <pr>: 実装は行わず、既存のPRに対するレビューフィードバックに対応します（最後のセクションを参照）。
• --unattended: オーケストレーターによって開始され、誰も質問に答えられないことを示します。 質問をしないでください。 質問が必要な場面では、処理を中止し、レポートで説明してください。 作業は自身のワークツリーで行ってください。

チケットとローカルファイルの場所

• トラッカー優先。 チケットにトラッカーキーがある場合（引数として、またはタスクファイルの Tracker: フィールドに）、接続されたトラッカーツール（Linear、Jira、GitHub Issuesなど）を介して取得します。 公開されている場合、トラッカーはチケットのコンテンツの信頼できる情報源です。 そこでキャンセルまたは完了している場合は、処理を中止して報告します。
• それ以外はローカルタスクファイル、およびトラッカー課題に欠けているフィールド（ファイル、範囲外）について。 RFCとタスクファイルは開発者のローカルで追跡されていないドキュメントであるため、メインプロジェクトフォルダにのみ存在し、ワークツリーには存在しません。 ワークツリーにいる場合は、git worktree list（最初のエントリ）でメインフォルダを見つけ、絶対パスでファイルを読み取ります。 メインフォルダは読み取り専用として扱います。編集、チェックアウト、gitコマンドの実行は絶対に行わないでください。
• RFC、メモ、タスクファイルをコミットしないでください。 ステージングは git add -A ではなく、明示的なパスで行ってください。

1. チケットを選択する

• チケット（上記参照）、その受け入れ基準と依存関係を読み取ります。 タイプが spike の場合は中止します。スパイクはPRではなく決定を生成します。 /spike-task をポイントします（無人モード：blocked を報告）。
• 依存関係は、そのPRがmainにマージされている（gh でPRの状態を確認、または依存関係のステータスが pr-merged/done）か、ベースブランチがその依存関係自身のブランチ（スタッキング）である場合に充足されます。 スパイクの依存関係は、それが done になった場合、つまりその決定が承認されバックログが洗練された場合にのみ充足されます。 充足されていない依存関係がある場合は、処理を中止し、それを示します。
• ワーキングツリーがクリーンであることを確認し、fetchして、最新の origin/<base> からブランチを作成します。
• ブランチ名（--branch が指定されていない場合）：<username>/<project-slug>/<task-branch>。
  • username: ユーザーの既存のブランチがこのパターンに従っている場合はそのプレフィックス、そうでない場合はGitHubログイン（gh api user --jq .login）。
  • project-slug: タスクファイルの Project slug: ヘッダーから、またはRFC名をケバブケースにしたもの。
  • task-branch: トラッカーキーと短いスラッグ（例：eng-123-add-v2-flag）（キーによりトラッカー統合がPRをリンクできます）、または未公開の場合は t-04-add-v2-flag。
• ユーザーと直接作業している場合（無人モードでない場合）、タスクファイルでチケットのステータスを in progress に設定し、トラッカーでも（GitHub統合が自動で行わない場合）設定します。

2. チケットが必要とするものだけを読み込む

チケット、それが依存するRFCセクション、およびそれが指定するファイルを読み取ります。 次に、実際のフロー（呼び出し元、既存のヘルパー、変更するコードの横にあるテスト）をトレースします。 問題を完全に理解するのに十分な量を読みますが、RFC全体やセッション履歴は読み込まないでください。チケットは単独で成り立つように書かれています。 そうでない場合は、推測するのではなく、報告すべきギャップです。

3. 最初にテストを書く

各受け入れ基準をテストに変換し、リポジトリの既存のテストフレームワーク、場所、およびスタイルを使用します。 テストを実行し、正しい理由で失敗することを確認します。 基準ごとに1つの集中したテストで十分です。既存のパターンで必要とされない限り、新しいテストユーティリティ、フィクスチャ、またはヘルパーは追加しないでください。 純粋に機械的なチケット（例：フラグの追加）では、基準が既存のテストや型チェッカーによってチェックされる場合、新しいテストは不要な場合があります。その場合はPRでその旨を記述します。

4. 最小の完全な変更を実装する

「完全」とは、すべての受け入れ基準がパスすることを意味します。 「最小」とは、それ以上のものは何もないことを意味します。 これはポニーテールアプローチに従います。 ponytail スキルがインストールされている場合は、デフォルトレベルでそれを今ロードし、このステップを管理させます。

それ以外の場合は、最初に機能するオプションを選択します。

1. ニーズがすでに満たされているか？ 既存のコードがすでに基準を満たしている場合は、処理を中止し、チケットをクローズすることを提案します。
2. コードベースにすでにあるもの（ヘルパー、型、パターン）を再利用します。
3. 標準ライブラリ、次にネイティブプラットフォーム機能（DB制約、組み込みHTML入力、CSSの優先、JSの後）、次にすでにインストールされている依存関係を使用します。
4. その場合にのみ、最小限の新しいコードを記述します。

記述中：

• 推測による構造は禁止。 実装が1つしかないインターフェース、1つの製品のためのファクトリ、決して変更されない値のための設定、「後で使うため」の足場は禁止。 新しいファイルを作成するよりも、既存のファイルを編集することを優先します。
• 周囲のコードに合わせる： 命名、エラー処理、構造。 差分はコードベース自身が書いたように見えるべきです。
• コメントはコードが語れない場合のみ。 コードが何をするかを説明したり、チケットを言い換えたり、コメントアウトされたコードやデバッグ出力を残したりしないでください。 追加する価値のある唯一のコメントは、意図的な単純化についてです。制限と、いつアップグレードするかを示し、誰も誤って「修正」しないようにします。
• バグは根本で修正する。 共有関数を変更する前に、すべての呼び出し元を確認します。
• 安全性を決して軽視しない。 信頼境界での入力検証、データ損失を防ぐエラー処理、セキュリティ、およびアクセシビリティの基本は、チケットに明示されていなくても常に適切に行います。

5. 範囲を守る

チケットが1ポイントより大きいことが判明した場合（約1日以上、2つ目の関心事が現れる、または無関係な領域に触れずに基準を満たせない場合）、処理を中止します。 クリーンなもの以外はコミットせず、見つけたことを説明し、承認のために新しいチケットとして分割を提案します。ユーザーと作業している場合はタスクファイルに書き込み、無人モードの場合はレポートに書き込みます。 気づいた無関係な問題はPRのメモに記載し、差分には含めません。 受け入れ基準を弱めたり、再解釈してパスさせようとしたりしないでください。

6. 検証してPRを開く

1. リポジトリの方法でテスト、リンター、型チェッカーを実行します。 変更にランタイム動作があり、/verify を実行できる場合は実行します。それ以外の場合は、プロジェクト独自の実行コマンドまたはチェックコマンドで動作を確認します。
2. 差分全体を自分自身で再度読みます。変更された各行は受け入れ基準にトレース可能であるべきです。 無関係なフォーマット、リネーム、および迷い込んだファイルを削除し、ローカルのRFCやタスクファイルが含まれていないことを確認します。
3. リポジトリのコミットスタイルに従ってコミットし、プッシュし、ベースブランチに対してレビュー準備完了（ドラフトではないため、レビュー自動化が実行されます。ユーザーがドラフトを要求した場合を除く）としてPRを開き、templates/pr.md を使用します。 タイトルにトラッカーキーを入れ、説明にトラッカー課題をリンクします。 ベースがmainでない場合は、どのPRにスタックしているか、およびそのPRが先にマージされることを記述します。 ここからPRを開けない場合は、ブランチをプッシュし、応答にPRテキストを含めます。
4. ユーザーと直接作業している場合、チケットのステータスを pr-open（または pr-draft）に設定し、タスクファイルの Branch / PR: を埋め、GitHub統合が自動で行わない場合はトラッカー課題をレビュー状態に移動します。 無人モードでは、ステータスはオーケストレーターに任せます。
5. 以下のレポートで終了します。 ユーザーがいる場合は、2～3行のバージョンで十分です。

PRフィードバックへの対応（--feedback）

PRと、対応するレビューアイテムのリスト（コメントリンクとその対処方法）を取得します。

1. ワークツリーでPRのブランチをfetchしてチェックアウトします。 チケットとアイテムを読み、現在の差分を読みます。
2. 各アイテムを、それを解決する最小の変更で対応します。ルールはステップ4と同じです。 チケットの範囲内に留めてください。アイテムが範囲を超えたものを要求している場合は、実装せず、フォローアップとして報告します。
3. 修正やforce-pushではなく、新しいコミットを追加して、レビュアーがレビュー以降に何が変更されたかを確認できるようにします。 テストを実行し、プッシュします。
4. 対応した各コメントスレッドに、何が変更されたかと短いコミットSHAを1行で返信します。 コード変更なしで回答するように指示されたアイテムについては、指定されたテキストで返信します。 アイテムを変更すべきでないと結論付けた場合は、スレッドで議論せず、そのままにしてレポートで説明します。
5. すべてのアイテムが処理された場合は done、そうでない場合は blocked を使用してレポートで終了します。

レポート

オーケストレーターが解析できるように、最終メッセージを次のブロックで正確に終了します。

RESULT: done | blocked | needs-split | already-met
TICKET: <local id> / <tracker key or "unpublished">
PR: <url or "none">
BRANCH: <branch or "none">
SKIPPED: <deliberate limits or items not addressed, or "none">
NOTES: <one or two lines: why blocked, what to split, follow-ups, unrelated issues found>