second-brain-fix

セカンドブレインの修正

監査によって問題が見つかり、形がわかるように1か所を修正しました。このスキルでは、 監査で残った調査結果をもとに、残りをバッチごとに修正します。

引数

この実行時に指定された調査結果ファイルは$audit-resultsです。これは省略できます。

/second-brain-fix                                   nothing passed
/second-brain-fix ~/notes                           a folder to look in
/second-brain-fix ~/notes/second-brain-audit.md     the findings file itself

$audit-resultsは調査結果が記載された1つのMarkdownファイルへのパスです。/second-brain-auditは 出力するファイルをsecond-brain-audit.mdと定めているため、通常はそのファイルを渡されますが、 ファイル名は必須ではありません。調査結果を記載したMarkdownファイルならどれでも使えます。 ユーザーが指定したファイルを使用してください。

何よりも先に、パスを解決してください。

渡されたもの	実行すること
ファイルへのパス	それが調査結果ファイルです。ファイルに別のフォルダーが記載されていない限り、メモのフォルダーはその親フォルダーです
フォルダーへのパス	その中から調査結果ファイルを探します。まずsecond-brain-audit.mdを確認してください
指定がなく、上の行がまだ \$audit-resultsと表示されている	現在のフォルダー、次にその1階層下を確認します
存在しないパス	その旨を伝えて停止します。検索に切り替えてはいけません。そうすると、パスの誤記があっても別のフォルダーを誤って使ってしまいます
検索で候補が複数見つかった	各候補の最新の## Logの日付を添えて一覧表示し、どれを使うか尋ねます
検索で候補が見つからなかった	停止します。作業の手掛かりがないため、先に/second-brain-auditを実行するよう伝えます

調査結果がない状態で、キューを一から作ってはいけません。監査と修正を一度に行うと、 誰も確認していない調査結果に対して一括書き込みが行われることになります。

調査結果が入力です。 $audit-resultsはキューであり記録でもあります。## Current Stateには 場所ごとにキー付きの行を1つ、## Logには実行ごとに日付入りの行を1つ記載します。 以下のすべての作業はこのファイルをもとに進めます。このファイルを更新しない実行は、 後から誰も引き継げません。

このスキルは一括で書き込みます。開始前にバックアップを確定してください。

これを確定する前に書き込みを始めてはいけません。また、メモのフォルダーを別の場所に コピーして解決してはいけません。メモのフォルダーを複製すると、あらゆる問いに対する 答えが2つになってしまいます。それこそが、このスキルで解消しようとしている問題です。

まず、現在の状態を確認してください。 メモのフォルダーでgit rev-parse --show-toplevelを実行します。

• すでにgit管理下にある場合。独立したリポジトリである場合も、親リポジトリで追跡されている場合も同様です。未処理の変更をコミットするかスタッシュしてから、git checkout -b second-brain-fixを実行し、各バッチの後にコミットします。どのリポジトリにいるかを伝えてください。別のプロジェクト内にVaultがあるのはよくあるため、ブランチが何を対象としているかをユーザーが把握できるようにします。

• git管理下にない場合。次のように尋ねます。

  メモはgit管理下にないため、バッチを元に戻す方法がありません。ここで先にgit initを実行してもよいですか？ これはお使いのマシン内にとどまり、どこにもプッシュされません。各バッチをチェックポイントにでき、 そこまで戻せるようになります。

  同意が得られたら、git init、git add -A、ベースラインのコミットを1つ作成し、その後ブランチを作成します。リモートは追加せず、プッシュもしてはいけません。

  同意されない場合は、もう一度だけ確認して回答に従います。

  承知しました。念のため確認です。多数のファイルを一度に書き換えるため、元に戻す方法はありません。 それでも続けますか？

  明確に「はい」と回答されたら、作業を進め、この件を再度持ち出してはいけません。回答がない場合や、 曖昧な回答の場合は停止します。質問への回答がないことは、許可を意味しません。

3つの分類は、それぞれ異なる作業です

分類	調査結果に含まれるもの	対応
矛盾あり	古くなった主張と、それを覆す新しい証拠	質問せず、バッチで修正します
裏付けなし	主張のみで、それを裏付ける情報がない	推測してはいけません。ユーザーにまとめて質問します
未変換の場所	## Current State / ## Logがないページ	そのままバッチで変換します

一括修正で問題が起きるのは、中央の分類です。裏付けのない主張には定義上メモ内に 答えがありません。そのため、「これらを修正して」と指示されたエージェントは、値をでっち上げるか、 その行を黙って削除してしまいます。どちらも古くなった主張を残すより悪い結果です。

どこまで取り組むか

ノートの規模を尋ねるか、Markdown ファイルの数を数えて、取り組む範囲を調整します。

規模	実施内容
約50ファイル未満	すべてを1回のセッションで実施します。2〜3回に分けて処理します
約50〜500ファイル	常に読み込まれる範囲を先に処理し、その後、フォルダーごとに1回分ずつ処理して、間にコミットします
500ファイル以上	常に読み込まれる範囲に加えて、履歴があるページ（同じテーマについて時間をかけて複数の記録があるもの）だけを処理します。それ以外は永久にそのままにします

ノートの規模が大きいからといって、変換する量を増やすわけではありません。変換する割合を小さくし、書き込み時の処理により力を入れます。その規模では、誰もアーカイブを手作業で細かく管理し続けられないからです。

ステップ1：バッチ一覧を作成する

$audit-results を読みます。## Current State にある項目のうち、修正済みと記されていないものと、監査で報告されたものの列挙されていない項目を取り出します。フォルダーをまとめられる場合はまとめながら、場所ごとにおよそ5〜15件のバッチに分けます。

何かを書く前に、バッチ一覧と順序をユーザーに提示します。順序は必ず次のとおりです。

1. 毎回のセッションで読み込まれるもの。
2. エージェントが最も頻繁に間違えるページ。
3. 履歴があるページ。
4. それ以外は対象外。

ステップ2：矛盾がある項目をバッチで処理する

各指摘では、新しい証拠がすでに特定されています。したがって、次のようにします。

• ## Current State の古い行を置き換えます。
• 置き換えた行を一字一句そのまま ## Log に移します。
• 新しい行には、今日の日付ではなく、証拠の日付を記載します。

最後の点は、見た目以上に重要です。現在の値に日付を付けることは、その日に誰かが値を確認したという主張になります。6月に書かれたメモをもとに修正した行に今日の日付を付けると、6月時点の事実が今朝確認されたように見えてしまいます。

バッチ全体を処理してから、置き換えた行数、対象ファイル、最も分かりにくかった3〜4項目をまとめて提示します。行ごとの差分は提示せず、行ごとの確認も求めません。

ステップ3：場所ごとにバッチで変換する

各ページに2つのセクションを設けます。監査で見つかった形式に合わせて調整します。

## Current State


- **Retainer** (2026-08-01): $3,200/mo, renewed through February 2027
- **Main contact** (2026-05-02): Curtis Ilo

## Log


- (2026-04-30) Delivered and paid, $21,000
- (2026-06-15) Added reply drafting, retainer to $3,200/mo

大きなファイルが1つある場合は、ファイルの先頭に ## Current State ブロックを設け、その下にほかのすべてを置きます。新しいファイルは作成しません。日次ノートの場合は、現在の値を記載した新しいファイルを1つ作成し、日誌には手を加えません。Markdown 以外のノートは変換しません。

これは分類作業であり、書き直しではありません。 既存の行はすべて、最大でも日付を先頭に追加するだけで、どちらかのセクションに一字一句そのまま移します。文章を改善すると、誰にも気付かれずに情報が消えてしまうことがあります。バッチ処理では、細かく確認する人がいないため、それを見つけるのは困難です。

箇条書きに日付がなく、日付を特定する方法もない場合は、日付をでっち上げたり、項目を日付なしのままにしたりしないでください。箇条書きに証拠の記載があれば、その証拠の日付を使います。なければ、日付の代わりに (date unknown) と記載します。日付のない項目は見落としに見えますが、(date unknown) とあれば、そのまま次の監査に引き継がれ、確認事項として残ります。

変換せず、そのままにしておくべきページが2種類あります。その場合は変換せず、その旨を伝えます。

• 参照用チェックリスト。 荷造りリスト、入院バッグのリスト、標準的な作業手順などです。太字のキーや日付が少なく、順序そのものが内容です。変換すると、構造上のチェック項目はすべて満たせても、そのリストの有用性の源が失われます。
• 最新の状況が、箇条書きの下にある見出し配下の文章に記載されているページ。 そのセクションを解体すると、最新の状況が ## Current State の外に、最も古い情報がその中に残ります。これは、取り除こうとしている問題を、1段上の階層で再構築することになります。

ステップ 4：未確認事項をまとめて、一度に質問する

すべて集めて、番号付きリストにして一度だけ質問します。一つずつ質問してはいけません。また、黙って処理してはいけません。

それぞれ、結果は次の 3 通りです。

• 現在も正しい場合は、ユーザーが指定した日付とともに ## Current State に記載し、証拠が単に誤った場所に保存されていたのではなく、欠けていたことを明確に伝えます。
• 現在は正しくない場合は置き換え、元の行をそのまま ## Log に記録します。
• 判断できない場合は、常時読み込まれるファイルから完全に削除します。自信満々に誤った回答をするより、回答がないほうがましです。

ユーザーから回答がなければ、すべてそのままにします。質問への未回答は、変更してよいという許可ではありません。

オーナーの判断待ちにするものには、記載箇所で注記を付ける

要約に記した質問は、一人に一度だけ届きます。その行はメモに残り、今後のすべてのセッションで読まれるため、警告は報告書だけでなく、その行自体に記載しなければなりません。

オーナーだけが解決できないために行を残す場合は、元のテキストをそのまま残し、その後に理由を追記します。

- **Sam Iwu**: accepted a full-time offer, starting October 2026. UNVERIFIED (fix run
  2026-09-18): no date and no source anywhere; entities/sam-iwu.md says he is still a
  contractor. Confirm or delete.

- **Ferro retainer renewal** (2026-09-12): renewed at $6,500/mo through year-end. CONFLICT
  (fix run 2026-09-18): the 2026-09-10 call set it to $12,000/mo. Nothing sources this line.
  Ask before quoting either number.

特に重要なのは、今修正した行より新しい古い行がある場合です。あるキーに 10 日付で $12,000 と記載され、別のキーに 12 日付で $6,500 と記載されている場合、そのページを読むエージェントは新しいほうを採用して $6,500 と回答します。そのため、2 つ目のキーに警告を付けない限り、最初のキーを修正しても何も変わりません。このケースがないか、各バッチの後に必ず確認してください。修正した各キーについて、同じページに同じ話題を扱う、より新しい日付の別のキーがないか調べます。

矛盾を解決するために行を削除してはいけません。また、自分で値を選んではいけません。行に注記を付けることが、対応のすべてです。

ステップ 5：結果を書き戻す

各バッチの後に $audit-results を編集します。

• 各場所の ## Current State の行を、新しいステータスに置き換えます。各場所につき必ず 1 行です。2 行目を追加してはいけません。
• 注記を付けて残した行をすべて記録し、次回の実行で、オーナーの判断待ちのものを再度調べ直さなくても把握できるようにします。
• ## Log に 1 件追記します。日付、バッチ番号、置き換えた行数、変換した場所の数、未回答の未確認事項の数を記載します。

その後、バッチをコミットします。調査結果とメモを一緒に移動するため、実行が中断されても、1 つのファイルを読めば再開できます。

ステップ 6：再監査して比較する

バッチが完了したら、もう一度 /second-brain-audit を実行し、矛盾の件数を直近の ## Log の行と比較します。この件数だけが、これらの作業が機能したことを示す証拠です。

件数があまり変わらなかった場合は、変換を成果として示すのではなく、そのことと理由を述べます。再構成しても、誰も一度も書き残していない事実にはたどり着けません。件数が変わらない場合、通常はそれが原因です。その場合、修正すべきなのは書き込み経路であり、別のバッチではありません。

調査結果ファイルの名前が変更されている場合は、その点を 1 つ警告してください。audit.py は名前が second-brain-audit で始まるファイルをスキップするため、名前を変更すると次回のスキャンでは証拠として読み込まれ、古い主張がそのまま引用されます。名前をそのままにするか、ファイルを notes フォルダーの外に置いてください。

決して曲げてはならないルール

1. 何も失わないでください。 すべての行を、そのままどこかに残します。行を配置できない場合は、元の場所に残し、その旨を報告してください。
2. 似ている項目を決して統合しないでください。 「Acme（5月）」と「Acme Corp の更新」は、実際には別のものかもしれません。重複項目は些細なミスですが、誤った統合は情報を破壊します。バッチの最後に類似している項目を報告し、判断はユーザーに委ねてください。整理しているように見えるため、バッチ作業では既定で統合されがちです。このルールは意識して守る必要があります。
3. 値を決してでっち上げず、項目を減らすために主張を削除しないでください。 所有者に判断を委ねる内容には、理由を要約だけでなく、その行自体に記載してください。チャットウィンドウにしか存在しない警告こそ、このスキルが防ぐべき失敗です。
4. ## Log の項目を編集または削除しないでください。 古くなっていたり、後から置き換えられていたりすることが、このセクションの目的です。
5. 日付は、その値が確認されたという主張です。 移動しただけの行には、元の日付を残してください。
6. バックアップとしてノートフォルダーをコピーしないでください。 Git を使うか、事情を理解したうえで使わないかのどちらかです。それ以外は認められません。
7. 常時読み込まれる範囲に矛盾がなくなったら、そこで止めてください。 古いページが詰まったアーカイブは履歴であり、腐敗ではありません。すべてのページを変換する必要はありません。

書き込み経路がまだ変更されていない場合

CLAUDE.md（または AGENTS.md、あるいはシステムプロンプト）に、監査のフェーズ 7 で定めた状態／イベントのルールが記載されているか確認してください。記載されていない場合は、作業を始める前に追加し、その理由を説明してください。追記しかできない書き込み経路の下で 400 行を修正しても、効果は約 1 か月しか続きません。