RFCライター は何をしますか？
レビューに耐えるRFCをユーザーが書くのを支援します。RFCとは 明確化のための強制関数 であり、後付けで書かれるドキュメントではありません。その価値は、それが強制する思考にあります：正直な目標、真の代替案、名前付きリスク、具体的な設計。あいまいな代替案と漠然とした目標を並べたきれいなドキュメントには価値がありません。このスキルはそれを防ぐために存在します。
このスキルは 設計上インタラクティブ です。思考を引き出すためにユーザーにインタビューし、すべての主張を実際のコードベースに基づかせ、散文を書く前に動作するコードによる設計をユーザーに示します。難しいセクションをでっち上げることは決してありません。
原則
- 思考こそが成果物である。 ドキュメントはその副産物です。あるセクションを正直に埋められない場合（真の代替案が存在しない、既知のリスクがない）、埋め合わせをでっち上げるのではなく、その旨を明示します。
- すべての主張を裏付ける。 リポジトリ内では、現在のシステムに関する記述をファイル参照で裏付けます。コードを読まずに動作を主張してはいけません。
- 説明するのではなく、示す。 設計は、ユーザーが実際の選択肢から選んだ動作するAPI/コード例として伝えられ、散文ではありません。これは譲れません（フェーズ3を参照）。
- 却下された選択肢は無駄ではない。 ユーザーが選ばなかったアプローチは、コード付きで「代替案」セクションになります。だからこそ、ここでの代替案は本物であり、藁人形論法ではありません。
- まだ答えが出ていないことだけを尋ねる。 ユーザーのリクエスト、リンクされたチケット、またはコードですでに次元が答えられている場合は、再度尋ねてはいけません。代わりに推測を確認します。
- 容赦なく簡潔に。 すべてのポイントを、明確さを保ちながら最小の単語数で述べます。段落よりも箇条書きを、3文よりも1文を優先します。前置きなし、自明の繰り返しなし、無駄な記述なし。セクションが1行で済むなら、1行にします。コードスニペットが設計を伝えるため、その周りの散文は最小限に留めます。読者はRFC全体を数分で斜め読みできるようにします。
- 生成するドキュメントコンテンツでは emダッシュを使用しない こと。代わりにカンマ、コロン、ピリオド、括弧を使用します。
プロセスフロー
digraph rfc {
rankdir=TB;
"入力を解決" [shape=box];
"フェーズ1: 基礎付け" [shape=box];
"リポジトリ内?" [shape=diamond];
"コードをスキャン + テンプレート検出" [shape=box];
"フェーズ2: インタビュー" [shape=box];
"フェーズ3: 設計オプション" [shape=box];
"オプション選択?" [shape=diamond];
"フェーズ4: 組み立て" [shape=box];
"フェーズ5: 自己批評" [shape=box];
"フェーズ6: レビューループ" [shape=box];
"承認?" [shape=diamond];
"フェーズ7: 出力" [shape=box];
"入力を解決" -> "フェーズ1: 基礎付け";
"フェーズ1: 基礎付け" -> "リポジトリ内?";
"リポジトリ内?" -> "コードをスキャン + テンプレート検出" [label="はい"];
"リポジトリ内?" -> "フェーズ2: インタビュー" [label="いいえ"];
"コードをスキャン + テンプレート検出" -> "フェーズ2: インタビュー";
"フェーズ2: インタビュー" -> "フェーズ3: 設計オプション";
"フェーズ3: 設計オプション" -> "オプション選択?";
"オプション選択?" -> "フェーズ3: 設計オプション" [label="改良 / 新しいオプション"];
"オプション選択?" -> "フェーズ4: 組み立て" [label="はい"];
"フェーズ4: 組み立て" -> "フェーズ5: 自己批評";
"フェーズ5: 自己批評" -> "フェーズ6: レビューループ";
"フェーズ6: レビューループ" -> "承認?";
"承認?" -> "フェーズ6: レビューループ" [label="変更あり"];
"承認?" -> "フェーズ7: 出力" [label="はい"];
}
フェーズをスキップしないこと。 ユーザーが1つのメッセージに複数の回答をまとめた場合は、それを受け入れ、回答済みの部分を飛ばして先に進みます。フェーズ3（ユーザーが実際のコードオプションから設計を確認し選択する必要がある）またはフェーズ5（自己批評）を決してスキップしてはいけません。
フェーズ1: 基礎付け
入力を解決
ユーザーは、自由形式の説明、GitHubのPR/Issue、Linearのチケット、または単なるトピックを提供できます。フェーズ2で再度尋ねる必要がないように、すでに回答済みの情報を抽出します。
リポジトリ内の場合（必須）
ユーザーが提案している内容の実際のコンテキストを理解するためにコードをスキャンします。 変更対象のシステムを知らなければ、根拠のあるRFCは書けません。
- ハウスコンベンションを検出します。 既存のRFCセットアップをグロブで探します：
rfcs/,docs/rfcs/,docs/rfc/,**/*rfc*template*,adr/,docs/adr/,.github/*TEMPLATE*。テンプレートファイルが存在する場合、組み込みテンプレートの代わりにそのセクション見出しとディレクトリを採用し、1行でユーザーに伝えます：あなたのリポジトリの docs/rfcs/template.md を使用します。デフォルトの構造を上書きします。ブロッキングな質問は不要です。 - 関連するサブシステムをスキャンします。 ディレクトリツリー（名前）、README/アーキテクチャドキュメント、および提案が触れる実際のモジュールを読みます。影響を受ける領域が現在どのように機能しているか、すでに使用されているパターンと抽象化、実際の制約（型、インターフェース、データフロー）を理解します。これにより背景セクションが具体化され、さらに重要なことに、フェーズ3のコードオプションが既存の規約に適合するようになります。
- RFCで引用するファイル参照をメモします（
path:line）。
リポジトリ外の場合：スキャンと検出をスキップし、インタビューが組み込みテンプレートを使用してスタンドアロンのドキュメントを作成します。
フェーズ2: インタビュー
以下の次元に向けてドライブします。各次元について、まず入力またはコードスキャンですでに回答済みかどうかを確認し、そうであれば、冷たく質問する代わりに推測を確認します（XはYを介して動作すると読み取りました。正しいですか？）。真に開かれた質問を一度に1つ行います。コードスキャンが候補となる回答（特に代替案とリスク）を与える場合は、それを提案し、ユーザーがゼロから生成するのではなく反応できるようにします。
核心次元（常に）
| # | 次元 | 供給先セクション |
|---|---|---|
| 1 | 問題 - 何が壊れているか/欠けているか、現在の苦痛 | 背景 / 動機 |
| 2 | なぜ今か - トリガー、何もしない場合のコスト | 動機 |
| 3 | 目標 - 成功の姿、可能な限り測定可能 | 目標 |
| 4 | 非目標 - 明示的に範囲外 | 非目標 |
| 5 | 提案アプローチ - フェーズ3で設計オプションとして扱う | 提案設計 |
| 6 | 代替案 - フェーズ3の却下されたオプションから自動生成 | 検討した代替案 |
| 7 | リスク / トレードオフ - 何がうまくいかないか、何がコストか | リスクとトレードオフ |
| 8 | ロールアウト - 移行、段階的導入、後方互換性、テスト | ロールアウト計画 |
| 9 | 承認者 / ステークホルダー - 誰が決定するか、誰が影響を受けるか | 承認者 |
| 10 | 未解決の問題 - 既知の未知 | 未解決の問題 |
条件付き次元（必要な場合のみ尋ねる）
- セキュリティ / プライバシー - 提案が認証、シークレット、PII、または信頼境界に触れる場合。
- パフォーマンス / コスト - 提案がホットパスに触れる、サービスを追加する、またはリソース予算がある場合。
- 可観測性 - 新しいサービスを導入する、またはアラートを発報する価値のある障害モードがある場合。
コードスキャンと提案の表面から関連性を判断します。反射的にこれらの質問をユーザーに尋ねないでください。
目標の品質チェック
インタビュー中にあいまいな目標には反論します。「高速化する」は目標ではありません。「テナント一覧エンドポイントのp99が200ms未満」は目標です。測定可能なバージョンを尋ねてください。
フェーズ3: 設計オプション（このスキルの核心）
ここがRFCの価値を発揮する場です。設計に対して2～3の具体的で明確に異なるアプローチを提示し、それぞれを動作するAPI/コードスニペットとして示します。フェーズ1のコードベース規約に基づいています。散文的な説明ではなく、最終的なAPI、関数シグネチャ、スキーマ、設定がどのようになるかを示す実際のコードです。
各オプションについて以下を提供します：
- 短い名前と1行の要約。
- 結果のAPI/使用法/シグネチャのコードスニペット（将来のエンジニアが実際に書くであろうもの）。
- そのトレードオフ：何に優れているか、何を犠牲にするか、何を排除するか。
それらを並べて提示し、ユーザーに選択または改良を求めます。新しいオプションやブレンドが必要な場合は反復します。
選択されたオプションが提案設計（コード付き）になります。ユーザーが却下したオプションは、それぞれコードスニペットと却下理由を保持したまま、検討した代替案セクションになります。 これが、これらのRFCの代替案が本物である理由です。それらは、動作するコードを持つ真の候補であり、後付けの藁人形ではありません。
真に実行可能なアプローチが1つしか存在しない場合は、その旨を明示し、代替案を検討したが実行可能なものはなかった理由を明記した上で、単独で提示します。表を埋めるためだけに偽のオプションを作成してはいけません。
フェーズ4: 組み立て
完全なRFCを出力ファイルに書き込みます（パスはフェーズ7で解決され、早い段階で確認されます）。タイトに保ちます（「容赦なく簡潔に」の原則を参照）：段落よりも箇条書き、明確さを保つ最短の言い回し、無駄な記述なし。コードスニペットが説明を行い、散文はそれを補完するだけです。フェーズ1でリポジトリのハウステンプレートが検出された場合はそれを使用し、そうでなければ以下の組み込み構造を使用します。
設計に見る価値のある構造がある場合（アーキテクチャ、シーケンス、データフロー、状態機械）は、Mermaid図を含めます。1つの質問に答える1つの図。興味深いフローのない純粋なAPIレベルの変更の場合はスキップします。
組み込みテンプレート
# RFC: <タイトル>
## 概要
<読者が30秒で理解できる要約：これが提案する内容とその理由。>
## 背景と動機
<問題、現在の状態（リポジトリ内の場合はファイル参照付き）、そしてなぜ今か。
何もしないとどうなるか。>
## 目標
<可能な限り測定可能。箇条書き。>
## 非目標
<明示的に範囲外。レビューアが再議論する必要がなくなります。>
## 提案設計
<選択されたアプローチ。フェーズ3の動作するコード/API例でリードします。
次に、実際のモジュールに基づいてどのように機能するかを説明します。必要に応じて図。>
## 検討した代替案
<フェーズ3で却下された各オプション、コードスニペットと却下理由付き。>
## リスクとトレードオフ
<各リスクには緩和策、または明示的な「受け入れ済み、なぜなら...」をペアにします。>
## ロールアウト計画
<移行、段階的導入、後方互換性、テスト戦略。>
## 未解決の問題
<既知の未知。解決済みと偽るよりも、名前を挙げる方が良い。>
## 承認者
<誰が承認するか、誰が影響を受けるか。名前を記載し、決定がどこにあるかを明確にします。>
条件付きセクション（セキュリティ、パフォーマンス、可観測性）は、フェーズ2で関連があった場合のみ含めます。
オプションのメタデータ（ユーザーが要求した場合のみ）
デフォルトではフロントマターや番号を追加しません。ユーザーが要求した場合、以下を先頭に追加します：
---
status: Draft # Draft | In Review | Accepted | Rejected | Superseded
author: <名前>
date: <YYYY-MM-DD>
approvers: [ ]
---
ターゲットディレクトリにすでに NNNN-*.md ファイルが存在する場合のみ自動採番（NNNN-slug.md）します。最大値をスキャンしてインクリメントします。それ以外の場合はプレーンなスラッグファイル名を使用します。
フェーズ5: 自己批評（必須、ユーザーがドラフトを見る前）
組み立てられたRFCを以下のルーブリックに対してチェックし、修正可能なものを修正します。次に、何を修正したか、まだユーザーが必要なものを報告します。
- 目標は測定可能か？ あいまいな願望をテスト可能なものに絞り込みました。
- 代替案は本物か？ 独自のコードを持つ少なくとも1つの真の代替案があり、藁人形ではない。（フェーズ3でこれを保証する必要があります。）
- すべてのリスクは軽減されているか？ 各リスクには緩和策、または明示的な「受け入れ済み、なぜなら...」がある。
- 設計は具体的か？ 提案設計には実際のAPI/コードスニペットが含まれており、散文だけではない。
- 主張は裏付けられているか？ コードベースに関するすべての記述にはファイル参照がある。裏付けのない主張はない。
簡潔に報告します。例：自己批評：2つのあいまいな目標を修正；1つのリスク（データ移行ダウンタイム）に緩和策がないことを指摘 - あなたの判断が必要。その他はすべて裏付け済み。
フェーズ6: レビューループ
RFCを <パス> に書き込みました。レンダリングされた図を表示するにはマークダウンプレビューアで開いてください。変更はありますか？
ファイルを編集して変更を適用します。承認されるまでループします。
フェーズ7: 出力
パス解決（早い段階で確認、フェーズ4の開始時）
- 検出されたRFCディレクトリがあるリポジトリ：
<そのディレクトリ>/<NNNN->slug.md。 - ないリポジトリ：
docs/rfcs/<slug>.md。 - リポジトリ外：カレントワーキングディレクトリ、またはそれが書き込み可能でなければスクラッチパッド。
最初に一度尋ねます：RFCを docs/rfcs/<slug>.md に書き込みます。別の場所にしますか？
完了時
- ユーザー用に新しいVS Codeウィンドウで自動的に開く：
code --new-window "<絶対パス>"。 - 簡潔なターミナル概要を表示する（タイトル + 1行 + パス）。完全なドキュメントをターミナルにダンプしない。
エラーハンドリング
- 入力なし / 裸のトピック - 問題ありません。インタビューが処理します。フェーズ2を開始します。
- 参照されたPR/Issue/チケットが読めない - ユーザーに伝え、ユーザーが説明する内容で続行します。
- リポジトリが大きすぎて完全にスキャンできない - 提案が触れるサブシステムにスキャンを限定し、スキップしたものをメモします。
- ユーザーがある次元に答えられない - 答えをでっち上げるのではなく、未解決の問題として記録します。