Menu
複数の BizSpec プロセスを横断してリファクタリング提案を行う。重複の統合・不要 unit の除去・順序の最適化などを提案し、ユーザーが選んだものだけ YAML に適用する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | bizspec-refactor |
| description | 複数の BizSpec プロセスを横断してリファクタリング提案を行う。重複の統合・不要 unit の除去・順序の最適化などを提案し、ユーザーが選んだものだけ YAML に適用する。 |
| argument-hint | なし（起動後に対話形式で設定） |
| disable-model-invocation | true |
複数の BizSpec プロセスを横断して分析し、リファクタリング提案をリストで提示する。 ユーザーが選んだ提案だけを YAML に適用する。提案の実装判断はユーザーに委ねる。
引数は受け取らない。起動したら以下の順で質問する。
bizspec list（引数なし）を実行し、全プロセスの unit 数を把握したうえで選択を求める。
対象プロセスを選んでください:
[1] issue-refinement (9 units)
[2] pr-review (4 units)
[a] すべて
番号を入力（複数可: 1 2）:
a で全プロセスを対象にできるリファクタリングの観点があれば教えてください（省略可）:
例: manual を減らしたい / AI 化できる unit を探したい / 冗長な unit を整理したい
>
対象プロセスを選んだら、まず以下のコマンドで構造サマリーを取得する。
bizspec list [プロセス名] --refactor
引数なしで全プロセスが対象になる。このコマンドで各 unit の aim・link.up/down・core・executor・effort を一覧できる。
aim で一次スクリーニングし、候補を絞り込む一次スクリーニングで怪しいと判断した unit のみ、フルYAMLを Read して rule・io の詳細を確認する。
全 unit を一括 Read せず、必要なものだけ読む。
上記2ステップで得た情報をもとに、以下の軸で分析する。
複数プロセスにまたがって aim が意味的に近い unit を検出する。
検出の目安:
提案の形:
「〇〇プロセスの△△ unit と □□プロセスの▽▽ unit は同じ目的を持っています。共通プロセスとして切り出すか、一方が他を参照する形に整理できます。」
ゴール達成への貢献が薄い unit を検出する。
検出の目安（複数該当するほど優先度が高い）:
core: falselink.down が空（末端ノード）executor.type: manualio.in が独立）提案の形:
「△△ unit はゴール達成に直接関与しておらず、下流 unit もありません。削除、または別プロセスへの分離を検討してください。」
同一プロセス内で分割しすぎている unit を検出する。
検出の目安:
aim が「〇〇して△△する」と一文で言えるio.out が他方の io.in の全体である（中間産物がない）提案の形:
「△△ unit と ▽▽ unit は一連の処理で分ける意味が薄いです。統合して1 unit にできます。」
直列になっているが実は並列実行できる unit を検出する。
検出の目安:
link.up を持ち、互いを参照していないio.in に互いの出力を必要としていない提案の形:
「△△ unit と ▽▽ unit は独立しており、同時に実行できます。link を更新して同一レベルに配置できます。」
フローの途中に位置するのに後続がなく、プロセスゴールに繋がっていない unit を検出する。
検出の目安:
link.down が空（末端ノード）であるが、core: true でなく、かつ他の unit の link.down にも参照されていない提案の形:
「△△ unit はプロセスの最終出力に繋がっておらず、Dead End になっています。目的を確認し、削除または下流 unit との接続を検討してください。」
プロセス全体の流れを1つの unit が直列に絞り込んでいる箇所を検出する。
検出の目安:
link.up を持ち、その後に1本の流れが続く（多→1→少 の形）提案の形:
「△△ unit は上流 N unit の合流点になっており、ここがボトルネックになっています。処理を分割するか、executor を ai_agent/script に変更することで並列化できます。」
同じデータや判断文脈を扱うべき unit が不必要に分断されている箇所を検出する。
検出の目安:
io.in / io.out を見たとき、B の出力が「A の入力を単純に加工しただけ」であり、C が実質 A のデータを再度必要としているaim が同一ドメインの部分処理になっている（同じ文脈をバラバラに扱っている）提案の形:
「△△ → ▽▽ → □□ の流れは同一文脈の処理が断片化されています。▽▽ を △△ に統合し、コンテキストをひとまとめにすることで、後段への受け渡しが明確になります。」
── 分析対象: <プロセス名, ...> (<合計 unit 数> units) ──────────
[1] <種別>
<対象: プロセス名/unit名 （↔ 対象2）>
<理由を1〜2文で>
→ <具体的な変更の方向性>
[2] ...
適用する番号を入力してください（複数可: 例 1 3）。スキップは Enter:
ユーザーが番号を入力したら、選択された提案ごとに処理する。
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）:
CLI で表現できない以下のケースのみ Edit を使う。変更後は必ず bizspec validate を実行して link の双方向整合性を確認する:
link を相互に更新rule / io を Edit で統合 → 元 unit を bizspec rm で削除/bizspec-refine への引き継ぎを促す重複統合の提案を含む場合は適用後に次のように案内する:
── 案内 ──────────────────────────────────────────────────────
提案 [1] は共通 unit の設計が必要です。
/bizspec-refine を使って新しいプロセスまたは unit を設計することをお勧めします。
今すぐ /bizspec-refine を使いますか？（y/N）:
YAML を変更したら必ず検証を実行し、結果を報告する（bizspec-refine の検証方法セクションと同じ優先順位で実行する）。
core: true の unit は積極的に削除候補にしない（ゴール達成に必要なため）link の双方向整合性は変更後も必ず保つ