tldr-expert

TL;DR エキスパート

概要

TL;DR エキスパートスキルは、技術的な内容を明確かつ簡潔に要約します。構造化されたパターンを適用して、複雑な情報を、対象読者に適した詳細度の実行可能な概要へとまとめます。

使用する場面： PR の説明文の作成、レビュー担当者向けのコード変更の要約、関係者向けのエグゼクティブブリーフの作成、長い議論から決定事項やアクションアイテムの抽出、リリースノートの作成。

使用しない場面： 完全なドキュメントの作成（docs スキルを使用）、マーケティング文の作成、詳細なチュートリアルの作成、網羅的な説明が必要な仕様書の作成。

クイックリファレンス

パターン	形式	要点
エグゼクティブサマリー	結論を最初に示し、次に根拠、その後に詳細を示す	推奨事項から始める。逆ピラミッド型にする
PR の説明文	変更内容、理由、テスト方法	レビュー担当者はタイトルと最初の段落を読む
コード変更	変更したファイル、主な決定事項、影響範囲	行ごとの差分ではなく、意図に焦点を当てる
会議メモ	決定事項、アクションアイテム、未解決の質問	議論は省き、結果を記録する
リリースノート	ユーザー向けの変更、破壊的変更、移行方法	開発者ではなく、ユーザーに向けて書く
技術概要	課題、解決策、代替案、推奨事項	最大 1 ページ。詳細へのリンクを付ける

よくある間違い

間違い	正しいパターン
冗長で、あらゆる詳細を含めている	価値の 80％を維持しながら、元の長さの 20％に削る
背景がなく、読者が知っている前提で書いている	要約の前に、背景を一文で説明する
3 段落目まで重要なポイントが出てこない	最初の文で結論または重要な変更を述べる
会議メモに実行可能な項目がない	すべての会議の要約に担当者と期限を記載する
WHY ではなく HOW を要約している	実装の詳細ではなく、意図と影響から始める
読者を意識していない	深さを調整する。経営層向け＝箇条書き 3 点、開発者向け＝1 段落
開発者向けに書かれたリリースノート	コード変更ではなく、ユーザーが何をできるようになるかに焦点を当てる
PR の説明文に「さまざまな修正」と書いている	各変更とその理由を列挙する。曖昧な説明では誰の役にも立たない
リリースノートに破壊的変更が記載されていない	破壊的変更は専用のセクションを設け、移行手順を記載する
技術に詳しくない読者に専門用語を使っている	読者の専門知識のレベルに語彙を合わせる

委任

• 内容の調査：Explore エージェントを使って資料を収集します
• 詳細なレビュー：要約の前に、Task エージェントを使って徹底的に分析します
• コードレビュー：変更の影響評価を code-reviewer エージェントに委任します

docs スキルが利用できる場合、完全なドキュメントの作成はそのスキルに委任してください。

参考資料

• 要約のパターン、テンプレート、段階的な情報開示