exec-issue: 実装プランにスキル実行が含まれる場合の確実な実行保証

[utsubasa]

概要

exec-issue スキルで Issue を実行する際、その Issue の実装プランに「特定スキルの実行」が含まれているケースで、当該スキルが確実に実行される保証がない。本 Issue は、実装プランにスキル実行ステップが含まれる場合でも、exec-issue がそれを取りこぼさず確実に実行することを目的とする。

達成すべきゴール

• Issue の実装プランに「○○スキルを実行する」というステップが含まれる場合、exec-issue 実行時に当該スキルが必ず呼び出される。
• スキルが実行されなかった場合に、それが暗黙的にスキップされ別の手段で代替される（＝期待した副作用が起きない）状態を防ぐ。

問題の詳細

現状の exec-issue の実行フロー（skills/exec-issue/SKILL.md ステップ2）は、実装プランから洗い出した各タスクをサブエージェントへ委譲する設計になっている。

• UI 実装・マークアップ → frontend-implementer サブエージェント
• それ以外 → general-purpose-assistant サブエージェント

ここに以下の構造的問題がある。

1. サブエージェントにスキル発火の指示・保証がない
   agents/frontend-implementer.md / agents/general-purpose-assistant.md のいずれも、特定スキルを Skill ツールで呼び出す指示を持たない汎用実装エージェントである。タスクプロンプトに「○○スキルを実行せよ」と書かれていても、サブエージェントがスキルを呼ばず自前の判断で同等処理を手作業実装してしまう／取りこぼす可能性がある。

2. タスク分解時にスキル実行ステップの情報が落ちる
   read-github-issue（ステップ1で利用）が作成する実装プランは「並列実行可能な単位での分解」を重視しており、スキル実行ステップであるという属性を明示的に保持・伝播する仕組みがない。exec-issue 側でもスキル実行ステップを通常タスクと区別して扱う分岐が存在しない。

3. 結果としてスキル特有の副作用が保証されない
   スキルは固有の手順・ガードレール・フック（例: exec-issue 自身の Stop フックや、各スキルの前提処理）を伴う。サブエージェントによる代替実装ではこれらが再現されず、Issue の意図した成果が得られない。

要件

機能要件

• exec-issue は、実装プランの各ステップが「スキル実行を要するか」を判定できること。
• スキル実行ステップは、サブエージェントへの委譲ではなく、確実にスキルが発火する経路で実行されること（例: メインエージェントが Skill ツール／スラッシュコマンドで直接実行する分岐を設ける）。
• スキル実行ステップをサブエージェントに委譲せざるを得ない場合は、対象スキル名と「必ず Skill ツールで当該スキルを呼び出すこと」をプロンプトに明示し、サブエージェントがスキルを発火できることを担保すること。
• スキル実行ステップと通常タスクの依存関係（順序・並列可否）が維持されること。

非機能要件

• 既存の通常タスク（スキル実行を含まない Issue）の挙動・並列実行性能を退行させないこと。
• スキルが実際に呼び出されたことが、実行ログ／PR 説明等で追跡可能であること（取りこぼしの検知容易性）。

参照情報

• skills/exec-issue/SKILL.md — 本件の中心。ステップ2のサブエージェント委譲ロジックが問題の発生源。Stop フックでの docker compose down も、サブエージェント代替時に前提が崩れる例。
• skills/read-github-issue/SKILL.md — 実装プラン作成元。スキル実行ステップを区別・マーキングする拡張余地がある。
• agents/frontend-implementer.md / agents/general-purpose-assistant.md — 委譲先サブエージェント。スキル発火の指示・保証を持たない。
• skills/commit-push/SKILL.md / skills/create-pr/SKILL.md — ステップ5・6で exec-issue 自身が呼び出すスキル群。スキル間連携の既存パターンとして参照。

実装プラン（案）

Phase 1: スキル実行ステップの識別

• read-github-issue の実装プラン出力フォーマットを拡張し、スキル実行を要するステップに明示マーカー（例: 対象スキル名と「skill実行ステップ」である旨）を付与する。
• もしくは exec-issue ステップ2の冒頭で、実装プラン各ステップを走査し「スキル実行を要するステップ」を分類するロジックを追加する。

Phase 2: 実行経路の分岐

• スキル実行ステップは、サブエージェント委譲フローから分離し、メインエージェントが Skill ツール（スラッシュコマンド）で直接実行する経路を exec-issue に追加する。
• スキル実行ステップと通常タスクの依存関係を尊重した実行順序制御を実装する（先行スキル → 後続タスク等）。
• やむを得ずサブエージェント内でスキルを実行する場合のフォールバックとして、プロンプトに対象スキル名と Skill ツール呼び出しの必須指示を明記する。

Phase 3: 取りこぼし検知と注意書き

• スキル実行ステップ実行後、当該スキルが実際に呼び出されたことを確認し、未実行なら警告／再実行する仕組みを設ける。
• SKILL.md の注意事項に「スキル実行ステップは Skill ツールで確実に実行する」旨を追記する。

影響範囲

• skills/exec-issue/SKILL.md（中心的変更）
• skills/read-github-issue/SKILL.md（実装プランへのスキル実行ステップ・マーキング追加の場合）
• agents/frontend-implementer.md / agents/general-purpose-assistant.md（サブエージェント内スキル実行をフォールバックとして許容する場合の指示追記）

確認事項（要回答）

1. スキル実行ステップは原則メインエージェントで直接実行する方針でよいか（サブエージェント委譲は避ける）。
2. 「スキル実行ステップ」の識別を read-github-issue 側のマーキング拡張で行うか、exec-issue 側の走査ロジックで行うか、どちらを優先するか。
3. 取りこぼし検知（Phase 3）まで本 Issue のスコープに含めるか、最小実装（Phase 1・2）に留めるか。