---
name: restructure-doc
description: 既存ドキュメント1ファイルをCLAUDE.mdのルール1〜4に沿って仕分ける。事実・推測・採用案を残し、調査過程をjournalへ移す。
disable-model-invocation: true
argument-hint: <ファイル名>
---

# ドキュメントを再編する

運用ルール策定前に書かれたドキュメントを、CLAUDE.md のルール1〜4に沿った形に作り直す。
**1回の実行で1ファイルだけ**扱う。

## 最重要の制約

**情報を失わせない。** この作業は「移動と再配置」であって、要約でも削除でもない。

- 内容を短くしない。判断に迷った記述は、消さずに残してユーザーに聞く。
- メインドキュメントから外す記述は、必ず journal に移す。捨てない。
- 元の主張を勝手に言い換えない。特に断定度を上げ下げしない。

## 手順

### 1. 全体を読む

対象ファイルを最初から最後まで読む。部分的に読んで判断しない。

### 2. 4分類する

各ブロック(見出し単位、または段落単位)を次のどれかに分ける。

| 分類 | 行き先 |
| --- | --- |
| a. 採用した案 / 現在の設定 / 設計に影響する制約 | メインドキュメントに残す |
| b. 裏取りの済んだ事実 | メインドキュメントに残す(文中のどこでもよい) |
| c. 未確認の推測・未解決の問い | メインドキュメント末尾の `## 未確認事項` |
| d. 調査過程 / 案の比較 / 却下案 / 優先度評価 | `journal/` へ移す |

判定のヒント:

- メリット/デメリット表、優先度リスト、「〜も検討したが」 → d
- 「〜できるはず」「〜と考えられる」「実現可能」で、実際に試していない → c
- 外部仕様の記述(KLEのプロパティ定義など)は、出典を確認できていれば b、していなければ c

### 3. 分類結果を提示して承認を得る

**ここで必ず止まる。** ファイルを書き換える前に、分類の一覧をユーザーに見せて確認する。
特に b と c の境目(裏取りできているか)は自分で判断せず聞く。

### 4. メインドキュメントを書き直す

- a を中心に再構成する。b は文中に自然に置く。
- 「なぜBではないのか」の記述が残っていたら、**制約文**に書き換える。
    - ✗ `階層構造はKLEが非対応なので諦めた`
    - ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- 落とした案があれば末尾 `## 検討済み・非採用` に1案1行(理由なし、journalファイル名を参照)。

### 5. 未確認事項を立てる

c に分類したものを末尾の `## 未確認事項` にまとめる。

- 本文が前提にしている推測 → 本文に `[推測:P-n]` を付け、対応する項目を置く
- まだ本文に書けない未解決の問い → 本文タグなしで項目だけ置く
- 各項目に**格上げ条件**を必ず書く。思いつかないものはユーザーに聞く(空欄で残さない)

```markdown
### P-1 KLEはlabels[9]の内容を保存時に保持する
- 位置づけ: 本文「クラスター管理」が前提にしている
- 格上げ条件: KLE本家でインポート→エクスポートし、labels[9]が残ることを確認する
```

### 6. journal へ移す

d を `journal/YYYY-MM-DD-<元ファイル名>.md` に移す。

- 冒頭に**結論**(このファイルの再編で何が確定し、何を落としたか)
- 次に案の比較(元ファイルの表をそのまま持ってきてよい)
- 以下に元の調査記述
- 整形は最低限でよい

### 7. コミットする

1ファイル1コミット。メインドキュメントと journal を同じコミットに入れる。

```
<ファイル名> を運用ルールに沿って再編

<何を残し、何をjournalへ移したか 数行>

Journal: journal/2026-09-16-<元ファイル名>.md
```

## 注意

- 複数ファイルを一度に触らない。ファイル間で内容が重複していると気づいた場合は、
    勝手に統合せず、指摘だけしてそのファイルの再編を終える。
- 再編の途中で事実関係の誤りを見つけても、勝手に直さない。指摘する。