手引き: feature（新しい振る舞い・変更）

依頼された振る舞いを、設計を決めてから最小の形で作り、実物で確かめる。

1. 言い直す。 新しい振る舞いと、変えてはいけない振る舞いを分けて書く。「できたと分かる確かめ方」を、利用者の言葉に無ければ提案する。
2. 読む。 触る場所の周りがいまどう動くか、既存の形（データの形・命名・エラーの扱い・検査の書き方）を把握する。周りの形に合わせる。外の振る舞い（道具・ライブラリ・API・OS とシェルの版）に拠る部分は、書く前に仕様（公式の文書・man・リリースノート）を読む。動かしてエラーを見てから調べない。
3. データの形を先に決める。 新しい状態や分岐があるなら、散らばった条件分岐でなく構造（表・型・状態の列挙）で表す（principle-model-the-domain・principle-foundational-thinking）。関数の境界をまたぐ変更で形が複数考えられるなら、2 案を短く書いて比べる。議論で決まらないことは試作で決める。
4. 削ってから足す。 触る場所の死んだコード・重複・使われない引数を先に外す（principle-subtract-before-you-add）。最小の変更で依頼を満たす（principle-laziness-protocol）。抽象や設定の鍵を「将来のために」足さない。
5. 検査を書く。 利用者が観測できる振る舞いを assert する（principle-test-behavior-not-implementation）。新しい検査は、意図的に壊した実装で落ちることも確かめる。
6. 単位ごとに確かめる。 小さく積み、各単位の後に検査と実物の起動で確かめる（principle-sequence-verifiable-units）。CI は仕上がった変更の確かめに、まとめて 1 回使う（調べるための job や commit を push しない。playbook-verify の「CI を試し場にしない」）。範囲を広げた単位の後は、前の単位で書いた「この変更でしたこと」の文（作業記録の行・要約・PR の本文）を、playbook-verify の「確かめる」のとおり拾い直す。
7. 仕上げ。 playbook-verify の形で証拠を取り、小さな単位の commit にし、変更を届けるときは「なぜ・何が変わるか・範囲・壊れうる所・どう確かめたか・戻し方」を本文に書く。

返答: 言い直し、何を作ったか、選んだ形とその理由、確かめ方と結果、残る範囲。

会話が要約された後は、入口 bb-writ を呼び直して全文を読み直す（要約の後は、先に呼んだ入口が落ちていることがある）。