漠然としたトピックから記事のアウトラインを作成するスキルは何をしますか？

ユーザーの代わりに記事を執筆することなく、幅広くまたは形の定まっていないトピックを、独自性があり調査可能な記事のアウトラインに変換します。ユーザーの既存の作業やナレッジベースから出発し、関連コミュニティで繰り返される質問を特定し、焦点を絞った読者の質問を選択し、セクションごとの研究の足場を作成します。

使用するタイミング

以下の場合に使用します：

ユーザーが漠然としたトピックを提示し、それを記事にまとめるための支援を求める場合
ユーザーが調査用の質問、アウトライン、または視点を求める場合
ユーザーが手動で執筆し、後でエージェントに作業を洗練させたい場合
ユーザーが新しいトピックを既存のWikiページ、プロジェクト、または実装作業に結び付けたい場合

以下の場合には使用しないでください：

完成した記事をすぐに執筆する必要がある場合
調査やソース作業を伴わない、一般的なブレインストーミングの場合
テーゼと構造が既に明確な既存の草稿を編集する場合

コアとなる思考モデル

以下のシーケンスを使用します：

漠然としたトピック
  ↓
既存の作業と知識
  ↓
外部からの繰り返し発生する質問
  ↓
焦点を絞った読者の問題
  ↓
独自性のあるテーゼ（論文）
  ↓
具体的なメカニズムまたは設計オブジェクト
  ↓
セクションの主張と調査用質問
  ↓
反論と証拠のギャップ
  ↓
要求されたワークスペースへの再利用可能なアウトライン

目標は未来を予測したり、分野を要約したりすることではありません。目標は、以下の4つの間の最も強力な交差点を見つけることです：

ユーザーが実際に構築し、観察し、考えてきたこと
特定の技術読者が理解したり決定したりする必要があること
現在の実践者が積極的に議論していること
一次資料と具体的な例によって裏付けられること

[[outlining-an-article|記事のアウトライン作成]]のアウトライン作成シーケンスを使用します：

topic → braindump → group → shape → one sentence per section → draft

技術系Substack記事の場合は、作成前に調査レイヤーを追加します：

topic → existing work → recurring questions → focused angle
→ braindump → group → story shape → section claims → research → draft

手順

1. 執筆の制約を定義する

調査を始める前に、以下を確立します：

想定読者
記事のタイプ：技術エッセイ、フィールドガイド、アーキテクチャノート、逆張りの議論、またはケーススタディ
ユーザーがアウトラインを望むか、完成された散文を望むか
アウトラインを保存する場所
ユーザーの既存のプロジェクト、実装、またはWikiコンテキスト

デフォルトは次の通り：技術読者向け、手動での調査と執筆、アウトラインのみ、後で洗練。

完了確認：読者と記事の役割を説明する一文を書く。

2. 最初にユーザーの既存の作業を調査する

参照されたファイルを完全に読み、以下を特定します：

明確なテーゼ
具体的な経験や例
アーキテクチャの境界
失敗事例
評価基準
トレードオフ
未解決の質問
ユーザーが既に使用している言語

ユーザーがWikiやフォルダを参照している場合、新しいフレーミングを考案する前に、重複する概念を検索します。最も関連性の高い概念、ソース、テーマ、ノート、プロジェクトページを読みます。

ユーザー自身の作業に基づいたアイデアを優先します。具体的な実装、失敗した評価、設計上の決定、または未解決のトレードオフは、通常、一般的なトレンドの主張よりも価値があります。

完了確認：ユーザーの資料から3〜8個の再利用可能な原則をリストアップする。

3. 実践者から繰り返される質問を調査する

エンジニアリングコミュニティでの現在の議論や、主要な技術ソースについてウェブ検索を使用します。必要に応じて、複数のサーフェスを検索します：

プロトコルリポジトリとGitHubのイシュー/ディスカッション
公式の実装例
エンジニアリングブログとドキュメント
Redditやその他の実践者コミュニティ
技術フォーラムやカンファレンス資料

トピック名だけでなく、質問を検索します。例：

[topic] GitHub issue authority
[topic] implementation problem
[topic] engineering discussion failure
[topic] protocol limitations
[topic] production lessons

繰り返される質問を、以下のようなカテゴリに記録します：

アイデンティティと権威
状態とトランザクション
相互運用性
データとコンテキストの境界
安全性と悪用
評価と可観測性
製品と運用モデル

体系的なデータセットが裏付けない限り、統計的な人気を主張しないでください。調査が定性的である場合、「サンプリングされた議論で繰り返される質問」のような表現を使用します。

完了確認：テーマ別にグループ化され、代表的なソースが示された10〜25個の繰り返される質問を作成する。

4. 最適な記事の質問を選択する

候補の質問を以下の基準でスコアリングします：

テスト	質問
読者への価値	特定の読者が設計や製品の決定を行うのに役立つか？
ユーザーの権威	ユーザーはここで直接の経験や発展した見解を持っているか？
証拠	主張は一次資料と例で裏付けられるか？
具体性	全体的なトピックよりも狭いか？
独創性	サーベイではなく、視点を生み出しているか？
耐久性	現在の誇大広告が過ぎた後も有用であり続けるか？
シリーズ化の可能性	フォローアップ記事につながるか？

1つのメインの質問と、最大2つの代替案を選択します。なぜ勝者がより優れているかを説明します。

適切な質問の形状：

[特定のビルダー]は、[新しい条件]の下で[特定のシステム]をどのように設計すべきか？

避けるべき形状：

[大規模なテクノロジー]はどのように[業界全体]を変えるのか？

完了確認：選択した読者の質問と、なぜそれが勝つのかを記述する。

5. ユーザーの作業からテーゼを導出する

以下のテンプレートを使用します：

一般的な見解は：
ユーザーの作業が示唆すること：
その見解が不完全な理由：
より有用なモデルは：
ビルダーにとっての実用的な結果：
最も強い反論は：

テーゼは、議論可能な主張であるべきであり、トピックのラベルではありません。

有用な変換の例：

「エージェンティックEコマース」→「マーチャントエージェントは、チャットボットではなく、境界のある結果解決システムである。」
「エンタープライズエージェント」→「統治される単位はモデルではなくアクションシステムである。」
「エージェントメモリ」→「メモリはモデルの機能ではなく、アプリケーション層の制御面である。」

完了確認：一文のテーゼと30秒の説明を書く。

6. 具体的なメカニズムを命名または定義する

テーゼを有用にする設計オブジェクトを記事に与えます。例：

ジャーニーコントラクト
権威の境界
評価ハーネス
コンテキスト予算
機能表面
決定トレース
結果元帳
介入ループ

単に独創的に聞こえるようにするためだけに専門用語を作り出さないでください。その用語が既に存在するかどうかを検索し、隣接する用語を特定し、必要に応じてそれを作業用語としてラベル付けします。

完了確認：メカニズムを1〜3文で定義し、小さな例を示す。

7. 記事をストーリーとして形成する

トピックのカタログを作成しないでください。読者にセクションから次のセクションへと進む理由を与えます。

以下のデフォルトのストーリーフローを使用します：

冒頭の問題またはシナリオ — トピックを説明する前に具体的な状況を示す。
緊張 — 明白な解決策がなぜ機能しないか、または不完全であるかを明らかにする。
テーゼ — 主要な主張を明確に述べる。
メカニズム — 問題を説明するモデル、アーキテクチャ、または設計オブジェクトを紹介する。
適用 — メカニズムが実践をどのように変えるかを説明する。
ガードレールまたはトレードオフ — 何がうまくいかない可能性があり、境界がどこにあるべきかを示す。
証拠と評価 — ビルダーがアプローチが機能することをどのようにして知るかを説明する。
含意 — 読者の仕事や業界にとって何が変わるかを示す。
オープンエンディング — 要約ではなく、質問や未解決の緊張で締めくくる。

すべてのセクションについて、段落を書く前に一文を書きます：

セクション：
このセクションが行う主張：
例または証拠：
読者が今持っている質問：
次のセクションがそれにどのように答えるか：

次のセクションは、通常、前のセクションによって作成された質問に答えるべきです。ストーリーを前進させないセクションは削除します。

完了確認：アウトラインが、単なるテーマのリストではなく、質問と回答の連鎖として上から下まで読めること。

8. ブレインダンプ、グループ化、削減

アウトラインを確定する前に：

ブレインダンプ — 関連するすべてのアイデア、例、ソース、反論、個人的な観察を書き出す。
既存の資料を検索 — Wiki、ノート、ハイライト、プロジェクトファイルを検索する。
グループ化 — 関連するアイデアをグループ化し、選択した角度をサポートしない資料を削除する。
形状を選択 — 上記のストーリーフローまたは別の適切な構造から選択する。
セクションごとに一文を書く — トランジションを確認する。
未解決のアイデアは保留リストに保持 — 記事に無理に組み込まない。

トピックから直接散文に移行しないでください。アウトラインは、生の思考と草稿の間の橋渡しです。

完了確認：保持されたすべてのアイデアはセクションに属し、すべてのセクションには1つの主要な主張がある。

9. 調査用質問と証拠のギャップを追加する

保持された各セクションについて、以下を提供します：

ユーザーが答えなければならない調査用質問
見つけるべき証拠
考えられる反論
テーゼを変えるものは何か
具体的な例、図、またはケース

単に興味深いだけの質問は書かないでください。各質問は、セクションの主張を確立、挑戦、または限定するのに役立たなければなりません。

完了確認：すべてのセクションに、回答可能な調査用質問が2〜5個と、少なくとも1つの証拠ターゲットがある。

10. 反論と証拠のギャップを追加する

一方的なトレンドのナラティブを作成しないでください。4〜8の深刻な反論を追加します。それぞれについて、以下を作成します：

主張：
賛成の証拠：
反対の証拠：
私の考えを変えるもの：
テーゼへの影響：

主張を事実、予測、解釈、または意見としてマークします。公開前に主要な証拠を必要とする主張を特定します。

完了確認：記事の最も弱い裏付けのない主張と、それをテストするために必要なソースをリストアップする。

11. アウトライン成果物を作成する

ユーザーがファイルを要求した場合、要求された場所に作成します。Substackの草稿の場合は、以下を使用します：

substack/drafts/<descriptive-title>.md

フロントマターを使用します：

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: outline
working_title: "..."
---

ファイルには、作業中のテーゼ、読者、選択された質問、調査分野、セクションアウトライン、質問、反論、およびソースリストを含める必要があります。明示的に要求されない限り、完成した記事の散文を書かないでください。

ユーザーが明示的に要求しない限り、Substackの草稿のために wiki/index.md や wiki/log.md を更新しないでください。raw/ を変更しないでください。

完了確認：ファイルが存在し、完全なアウトラインが含まれており、次に何を調査すべきかをユーザーに明確に示している。

12. 結果を報告する

以下の内容を含む短いレポートを提供します：

選択されたフレーミング
それが選択された理由
ユーザーの既存の作業との最も強力な重複
アウトラインが保存された場所
ユーザーが次に調査し、執筆すべきこと
特に「最も一般的」が定性的なサンプルから推測された場合の、調査における制限事項

調査とソースの規律

プロトコルと実装の主張には、主要な技術文書を使用する。
コミュニティディスカッションは、質問や障害モードを発見するために使用し、市場全体の行動の疑いのない証拠としては使用しない。
プロトコルの能力、実装の振る舞い、ユーザーの信頼、市場の採用を区別する。
一般的な予測よりも、具体的な例、トレース、評価ケース、障害レポートを優先する。
ウェブ検索を使用した場合、最終的な回答でインターネットから得られた事実に基づく主張を引用する。
定性的な検索結果を統計的に代表的なものとして提示しない。

一般的な障害モード

ユーザーの最も強力な証拠ではなく、業界トピックから始める。
議論なしにプロトコルの概要を作成する。
実際の分析単位がジャーニー、ワークフロー、またはアクションシステムである場合に、エージェントを分析単位として扱う。
読者の質問を定義する前に記事を書く。
モデルの能力と実稼働での保証を混同する。
APIやプロトコルを安全な相互運用性の証明として扱う。
記事の結論を変えることができない調査用質問をする。
「市場は～に向かっている」などのフレーズで不確実性を隠す。
隣接する文献を確認せずに、印象的な用語を作成する。
ユーザーが調査と手動での執筆を依頼したときに、洗練された散文を起草する。

確認チェックリスト

終了前に：

漠然としたトピックから記事のアウトラインを作成するスキル