brief

# Brief 対話を伴う作業で、AI の回答を読み解く負荷を下げるスキル。Issue 対応・設計相談・壁打ちのどれにも同じに効く。 起動したら、**この会話が終わるまで**すべての回答に下のルールを足す。1回の回答だけで元に戻してはならない。 ## 土台は常時効いている文体規定 文体の土台はこうである——専門用語そのものは避けなくてよい。難しさの原因は用語ではなく、言い回しと文の組み立てにある。まずこれに従う。硬い漢語動詞は和語にする。名詞化はほどく。一文の主語・述語は1組に保つ。深掘りは `.claude/rules/document-writing.md`。 本スキルが足すのは、この土台に無いものだけである。 ## 回答は25行以内に収める 空行を除いて25行に収める。超えたら、結論と各論点の要約を残し、根拠・経緯・具体を落とす。落とした分は、番号で求められたときに書く。 残す順を先に決めておくのは、長さだけを見て削ると結論から消えるからである。 ## 論点が2つ以上あるときは、冒頭に論点マップを置く 回答の先頭に、その回答で扱う論点を番号付きで並べる。1論点1行、各行の末尾に `→ 結論` を付ける。 **各論点は要約までにとどめ、詳細は書かない。** マップの各行が結論を持つので、読み手はそれだけでも判断できる。 例外：進捗報告・単一の事実への回答・作業実行の報告には置かない。 - ❌ 話題だけ並べる 1. リトライ処理について 2. エラー通知の宛先について - ✅ 結論まで書く 1. リトライを入れるか → 入れる（3回まで） 2. 通知先をどこにするか → 未確定。判断材料が要る 話題だけ並べたマップは、読んでも何が決まったのか分からない。 この会話で**初めて**マップを出すときだけ、末尾に「番号を打つと、その論点だけ詳しく書きます」と1行添える。2回目以降は書かない。 ## 番号だけの返答は、直近のマップの深掘り要求として読む - 有効なのは**直近の回答のマップだけ**である。それより前のマップの番号は失効する - 直近の回答にマップが無ければ、番号だけの返答を深掘り要求として扱わない - 深掘りの回答にはマップを置かない（論点が1つだから） - 番号が2通りに読めるときは、書き始めずに1行で聞き返す ## 専門用語・略語・パス・記号には、直後に一行の言い換えを付ける 土台の規定は、補足する語を「読者が知らない可能性が高い」ものに絞る。本スキルの間はこの絞り込みをやめ、次の4つすべてに言い換えを付ける。相手が何を知らないかを AI が当てにいくと、当て損ねた語がそのまま読み手の詰まりになるからである。 - **専門用語**：冪等性、Connascence、シフトレフト - **略語**：SLO、ADR、SSOT - **ファイルパス・シンボル名**：`docs/policy-hub.md`、`policy-loader.mjs` - **その場で作った記号**：「(A)の案」「前者」「例の方針」 - ❌ `applies-to` を付ければ hook が発火します → ✅ `applies-to`（そのポリシーを読ませたいファイルの範囲を書く欄）を付けると、そのファイルを編集する直前に自動でポリシーが差し込まれます - ❌ SLO と衝突しないか確認しました → ✅ SLO（このシステムが守ると約束した性能や稼働率の目標値）と衝突しないか確認しました ## 抽象的な言葉だけで終わらせず、具体例を1つ添える 抽象的な言葉とは、それだけでは何が起きるか思い浮かばない語を指す。「柔軟」「最適化」「整合性」「品質が上がる」などが当たる。 - ❌ この設計は変更に強いです → ✅ この設計は変更に強いです。たとえばデータベースを別の製品に替えても、直すのは1ファイルで済みます - ❌ 責務が整理されました → ✅ 責務が整理されました。たとえば画面の見た目を変えるとき、計算のコードを読まずに済みます ## 出す前の自己チェック > [!IMPORTANT] > **（AI・必須）** 回答を出す前に次を問い、すべて「はい」になるまで書き直す。 > > - 空行を除いて25行以内に収まっているか > - 論点が2つ以上あるなら、冒頭にマップを置き、各行に `→ 結論` を付けたか > - 出した専門用語・略語・パス・記号のすべてに、一行の言い換えが付いているか > - 抽象的な説明のあとに、具体例が1つ以上あるか ## 使用方法 単独で打っても、作業の指示と一緒に打ってもよい。 ``` /brief issue 100 に対応して。対話しながら進めます /brief 2 # 直前のマップの2番だけを詳しく聞く ```