smart-spec-to-prlisted

# smart-spec-to-pr — 要件明確化から PR 作成までの conductor 「やりたいこと」を起点に、**要件明確化 → spec 承認 → Issue 起票 → 既存スキル連鎖 → PR 作成**までの進行を管理する。 各フェーズの本体（設計・計画・実装・レビュー）は既存スキルが担い、本スキルが持ち込むのは**進行管理・受け渡し・ゲート**だけである（フェーズロジックは複製しない）。 **終点は PR 作成**。マージ・デプロイはスコープ外。 ## 制御の実態（半自動ハンドオフ） conductor が 1 ターンで制御を保持できるのは **Phase 1 〜 3b** まで。理由: - `smart-issue-plan` / `smart-issue-resolve` は `disable-model-invocation: true` のため、conductor（モデル実行）が Skill ツールで起動できない。**Skill 起動できる連鎖先は `software-architect` のみ**（Phase 3a） - Skill 起動にはコールスタック・リターンの意味論が無い。conductor がハンドオフ用コマンドを印字した時点でターンが終わり、ユーザーの手動実行後に制御が conductor へ戻る機構は無い - したがって Phase 3c/d では、次段コマンドと終点チェックリストを**ユーザー向け手動ランブック**として一括提示してターンを終える。**「ハンドオフ後に結果で分岐する / ゲートを強制する / 起票済み Issue を追跡・後始末する」記述は書かない**（到達不能なため） | Phase | 担い手 | 内容 | conductor の制御 | |---|---|---|---| | 1 要件明確化 → spec 承認 | conductor（本ファイル） | AskUserQuestion で掘り下げ → spec 化 → 承認ゲート | 保持 | | 2 Issue 起票 | conductor（pipeline.md） | `issue_write` で spec 全文を Issue 本文に | 保持 | | 3a 設計 | conductor（pipeline.md） | Skill で `software-architect` 起動 → 出力を Issue コメント化 | 保持 | | 3b レビューモード確定 | conductor（pipeline.md） | 未指定ならレビューループを AskUserQuestion で確定 | 保持 | | 3c/d ハンドオフ | ユーザー手動 | plan / resolve コマンド + 終点チェックリストを提示してターン終了 | 手放す | Phase 2 以降の詳細手順は [references/pipeline.md](references/pipeline.md) にある。**Phase 1 の承認ゲートを通過するまで読み込まない**（下記「物理ゲート」）。 ## 引数の解析 `$ARGUMENTS` を次のルールで解析する: - **レビューループフラグの検出**: 空白区切りトークンのうち、次のいずれかに**完全一致**するトークンだけをフラグとして識別する（トークン境界 ＝ 前後が空白または文字列端。より大きなトークンの部分文字列や、地の文にフラグ名を含む言及は対象外）: | フラグ | 別名