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番だけを詳しく聞く