implement-issue

イシューの実装

team-executor による、GitHub イシューのエンドツーエンドの対応です。迅速な対応よりも堅牢な解決を優先します。実行エージェントには、人間の時間・速度・見積もりに関する制約は適用されません。重視するのはリスクと一貫性です。

同梱リソース

ファイル	目的
references/workflow.md	詳細なステップごとのワークフローとエッジケース
references/team-composition.md	プロジェクトの技術スタックに応じた、計画エージェントとスキルの割り当て方法

入力

• GitHub イシュー番号（整数のみの場合は → 現在のリポジトリ）、owner/repo#N 形式の識別子、または完全な https://github.com/.../issues/N URL。
• ユーザーメッセージの任意のフラグ：「decide」／「make all decisions」／「no confirmation」 → TL;DR の確認ステップを省略し、最も堅牢で規約に沿った方法を自律的に選択します。

出力

• issue-<N>-<slug> という名前の機能ブランチ（または、検出されたリポジトリのブランチ命名規約に準拠する名前）。
• docs/plans/issue-<N>/ 以下の計画ドキュメント（team-executor によるもの）。
• 新しいチームがそのまま進められるだけの詳細を記載した、合意済みの実装方針に関するイシューへのコメント。
• 機能ブランチ上の実装コミット。
• イシューに紐付いたプルリクエスト（Closes #N）。

ワークフロー

0. 前提条件：team-executor がインストールされていること

他の手順に進む前に、team-executor を利用できることを確認します。次の順に確認してください。

1. ~/.claude/skills/team-executor/SKILL.md
2. .claude/skills/team-executor/SKILL.md（プロジェクト）
3. ./team-executor/SKILL.md（このリポジトリ内で実行する場合）
4. /mnt/skills/team-executor/SKILL.md
5. skills-lock.json 内の team-executor エントリ

見つからない場合は、停止してユーザーに警告してください。確認したパスと、このスキルが計画および実行のために team-executor を使用することを報告します。次のどちらを選ぶか、ユーザーに確認してください。

• (a) インストールして続行する（npx skills add thatjuan/agent-skills --skill team-executor）
• (b) 中止する

明示的な確認を待ちます。確認なしで先に進んではいけません。解決したパスは後続の手順で使えるよう保存してください。

1. イシューを特定する

• ユーザーの入力を解析します。整数のみの場合は、現在のリポジトリのイシュー番号として扱います。
• gh issue view <N> --json number,title,state,body,labels,assignees,milestone,url,author,comments を実行し、コメントも含めてすべて読みます。過去の議論ですでに対応方針が制約されている場合があります。
• state != "OPEN" の場合：
  • 現在の状態（closed／merged／locked）をユーザーに報告します。
  • (a) 再オープンする、(b) 新しいブランチでそのまま進める、(c) 中止する、のどれにするか尋ねます。回答を待ってください。
• リポジトリの規約を確認します：CLAUDE.md、AGENTS.md、CONTRIBUTING.md、最近のブランチからブランチ命名のヒント（git branch -a --sort=-committerdate | head -20）、および git log --oneline -20 によるコミットメッセージのスタイル。

2. 機能ブランチを作成する

• リポジトリのデフォルトブランチからブランチを作成します（gh repo view --json defaultBranchRef -q .defaultBranchRef.name で特定します）。
• リポジトリの規約で別の名前が指定されていない限り、ブランチ名は issue-<N>-<kebab-title> とし、60 文字で切り詰めます。
• 先に git fetch origin を実行し、origin/<default> からブランチを作成します。

3. 実装方針を決定する

Issue には 何を するかが記載されています。このスキル（team-executor と併用）では、Issue の本文で実装方法が明示されている場合を除き、どのように 実装するかを決定します。

Issue に具体的な実装手順が記載されている場合（対象ファイル、API、コードパターン、またはコーダーがそのまま実行できるチェックリストなど）：

• 計画チームをスキップします。Issue の本文を計画として使用し、ステップ 5 に進みます。

それ以外の場合：team-executor を介して計画チームを起動します。

• team-executor スキルを読みます：~/.claude/skills/team-executor/SKILL.md（プロジェクト内にインストールされている場合は ./team-executor/SKILL.md）。
• Issue の本文とコメントを「入力の整理」に渡し、team-executor のフェーズ 1（計画）のステップ 1～8 に従います。
• このプロジェクトのスタックに適したエージェントとスキルの割り当て方法については、references/team-composition.md を参照してください。

team-executor を介してこの Issue のために起動するアーキテクト、コーディング、レビューの各エージェントには、ベースとなるエンジニアリングレイヤーである software-engineer スキルを割り当てます。これにより、どのスタック／SDK スキルが上書き適用される場合でも、実装にはアーキテクト／開発者／レビュー担当者としての基準（Three Lenses）と Eight Standards が適用されます。スキルとエージェントの正確な対応関係については、references/team-composition.md を参照してください。

すべての計画エージェントのプロンプトに、次の制約を含めてください。

実装は他のコーディングエージェントが担当します。人間の作業時間、速度、労力の見積もりは適用されません。そのため、人間には時間がかかるという理由で、より堅牢な解決策を避けないでください。リスク、セキュリティ、保守性、既存のプロジェクト規約との一貫性を考慮してください。このリポジトリにある既存のツール、スタイル、コンポーネントを活用する、最も堅牢で適切に設計された選択肢を優先してください。既存のパターンで対応できる場合は、並行するパターンを導入しないでください。

4. 方針を確定する（または自律的に決定する）

• ユーザーの指示に判断を任せる旨（「決定して」「すべて判断して」「確認不要」「自律的に」など）が含まれている場合は、確認をスキップします。計画の出力から最も堅牢で規約に沿った選択肢を選び、先に進みます。
• それ以外の場合は、ごく簡潔な TL;DR をユーザーに提示します。選択したアプローチ、主なトレードオフ、影響を受ける領域、リスクを 3～6 個の箇条書きでまとめます。確認または方針変更を待ちます。
• 確認後（または自律的な決定後）、team-executor のステップ 8 に従い、最終計画を docs/plans/issue-<N>/execution-plan.md に記載します。

5. 実装方針を Issue にコメントする

gh issue comment <N> --body-file <path> を使って、以下を含むコメントを投稿します。

• アプローチ — 選択した方針を 1～2 段落で説明します。
• この方針を選ぶ理由 — 検討した代替案とのトレードオフを説明します。
• スコープ — 変更するファイル／モジュール、新規ファイル、マイグレーションを列挙します。
• 手順 — 新しいチームが曖昧さなく実行できるよう、ファイルパス、関数シグネチャ、ライブラリ呼び出し、テスト要件を含め、順序立てて詳述します。
• 対象外 — この PR で対応しない内容を明記します。
• 検証 — レビュアーが検証する方法（実行コマンド、手動確認）を記載します。

このコメントは、後から参照できる実行ブリーフです。単独で内容が理解できるものにしてください。

6. 実行する

team-executor のフェーズ 2（実行）のステップ 9～12 を開始し、エージェントに以下を参照させます。

• 元の要件を確認するための Issue（gh issue view <N>）。
• 選択した方針を確認するための投稿済み Issue コメント／docs/plans/issue-<N>/execution-plan.md。
• プロジェクトのコンテキスト（CLAUDE.md、AGENTS.md、README、関連するソースファイル）。

実行エージェントは自律的に作業します。独立した手順は並列に、依存関係のある手順は順次実行します。

7. 検証する

• リポジトリにあるテストスイート、リンター、型チェッカー、ビルドを実行します。package.json のスクリプト、Makefile、pyproject.toml などから確認します。
• UI に変更がある場合：開発サーバーを起動して機能を試し、ブラウザーで検証できなかった場合は明記します。
• PR を作成する前に、対象を絞ったフォローアップエージェントを使って失敗を修正します。

8. プルリクエストを作成する

• 機能ブランチをコミットしてプッシュします。
• gh pr create を実行し、以下を指定します。
  • タイトル：短く、70 文字以内にし、リポジトリのコミットメッセージ規約に合わせます。
  • 本文のセクション：概要（箇条書き）、アプローチ（イシューのコメントへのリンク）、テスト計画（チェックリスト）、Closes #。
• プルリクエストの URL をユーザーに返します。

失敗時の対応

条件	対応
team-executor がインストールされていない	中止します。ユーザーに警告し、確認したパスを示して、インストールコマンドを提示し、確認を待ちます。
イシューが見つからない／アクセス権がない	gh のエラーをそのまま提示し、番号と認証情報を確認するようユーザーに依頼します。
イシューがクローズまたはロックされている	続行する前にユーザーに意図を確認します（手順 1 を参照）。
gh がインストールされていない、または認証されていない	中止し、gh auth login の実行または gh のインストールをユーザーに案内します。
Git リポジトリ内にいない	中止し、状況を報告して、どこで実行するかユーザーに尋ねます。
計画チームから相反する推奨事項が出され、プロジェクトリードが調整できない	TL;DR に相違点を提示し、どちらを採用するかユーザーに決めてもらいます。
実行後にテストが失敗する	対象を絞った修正エージェントを起動します。CI でブロックされるチェックが失敗した状態でプルリクエストを作成してはいけません。
作業ツリーにコミットされていない変更がすでにある	中止し、どう対処するか（stash／コミット／中止）をユーザーに尋ねます。

関連スキル

• software-engineer — エンジニアリング分野の SME です（アーキテクト／開発者／レビュアーの視点を備えた、基盤となるエンジニアリングレイヤー）。すべてのコーディング／アーキテクト／レビュアーエージェントに割り当てられます。スタック／SDK スキルはその上に重ねて適用します。
• team-executor — このスキルが駆動する計画・実行エンジンです。
• commitpush — ユーザーが安全確認を利用したい場合の、コミット手順向けスキルです。
• git-github-cli — ブランチと PR の操作に関する Git／GitHub CLI リファレンスです。