| name | bizspec-refactor |
| description | 複数の BizSpec プロセスを横断してリファクタリング提案を行う。重複の統合・不要 unit の除去・順序の最適化などを提案し、ユーザーが選んだものだけ YAML に適用する。 |
| argument-hint | なし（起動後に対話形式で設定） |
| disable-model-invocation | true |
あなたの役割
複数の BizSpec プロセスを横断して分析し、リファクタリング提案をリストで提示する。
ユーザーが選んだ提案だけを YAML に適用する。提案の実装判断はユーザーに委ねる。
起動時の質問
引数は受け取らない。起動したら以下の順で質問する。
Q1: 対象プロセスの選択
bizspec list（引数なし）を実行し、全プロセスの unit 数を把握したうえで選択を求める。
対象プロセスを選んでください:
[1] issue-refinement (9 units)
[2] pr-review (4 units)
[a] すべて
番号を入力（複数可: 1 2）:
- 複数プロセスを選べる（横断分析がこのスキルの主目的）
a で全プロセスを対象にできる- 1プロセスのみでも実行可能
Q2: リファクタリングの観点（省略可）
リファクタリングの観点があれば教えてください（省略可）:
例: manual を減らしたい / AI 化できる unit を探したい / 冗長な unit を整理したい
>
- 省略時は7軸すべてを均等に分析する
- 指定時はその観点を優先してランキングする
データ取得の進め方
ステップ1: 構造把握（軽量・全体）
対象プロセスを選んだら、まず以下のコマンドで構造サマリーを取得する。
bizspec list [プロセス名] --refactor
引数なしで全プロセスが対象になる。このコマンドで各 unit の aim・link.up/down・core・executor・effort を一覧できる。
- フロー構造系（Dead End・Serial Bottleneck・順序最適化・不要候補）はこのサマリーだけで判断できる
- 意味系（重複・統合候補・Context Fragmentation）は
aim で一次スクリーニングし、候補を絞り込む
ステップ2: 詳細確認（絞り込み後のみ）
一次スクリーニングで怪しいと判断した unit のみ、フルYAMLを Read して rule・io の詳細を確認する。
全 unit を一括 Read せず、必要なものだけ読む。
分析の7軸
上記2ステップで得た情報をもとに、以下の軸で分析する。
1. 重複（横断）
複数プロセスにまたがって aim が意味的に近い unit を検出する。
検出の目安:
- 異なるプロセスに「同じ情報を取得/評価/判定する」unit が存在する
- executor.type・io の構造が似ている
提案の形:
「〇〇プロセスの△△ unit と □□プロセスの▽▽ unit は同じ目的を持っています。共通プロセスとして切り出すか、一方が他を参照する形に整理できます。」
2. 不要候補
ゴール達成への貢献が薄い unit を検出する。
検出の目安（複数該当するほど優先度が高い）:
core: falselink.down が空（末端ノード）executor.type: manual- 他の unit の出力に依存していない（
io.in が独立）
提案の形:
「△△ unit はゴール達成に直接関与しておらず、下流 unit もありません。削除、または別プロセスへの分離を検討してください。」
3. 統合候補（同プロセス内）
同一プロセス内で分割しすぎている unit を検出する。
検出の目安:
- 隣接する2 unit の
aim が「〇〇して△△する」と一文で言える
- 両方の executor.type が同じ
- 一方の
io.out が他方の io.in の全体である（中間産物がない）
提案の形:
「△△ unit と ▽▽ unit は一連の処理で分ける意味が薄いです。統合して1 unit にできます。」
4. 順序最適化
直列になっているが実は並列実行できる unit を検出する。
検出の目安:
- 2つの unit が同じ
link.up を持ち、互いを参照していない
- かつ
io.in に互いの出力を必要としていない
提案の形:
「△△ unit と ▽▽ unit は独立しており、同時に実行できます。link を更新して同一レベルに配置できます。」
5. Dead End（孤立末端）
フローの途中に位置するのに後続がなく、プロセスゴールに繋がっていない unit を検出する。
検出の目安:
link.down が空（末端ノード）であるが、core: true でなく、かつ他の unit の link.down にも参照されていない- 言い換えると「誰にも使われておらず、どこにも続いていない」孤立した unit
提案の形:
「△△ unit はプロセスの最終出力に繋がっておらず、Dead End になっています。目的を確認し、削除または下流 unit との接続を検討してください。」
6. Serial Bottleneck（直列ボトルネック）
プロセス全体の流れを1つの unit が直列に絞り込んでいる箇所を検出する。
検出の目安:
- 1つの unit が多数（3つ以上）の
link.up を持ち、その後に1本の流れが続く（多→1→少 の形）
- または executor.type が manual で、前後の unit が script / ai_agent であるにもかかわらず間に挟まっている
提案の形:
「△△ unit は上流 N unit の合流点になっており、ここがボトルネックになっています。処理を分割するか、executor を ai_agent/script に変更することで並列化できます。」
7. Context Fragmentation（文脈断裂）
同じデータや判断文脈を扱うべき unit が不必要に分断されている箇所を検出する。
検出の目安:
- 連続する unit（A→B→C）の
io.in / io.out を見たとき、B の出力が「A の入力を単純に加工しただけ」であり、C が実質 A のデータを再度必要としている
- executor.type が同じ連続 unit で、それぞれの
aim が同一ドメインの部分処理になっている（同じ文脈をバラバラに扱っている）
提案の形:
「△△ → ▽▽ → □□ の流れは同一文脈の処理が断片化されています。▽▽ を △△ に統合し、コンテキストをひとまとめにすることで、後段への受け渡しが明確になります。」
提案リストの出力フォーマット
── 分析対象: <プロセス名, ...> (<合計 unit 数> units) ──────────
[1] <種別>
<対象: プロセス名/unit名 （↔ 対象2）>
<理由を1〜2文で>
→ <具体的な変更の方向性>
[2] ...
適用する番号を入力してください（複数可: 例 1 3）。スキップは Enter:
- 提案が0件の場合は「リファクタリング候補は見つかりませんでした」と報告して終了する
- 観点が指定されている場合は関連度の高い提案を上位に並べる
提案の適用
ユーザーが番号を入力したら、選択された提案ごとに処理する。
CLI コマンド経由で適用する変更（推奨）
link 参照の自動更新やフロー分断検知が働くため、ファイルの直接編集ではなく必ず CLI コマンドを使う:
- 不要候補の削除:
bizspec rm <process> <unit> — link 参照を自動更新。フロー分断が検出された場合は警告 → --force 要否をユーザーに判断させる
- リネーム / 名称統一:
bizspec rename <process> <old> <new> — 同プロセス内の link 参照を自動更新。他プロセスの depends_on 参照は警告のみ（手動更新が必要）
- 採番再整理:
bizspec renumber <process>
破壊的変更は必ず --dry-run でプレビューしてからユーザーに承認を求める:
[3] の適用: 'X' を削除します（link 参照を 2 ファイルで自動更新）
プレビュー: bizspec rm pr-review X --dry-run
よろしいですか？（y/N）:
直接 YAML 編集が必要な変更
CLI で表現できない以下のケースのみ Edit を使う。変更後は必ず bizspec validate を実行して link の双方向整合性を確認する:
- 順序最適化（rename / 削除を伴わない link.up/down の組み替え）: 関係する両 unit の
link を相互に更新
- 2 unit の統合（マージ）: マージ先 unit の
rule / io を Edit で統合 → 元 unit を bizspec rm で削除
適用できない変更（提案のみ）
- プロセス跨ぎの重複統合: 構造的な判断が必要なため、提案にとどめて
/bizspec-refine への引き継ぎを促す
重複統合の提案を含む場合は適用後に次のように案内する:
── 案内 ──────────────────────────────────────────────────────
提案 [1] は共通 unit の設計が必要です。
/bizspec-refine を使って新しいプロセスまたは unit を設計することをお勧めします。
今すぐ /bizspec-refine を使いますか？（y/N）:
検証
YAML を変更したら必ず検証を実行し、結果を報告する（bizspec-refine の検証方法セクションと同じ優先順位で実行する）。
注意事項
core: true の unit は積極的に削除候補にしない（ゴール達成に必要なため）link の双方向整合性は変更後も必ず保つ- 1つの提案適用後に他の提案に影響が出る場合は、その旨を伝えてから続行する
- 変更は最小限にとどめ、「とりあえず整理する」より「明確な理由がある変更」を優先する
