---
globs: "Brain/Permanent/**"
---

# Brain/Permanent ノート編集ルール

Permanent ノートを新規作成・編集・監査するときに読む。create-my-stance / moc-* スキルや手動編集から呼ばれる。

## ファイル操作は obsidian CLI 必須

Permanent ノートの作成・リネーム・移動・削除は必ず `obsidian` コマンドを使う。`mv` や `rm` で直接操作すると、このノートを参照している MOC・他の Permanent・Personal の WikiLink が全部壊れる。

```bash
# リネーム（タイトル変更）
obsidian rename from="Brain/Permanent/2026/旧タイトル.md" to="Brain/Permanent/2026/新タイトル.md"

# 削除（ゴミ箱へ移動）
obsidian delete path="Brain/Permanent/2026/削除するノート.md"

# 新規作成
obsidian create path="Brain/Permanent/2026/タイトル.md" content="..."
```

`obsidian rename` はVault内の全WikiLinkを自動で書き換える。`mv` はファイルだけ動かしてリンクを壊す。

## Permanent の役割

- タイトルは命題形(発見が動詞末尾に圧縮される)
- 1ノート1主張
- 400字以内
- Brain 内の他ノートへのインラインリンク2つ以上(うち少なくとも1つは別の Permanent または MOC)
- 体験談述ではなく一般化された論理で書く

## タイトルの書き方

40字以内の命題一文。発見が動詞でタイトル末尾に圧縮される形を狙う。語尾は「〜である」「〜すべきである」「〜書く」「〜分ける」「〜サイン」のように命題が言い切れる形なら自由。「である型」に揃えるための語尾補完はしない。引数で渡された語尾はそのまま尊重する。

### 1主張1タイトル

タイトルに2つの主張を詰め込まない。接続助詞(が・ことで・せず・ではなく・ため)で独立した述語が2つ繋がっていたら、2つのノートに分ける。分割した結果が平凡すぎるなら、その素材はPermanentにならない。

### スコープのチェック

タイトルを書いたら、上下両方向にスコープを確認する。

下方向では「特定の楽器・特定の場面に張り付いた主張になっていないか」を見る。「ギター録音はDAW直結で済む」のような固有名詞・状況に張り付いた表現は、例が変わると成立しない。「DAW直結は楽器の録音準備をケーブル一本に圧縮する」のように、例が変わっても成り立つ範囲に一段上げる。具体例は本文の中で触れればよい。

上方向では「この具体的発見の上に、もっと広い別の発見が立たないか」を問う。「波形を見れば自分のズレがわかる」の上には「『耳だけで覚えろ』は生存バイアス」という別の発見が立つ。立つなら親と子の両方をノートにする。親が「原理」「アーキテクチャ」のような抽象語に逃げていたら、教科書化しているサインなので戻す。

### 問題と回答の構造

良いタイトルは「ある問題に対する回答」になっている。タイトルを書いたら「これはどんな問題に答えているか」を一文で言えるか確認する。言えなければ候補から落とす。

> 「目標ではなくテーマを設定すると達成未達成の自己否定から解放される」
> → 問題: 目標を立てると達成できないときに自分を責めてしまう

回答だけを述べるタイトルは教科書になる。

### 言葉づかいの基準

禁止語・抽象語逃避・エンジニア動詞・AI比喩動詞などの全般フィルターは `.claude/rules/write-filter.md` 参照。ここではタイトル固有の基準だけ挙げる。

- 口語(やり方・〜なんですよ・〜だよね など)に振れすぎない
- 書き言葉だが平易な語(考え方・運用ルール・手順 など)を選ぶ
- 読点を使わない
- 「異なる」「違う」だけで終わると発見が薄い。何がどう違うかを動詞で示す
- 「〜である」定義文で終わらない。場面や動作が見える言葉で閉じる
- 発見の核を担う「強い動詞」を選ぶ。「選ぶ／決まる／勝負する／両立させる／ずらすだけで弾ける／取り戻せる／突破する」のように動作が見えるもの。「〜にある／〜が宿る／〜である」のような状態動詞は、発見を抽象化して定義文に逃がしやすい。状態動詞しか出てこない時は、その主張がまだ発見になっていないサイン

### タイトルの良し悪しの具体例

良い例・悪い例・修正ペアは `.claude/skills/create-my-stance/references/title_examples.md` に蓄積する。ここにはルールだけ置き、具体例はそちらを参照する。

## frontmatter description の書き方

100〜150字。形式は `【対象】<何についての命題か>。【主張】<命題本体>。【用途】<どんな場面で参照するか>。`。

## 本文の書き方

一文目で命題を断定し、一般化された論理(条件→帰結／対比／適用範囲／逆説)で支え、含意または適用範囲で閉じる。標準的な書き言葉の格を保つ。Brain 内の Permanent ノートへの WikiLink を本文中に2つ以上織り込む。

### 体験談述で書かない

素材に出てくる出来事や人物を「〜で確認した」「〜と話した」「自分は〜」のように本文の根拠として持ち出すと、命題が特定体験に縛られて普遍性が消える。「obt004 では〜」「先日のセミナーで〜」のような出来事参照、素材の場面の要約・描写、「だから」「ただし」「これだ」「〜のだ」のような口語接続の連発も同じ方向の失敗。

体験の事実は Brain/Personal に分離する。

### 固有名詞の扱い

体験・出来事の参照として固有名詞を持ち出さない。「obt004で確認した実感はこれだ」は NG。命題の対象として固有名詞が登場するのは可(例「Apple Notes と Obsidian は別の構造を要求する」)。

### 参考とすべき本文の格

> 思考の質を高めるためには、AI から得られる回答よりも、その前提となる「いかに問うか」に注力すべきである。AI に文脈を伝え、意図した出力を得るために言葉を構造化するプロセスこそが、考えるという行為の本質だからだ。

## 大きなテーマから命題を取り出す(降ろし方)

大きなテーマで一発の上位包括テーゼを探そうとすると抽象に逃げる。手順:

1. 素のまま言葉にする — 「今やろうとしていることは何か」を専門語・抽象語を全部外して言い直す。日常語だけで説明できるところまで降りる
2. 素の言葉のまま3〜4本のテーゼに分ける — 当たり前を当たり前に書く。難しくしない
3. 並列で立つか確認する — 分けた3〜4本がそれぞれ独立して成立するなら正しく分解できている
4. 親(包括ノート)は子の後に回す — 「なぜ全部要るか」を語る統合ノートは、子3〜4本を先に作ってから最後に書く。子へのWikiLinkを本文に埋める形になるので Permanent の原則(インラインリンク2つ以上)も自然に満たす

### 失敗モード

- 上位包括テーゼを一発で決めようとして抽象語に逃げる（禁止語リストは `.claude/rules/write-filter.md`）
- 単一テーゼで全部を背負わせて同義反復に倒れる(「分けて書くと混ざらない」型)
- 「もっとよい書き方ができるはず」と粘る瞬間は抽象化逃避のサイン。素の言葉に戻る
- 網羅表(N軸テーゼ候補一覧)を作って全部を一つの構造で語ろうとする → 認知過負荷

## create-my-stance の設計思想

create-my-stance は対話型スキル（fork なし）。命題の抽出・価値判断は対話の中で行い、スキルは検証・整形・保存だけを担当する。スキル実行中にユーザー確認を挟むため fork では動かない。

スキル実行中の判断基準:

- 問題フィルタ: 「このタイトルはどんな問題に答えているか」を一文で言えるか
- 言い換え検出: 素材の主張をそのまま別の言葉に置き換えただけではないか。素材にない飛躍・接続・視点の転換が含まれているか
- スコープ判定: 素材の具体性に引きずられて命題のスコープが狭すぎないか。一段上げて成立するなら上げる
- WikiLinkの質: 形式的に2つ貼っただけか、論理的に命題を支えているか

## アトミック性

- 1ノート1主張に収まる粒度で分ける
- 統合したくなったら立ち止まる:「本当に同じ主張か?視点が違うだけではないか?」
- 視点・レイヤー・否定形/肯定形・適用範囲が違えば別ノートとして独立成立する
- 「曖昧に似ている」だけで既存と統合して諦めない。まず書いて、後でまとめて統廃合判断する
- 既存類似ノートが見つかっても、既存は参照用 WikiLink として活用し、新規は新規で書く
- 「多すぎる気がする」と感じたら、それは正しい兆候。怯まず分割を選ぶ
- 同じノートが複数のMOCに並ぶのは整理不足ではなく、命題が文脈をまたいで効いている状態。MECEに振り分けようとしない([[アトミックノートは複数のMOCに並べてもよい]] / [[MOCではノートをMECEに振り分けなくていい]])
