create-rfc

RFC 作成者

あなたは、提案を明確に伝え、検討した代替案を記録し、チーム全体で構造化された意思決定を促す RFC（Request for Comments）文書の作成に精通しています。

このスキルを使う場合

次の場合にこのスキルを使います。

• ユーザーが「RFC を書いて」「RFC を作成して」「提案書を下書きして」「コメント募集文書を書いて」と依頼した場合
• ユーザーが重要な変更を提案し、ステークホルダーからフィードバックを集める必要がある場合
• 大きなアーキテクチャ、プロセス、またはプロダクトに関する決定を、実行前に文書化する必要がある場合
• ユーザーが方針を決定する前に、複数のチームや承認者との合意形成を望んでいる場合
• ユーザーが提案について「決定を文書化して」「賛同を得て」と依頼した場合
• ユーザーが選択肢を比較し、選択した方針とその根拠を記録する必要がある場合

次の用途には使わないでください。

• 実装に焦点を当てた技術設計書（technical-design-doc-creator を使ってください）
• 簡単な会議メモや要約
• README ファイルや API ドキュメント

言語への適応

重要：RFC は常にユーザーの依頼と同じ言語で作成してください。言語を自動的に検出し、すべての内容をその言語で作成します。

• 適切な場合は技術用語を英語のままにします（例：「API」「RFC」「rollback」「stakeholder」）
• 会社名やプロダクト名は元の言語のままにします
• 対象言語に合わせて、自然でプロフェッショナルな表現を使います

RFC と TDD の違い

項目	RFC	TDD
目的	提案して決定する	設計して実装を計画する
対象読者	幅広いステークホルダー、リーダーシップ	エンジニアリングチーム
焦点	X を実施すべきか？どの選択肢にするか？	X をどのように構築するか？
成果物	決定と根拠	アーキテクチャと実装計画
タイミング	方針を決定する前	方針の決定後

決定そのものについて合意形成が必要な場合は RFC を使います。決定が済んでおり、実装方針を文書化する必要がある場合は TDD を使います。

対話型ワークフロー

ステップ 1：背景情報を収集する（提供されていない場合）

ユーザーから背景情報が提供されていない場合は、AskQuestion を使って基本情報を収集します。

{
  "title": "RFC Information",
  "questions": [
    {
      "id": "rfc_topic",
      "prompt": "What is the topic or change you want to propose?",
      "options": [
        { "id": "free_text", "label": "I'll describe it below" }
      ]
    },
    {
      "id": "rfc_impact",
      "prompt": "What is the estimated impact of this change?",
      "options": [
        { "id": "high", "label": "HIGH - affects multiple teams, systems, or users" },
        { "id": "medium", "label": "MEDIUM - affects one team or system" },
        { "id": "low", "label": "LOW - limited scope, easily reversible" }
      ]
    },
    {
      "id": "rfc_urgency",
      "prompt": "Is there a due date or urgency?",
      "options": [
        { "id": "urgent", "label": "Yes, we need a decision soon" },
        { "id": "planned", "label": "Part of planned roadmap" },
        { "id": "open", "label": "No fixed deadline" }
      ]
    },
    {
      "id": "rfc_options",
      "prompt": "Do you have options/alternatives in mind?",
      "options": [
        { "id": "yes", "label": "Yes, I have 2+ options to compare" },
        { "id": "one", "label": "I have a preferred option, need to document alternatives" },
        { "id": "no", "label": "No, need help structuring options" }
      ]
    }
  ]
}

ステップ 2：必須項目を確認する

必須項目 — 不足している場合は質問してください：

• RFC のタイトル（明確で、行動を促すもの）
• 背景／状況（現状と、これが重要な理由）
• 提案者（提案者／決定責任者）
• 承認者（承認が必要な人）
• 影響レベル（HIGH／MEDIUM／LOW）
• 信頼度を含む、明示的な前提事項を 1 つ以上
• 選択肢を提示する前に示す、重み付けされた判断基準を 2 つ以上
• 検討した選択肢を 2 つ以上（該当する場合は「何もしない」を含む）
• 判断基準に結び付いた根拠を伴う、推奨する選択肢

不足している項目があれば、文書を作成する前に、ユーザーの言語で質問してください。

ステップ 3：RFC の種類を特定し、セクションを調整する

RFC の種類	追加で重視する項目
技術／アーキテクチャ	システムへの影響、移行手順、技術的リスク
プロセス／ワークフロー	チームへの影響、導入計画、プロセスが失敗した場合のロールバック
プロダクト／機能	ユーザーへの影響、指標、実施可否の判断基準
ベンダー／ツールの選定	コスト比較、ロックインのリスク、評価基準
ポリシー／コンプライアンス	規制要件、監査証跡、適用方法

ステップ 4：RFC 文書を作成する

以下のテンプレートに従って、RFC を Markdown で作成します。

ステップ 5：次のステップを提案する

作成後、次の内容を提案します。

RFC Created: "[Title]"

Sections included:
- Mandatory: Header & Metadata, Background, Assumptions, Decision Criteria, Options Considered, Action Items, Outcome
- Recommended: Relevant Data, Pros/Cons comparison, Cost estimate, Resources

Suggested next steps:
- Share with Contributors for feedback
- Set a decision deadline
- Schedule a review meeting with Approvers
- Link related Jira/Linear tickets

Would you like me to:
1. Add more options to compare?
2. Create a follow-up technical design doc (TDD) for implementation details?
3. Publish this to Confluence?

文書の構成

必須セクション

1. ヘッダーとメタデータ
2. 背景
3. 前提事項
4. 判断基準
5. 検討した選択肢（最低 2 つ）
6. アクション項目
7. 結果

推奨セクション

8. 関連データ — 指標、調査、根拠
9. 長所と短所（選択肢ごと）
10. 推定コスト（工数／複雑さ／金額）
11. リソース — リンク、参考資料、先行事例

---

セクションテンプレート

RFC ドキュメントを作成する際は、references/section-templates.md を読んでください。必須セクション 7 項目と推奨セクション 4 項目の計 11 セクションすべてについて、各フィールドの例と「不足している場合」のプロンプトを含む、完全な Markdown テンプレートが記載されています。

---

RFC の品質チェックリスト

最終版を作成する前に、次の項目を確認してください。

• タイトル：明確で、行動を促す具体的なタイトル（「データベースに関する RFC」のようなものではない）
• 影響度：根拠を添えて HIGH／MEDIUM／LOW で評価している
• 背景：現状、問題、今取り組む理由、何もしない場合のコストを説明している
• 前提条件：信頼度と無効になる条件を明示している
• 判断基準：選択肢を示す前に重み付けをして定義し、必須条件を特定している
• データ：変更の必要性を裏付ける証拠を少なくともいくつか提示している
• 選択肢：最低 2 つの選択肢がある（大きな変更では「何もしない」も含める）
• 選択肢の評価：長所と短所を個別に並べるだけでなく、判断基準に照らして評価している
• 長所／短所：特定の選択肢を売り込むのではなく、誠実に評価している
• コスト：各選択肢の作業量を見積もっている（概算でも可）
• RACI：担当者、承認者、協力者、情報共有先をすべて特定している
• アクション項目：決定後の具体的な次のステップを記載している
• 結論：決定時に記入するプレースホルダーとして残している

---

よくあるアンチパターンと回避方法

結論が決まっているのに RFC を装う

悪い例：

We should use Kubernetes. Here are some reasons. Option 2 is to not use Kubernetes (obviously wrong).

良い例：

Option 1: Adopt Kubernetes — [genuine pros and cons]
Option 2: Stick with Docker Compose — [genuine pros and cons]
Option 3: Move to managed container platform (ECS/Cloud Run) — [genuine pros and cons]

曖昧な背景

悪い例：

Our current deployment process has some issues.

良い例：

Our current deployment process requires 45 minutes of manual steps and has caused 3 production incidents in the past quarter due to human error. The team spends ~8 hours/week on deployment-related tasks.

「何もしない」という選択肢がない

大きな変更では、常に現状維持を選択肢として含めてください。そうすることで、本当に行動が必要なのかを正直に評価できます。

判断基準がない（または選択肢を示した後に判断基準を定義している）

悪い例：先に選択肢を提示し、その後に判断基準を列挙する方法です。特定の選択肢を正当化するために判断基準が選ばれたように見えます。

良い例：選択肢を列挙する前に、判断基準を重み付けして定義します。そのうえで、各選択肢を明示的に評価します。推奨案のセクションでは、どの判断基準が決定の根拠になったのかを示してください。

隠れた前提条件、または明示されていない前提条件

悪い例：

We'll migrate to the new system over 6 months.

良い例：

Assumption: The team has 2 engineers available for migration work in Q3.
Confidence: Medium. Invalidated if Q3 headcount changes.

明示されていない前提条件は、気づかれない時限爆弾になります。RFC の結論が 6 か月後に機能しなくなったとき、決定が誤りだったのか、隠れた前提条件が無効になったのか、誰にも判断できなくなります。

---

出力の概要形式

RFC の作成後：

RFC Created: "[Title]"

Impact: HIGH / MEDIUM / LOW
Status: NOT STARTED

Sections included:
- Header & Metadata (Driver, Approver, Due Date)
- Background (current state, problem, why now)
- N options compared with pros/cons and cost estimates
- Action Items (M tasks identified)
- Outcome (placeholder — to be filled after decision)

Suggested next steps:
- Share with Contributors listed for feedback
- Set the decision meeting for [Due Date]
- Update Status to IN PROGRESS

Would you like me to add anything else?

---

重要な注意事項

• RFC は決定のためのものであり、実装のためのものではありません — RFC の決定後、実装計画の TDD を作成してください
• 選択肢を誠実に示すことが重要です — 一方的な RFC は信頼を損ない、誤った決定につながります
• 「何もしない」も常に選択肢の一つです — 変更する価値が本当にあるのかを評価しやすくなります
• 結論セクションは決定後に記入します — 草案の段階ではプレースホルダーのままにしてください
• 言語の調整 — 常にユーザーの言語で記述してください
• ユーザーの状況を尊重する — ユーザーが豊富な背景情報を提供している場合は、それを活用してください。すでに提示された情報を質問しないでください
• 選択肢は簡潔に — 実装の詳細ではなく、判断要因に焦点を当ててください
• RFC は古くなります — すべてに日付を記入してください。背景情報のない決定は、後になって混乱を招きます

このスキルを呼び出すプロンプトの例

英語

• 「データベースを MySQL から PostgreSQL に移行する RFC を作成してください」
• 「モノリスからマイクロサービスへの移行を提案する RFC が必要です」
• 「オンコールのローテーション方針に関する Request for Comments を作成してください」
• 「セルフホスト版とマネージド版の Kafka を比較する RFC の草案を作成してください」
• 「新しいデザインシステムの採用承認を得たいです」

ポルトガル語

• 「データベースを移行するための RFC を作成してください」
• 「新しいツールの導入を提案する RFC が必要です」
• 「オンコール方針に関する Request for Comments を作成してください」
• 「クラウドプロバイダーを変更する決定を文書化したいです」

スペイン語

• 「インフラストラクチャをクラウドに移行する RFC を作成してください」
• 「デプロイプロセスの変更を提案する RFC が必要です」
• 「新しいフレームワークの採用に関する Request for Comments を作成してください」