手引き: docs-skill（文書・スキル・知識の変更）

README・手引き・SKILL.md・知識ベースを、読者が目的を達成できる形に直す。文章が整っていることは完成ではない。

1. 読者と目的を決める。 誰が、何をしたくて読むか。「読者がその手順で目的を達成できる」を確かめ方にする。スキルなら「意図した依頼で使われ、意図しない依頼で暴発せず、必要な行動に至る」。知識なら「出典をたどれ、必要な情報を見つけ、矛盾を区別できる」。規則・方針なら「当てはまる場面で、読者が文書だけから同じ答えを出せる」。確かめ方を「〜を含む」「〜が書かれている」の形で書いたら、読者が何をして何を得るかの形に書き直す（含んでいても、行どうしが食い違えば読者は答えを出せない）。
2. 事実を実物で確かめる。 文書が指すコマンド・パス・名前・数値を、リポジトリと実行で照合する。CI の定義・スクリプト・ディレクトリの実体が正本で、文書は従。英日の対（README.md と README.ja.md）は両方を同じ変更で直す。外部の出典に照らす主張は、その主張を定める節を全文読む。表と箇条書きは最後の行まで読む。行の範囲指定や grep の一致で切り出すと、すぐ外にある限定や例外を読み落とし、読み落としたことも残らない。文ごとに、拠る相手（上流の出典か、同じリポジトリの別のページ・表か）を分けて照らし合わせる。「ページ全体を読み直した」と書くのは、すべての文をその相手と照らし合わせたときだけにする。上流とだけ照らし合わせたなら、そう書く。表や節を変えたら、そこを指すリンク（ファイル名とアンカー）でリポジトリを検索し、リンク元の文が変えた後も正しいかを読む。変えた語での検索だけでは、言い換えた要約文（「まだ作っていないものがある」）を見落とす。
3. 既存の規則に従う。 そのリポジトリの文体・用語・節の形・機械の検査（lint・スキャン・リンク検査・公開前の検査）を読み、同じ形で書く。新しい規則を持ち込まない。
4. 書く。 1 文 1 事。読者が次に取る行動が分かる文。推測の語（「はず」「たぶん」）を事実の文に混ぜない。
5. 確かめる。 そのリポジトリの文書の検査をすべて実行する。手順の文書は、書いたとおりに実行して通ることを確かめる。読者が従って動く・判断する文書（スキル・手引き・手順・規則・方針）の変更は、文書だけを渡した新しいセッション（別の子。delegate の launcher で読み取り専用に立てる）を読者役にする。スキルや手順なら代表的な依頼を遂行させて成果物を見る。規則や方針なら、当てはまる場面の問い（境界・例外・2 つの行が両方当たる場面）に根拠の行を添えて答えさせ、答えが行によって割れないか、意図と同じかを見る。PR の本文を読ませること、「〜を含むか」を聞くこと、対象のリポジトリの別の役の agent（設計の文書との整合を見る役など）に見せることは、読者役の代わりにならない。読者役の成功報告でなく、成果物で判断する。キーワードが含まれているかの検査を完成にしない。
6. 仕上げ。 変更の理由と、確かめたこと・確かめられなかったことを本文に書く。

返答: 読者と目的、何を直したか、実物との照合で分かったこと、実行した検査と読者役の結果、確かめていない範囲。

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