reflect: 振り返り、学びを行き先へ送る

学びを取り出し、文書に書いて終わりにせず、効く形と効く場所へ送る。

1. 材料を集める

• この会話（文脈にあるもの）、作業場所の記録（work.py status の note）、PR の本文とレビューのコメント、利用者からの訂正、落ちた検査とその直し方。
• 他のセッションのトランスクリプトを探して読まない（別の仕事・別のリポジトリの会話に触れる）。会話の要約を作るときは、本文の引用でなく、何が起きたかの事実で書く。トークンや個人情報を要約に入れない。

2. 2 人に独立に読ませる

要約を 1 つのファイルにし、同じ依頼を 2 人に渡す: 同じ系統の新しい文脈（Claude Code では Agent）と、別系統（delegate の launcher、読み取り専用）。別系統を使えなければ（もう一方の CLI か、その専用ログインが無い）、同じ系統の新しい文脈をもう 1 人立て、別系統の読みが無いことを返答に書く（delegate の「別系統の判断」）。依頼は「この仕事で、次の仕事でも同じ誤りや遠回りを生む原因を挙げよ。各項目に、起きた事実（どこで・何が）と、それを防ぐ最も強い手段を書け。1 回きりの出来事は挙げるな」。

3. 突き合わせて分ける

2 人の項目をまとめ、根拠を自分で確かめ（記録・差分・コマンドの結果）、次の 3 つに分ける。

• 採る: 2 回以上起きた、または起きれば被害が大きい。防ぐ手段が具体的。
• 退ける: 1 回きり、根拠が無い、すでに仕組みで防がれている。理由を 1 文で。
• 後で: 正当だが、防ぐ手段をいまの仕事の中で作れない（別のリポジトリ・別の担当の持ち物）。どこに積むかを書く。費用を理由にしない。

4. 行き先と形を決める

• 行き先は principle-route-lessons: ワークフローそのものの学びは bb-writ（スキル・スクリプト）へ、対象のドメインの学びは対象のリポジトリへ。
• 形は principle-encode-lessons-in-structure: 作り → 型 → lint・CI → 試験 → 手引きの文、の順に強いものを選ぶ。文を足すのは、判断が要って仕組みにできないときだけ。

5. 送る

• 対象のリポジトリへの学びは、そのリポジトリの通常の方法で変更として出す（入口 bb-writ の流れ。検査を足すなら、過去の実際の誤りで落ちることを示す）。
• bb-writ への学びは、すべての今後の仕事に効くので、採る項目と変更の案（差分か、変える場所と文）を示して、利用者の承認を待つ。後で、の項目は記録に積む。

返答: 採る・退ける・後での一覧（各項目に、起きた事実、挙げた者、行き先と形）、出した変更、承認待ちの案。