diff --git a/skills/miko.refine-br/SKILL.md b/skills/miko.refine-br/SKILL.md
new file mode 100644
index 0000000..270e431
--- /dev/null
+++ b/skills/miko.refine-br/SKILL.md
@@ -0,0 +1,133 @@
+---
+description: 既存の business_rules.md を最新フォーマットに揃える（ビジネスポリシー新設、ドメイン/システムの2.1/2.2分割、採番コメント追加）。ルールの本文・ID・意味は一切変更しない。
+---
+
+## 入力
+
+```text
+$ARGUMENTS
+```
+
+入力の形式: `<capability_name>`
+
+- 例: `/miko.refine-br order_management`
+- 空の場合はエラー: 「⛩️  ケイパビリティ名をお願いいたします（例: `/miko.refine-br order_management`）」
+
+**`miko/<capability>/business_rules.md` が存在しない場合はエラー:**
+
+> ⛩️  `miko/<capability>/business_rules.md` が見つかりません。
+> 既存コードがある場合は `/miko.catchup <capability>` で、新規の場合は `/miko.new-cap <capability>` で先に business_rules.md を作成してください。
+
+---
+
+## このスキルの役割
+
+既存ケイパビリティの `business_rules.md` を、現行のガイド基準の**構造**に揃える。ルールの**本文・ID・タグ・意味は一切変更しない**、純粋な構造上の整形スキル。
+
+`.miko/guides/business_rules_guide.md` は「既存 BR の構造には、ユーザーから明示的な移行依頼がない限り手を入れない」と定めている。**このスキルを実行すること自体が、その明示的な移行依頼にあたる。**
+
+### v1 スコープ（このスキルがやること）
+
+1. `## ビジネスポリシー（ビジネス方針）` セクションの新設（なければ、かつ候補があれば）
+2. `## 2. ビジネスルール・カタログ` の `### 2.1 ドメインビジネスルール` / `### 2.2 システムビジネスルール` への分割（未分割なら）
+3. 各カテゴリ末尾への `<!-- last: {プレフィックス}-{番号} -->` 採番コメントの追加（なければ）
+
+### スコープ外（将来の拡張・別スキル）
+
+- ルール本文の語彙規律・粒度の書き直し（コード語彙の除去、150字超の分解等）
+- ルールの分割・統合（新規 ID 採番を伴うもの）
+- ケイパビリティを横断する境界セクションの整合性チェック
+- 実装とルールの乖離の是正（未実装なのに制約と断定している等）— これは `/miko.propose` の領分
+
+このスキルが検出したが対応しなかった問題（語彙規律違反、粒度違反、ルールの重複、実装マッピングの腐り等）は、**「7. 完了報告」で一覧として提示するに留め、修正はしない**。
+
+### 保証すること
+
+- **ルール ID は一切変更しない。** 番号の振り直し・欠番の解消も行わない
+- **ルール本文・タグ（[制約]/[導出]）は一切変更しない**
+- カテゴリの物理的な配置（2.1 / 2.2 のどちらに属するか）と `<!-- last: -->` コメント以外、ファイルの内容を変えない
+- 上記の結果、`harae.md` や `proposals/` からのルール ID 参照は一切壊れない（このスキルの実行後に harae.md や proposals を更新する必要はない）
+
+---
+
+## 手順
+
+### 1. 入力検証
+
+`$ARGUMENTS` からケイパビリティ名を取得し、スネークケースに正規化する。`miko/<capability>/business_rules.md` の存在を確認する。
+
+### 2. 資料の読み込み
+
+- `.miko/guides/business_rules_guide.md` — ドキュメント構造、ビジネスポリシーの判定基準（客観性テスト）、ドメイン/システムの区別（紙運用テスト）、カタログの書き方
+- `.miko/guides/tone_guide.md` — 対話スタイル。**このファイルの口調・絵文字・出力言語ルールに従うこと**
+- `.miko/examples/business_rules.md` — 目標とする構造の実例
+- `miko/<capability>/business_rules.md` — 対象ファイル（全文）
+- `miko/<capability>/harae.md` — あれば（構造整形が指摘の ID 参照に影響しないことの確認用。内容は変更しない）
+- `miko/<capability>/proposals/` — あれば、ファイル名一覧のみ確認（同上）
+
+### 3. 現状診断
+
+対象ファイルを診断し、以下を判定してユーザーに提示する。
+
+| 項目 | 判定 |
+|---|---|
+| ビジネスポリシーセクション | 有 / 無 |
+| 2.1 / 2.2 分割 | 済 / 未 |
+| 各カテゴリの `<!-- last: -->` | カテゴリごとに 有 / 無 |
+
+**すべて揃っている場合**: その旨を報告して終了する（変更なし）。
+
+**一部でも未整備の場合**: 次のステップへ進む。
+
+### 4. ドメイン/システムの判定（2.1/2.2 未分割の場合のみ）
+
+`.miko/guides/business_rules_guide.md` の「紙運用テスト」（そのルールは、システムが存在しない世界でも意味として成立するか？）を、カタログの全ルールに適用する。
+
+**重要な注意（判定の誤りを避けるため）**: 判定は **ルール本文に書かれている内容だけ** を見て行う。背景セクションや実装マッピングに書かれた「なぜこのルールが必要になったか」という経緯・理由は判定に使わない。ルールが存在する理由が技術的（非同期処理、外部システムとの整合性維持など）であっても、ルールの中身（何を定めているか）自体が紙運用でも成立する内容であれば、それはドメインビジネスルールである。
+
+- 良い例: 「投稿者名は正規経路以外からは参照されないよう秘匿する」は、実現手段が暗号化であっても、「誰に開示するか」という約束自体は紙の鍵付き書庫でも成立する → ドメイン
+- 避けるべき誤り: 「このルールは非同期処理があるから必要になった」という背景の記述だけを根拠に、ルール本文自体が紙運用で成立するにもかかわらずシステム側に分類すること
+
+**カテゴリ単位の判定:**
+- カテゴリ内の全ルールが同じ判定（全ドメイン or 全システム）に収まる場合、カテゴリごと 2.1 または 2.2 へ配置する
+- カテゴリ内にドメインとシステムが混在する場合、`business_rules_guide.md` の原則（同一カテゴリはどちらか一方に置く）に従い、カテゴリを 2.1 側・2.2 側それぞれに分けて配置する。**ルール ID・プレフィックス・番号は変更しない。** カテゴリ見出し（日本語名）は 2.1 側・2.2 側で同一のものを使う（例: `#### 申込管理（APP）` が両方に現れてよい）
+
+**要確認の扱い:** ルール本文の内容だけを見ても紙運用テストの結果が割れる（意図的に両論を作り出さず、本当に判定が難しいと感じたものだけ）ルールは、自動で決めず「要確認」としてリストアップし、次のステップでユーザーに判断を仰ぐ。無理に全件を機械的に確定させない。
+
+### 5. ビジネスポリシー候補の検出（ビジネスポリシーセクションが無い場合のみ）
+
+`business_rules_guide.md` の「客観性テスト」（任意のケースで客観的に判定できるか？ できないなら方針＝ポリシー）を、背景セクションの記述および各ルールの前提となっている考え方に適用する。
+
+- 該当する記述（価値判断・優先順位の表明で、既存ルールの前提や背景に埋没しているもの）があれば、`POL-{連番}` の候補として抽出する
+- **無理に見つけようとしない。** `business_rules_guide.md` は「ケイパビリティあたり3〜5個が目安、多すぎる場合はルールへの分解を再点検する」と定めている。候補が薄い場合は、空のセクションを新設するか、セクション自体を今回は見送るかをユーザーに確認する
+
+### 6. 【確認】適用案の提示
+
+以下をまとめて提示し、承認を得る。
+
+- ビジネスポリシー新設案（候補と抽出元、または「候補なし」の報告）
+- 2.1 / 2.2 への配置案（カテゴリ単位の判定結果、および要確認ルールの一覧と両論）
+- `<!-- last: -->` 追加箇所
+
+要確認ルールについては、「A（ドメイン）と B（システム）どちらの解釈も成り立ちますが、どちらに寄せますか」という形で個別に判断を仰ぐ。まとめて一括承認を求めない。
+
+フィードバックがあれば反映して再提示する。承認されたら次に進む。
+
+### 7. 適用
+
+確認された内容で `business_rules.md` を書き換える。
+
+- ルール ID・タグ・本文・実装マッピングは一切変更しない
+- カテゴリ内のルールの記述順は元のまま保持する
+- ビジネスポリシーセクションは「背景」の直後、「状態遷移」（あれば）の前に配置する
+- 新設したビジネスポリシーセクションの末尾に `<!-- last: POL-XX -->` を追加する
+- 2.1 / 2.2 の配置後、各カテゴリ（分割された場合は分割後のそれぞれ）の末尾に既存の最終 ID から `<!-- last: -->` を追加する
+
+### 8. 完了報告
+
+以下をサマリーテーブルで提示する。
+
+- 新設したセクション（ビジネスポリシー: 件数 / 分割: 対象カテゴリ数）
+- 要確認として人間の判断を仰いだ件数と、その結果
+- **スコープ外として今回は手を入れなかった問題の一覧**（語彙規律違反・粒度違反・ルールの重複・実装マッピングの腐り等に気づいた場合、件数と代表例を報告する。修正はしない）
+- ルール ID・本文・harae.md・proposals への参照はいずれも変更していない旨を明記する