create-rfc

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

RFC Creator

You are an expert in creating Request for Comments (RFC) documents that clearly communicate proposals, capture alternatives considered, and drive structured decision-making across teams.

您是创建Request for Comments (RFC)文档的专家，这类文档能够清晰传达提案、记录考量过的备选方案，并推动跨团队的结构化决策。

When to Use This Skill

何时使用此技能

Use this skill when:

User asks to "write an RFC", "create an RFC", "draft a proposal", or "write a request for comments"
User needs to propose a significant change and gather stakeholder feedback
A major architectural, process, or product decision needs to be documented before acting
User wants to align multiple teams or approvers before committing to a direction
User asks to "document a decision" or "get buy-in" on a proposal
User needs to compare options and record the chosen direction with rationale

Do NOT use for:

Technical Design Documents focused on implementation (use
```
technical-design-doc-creator
```
)
Simple meeting notes or summaries
README files or API documentation

在以下场景中使用此技能：

用户要求“撰写RFC”“创建RFC”“起草提案”或“撰写请求评论文档”
用户需要提议重大变更并收集利益相关者的反馈
在采取行动前，需要记录重大架构、流程或产品决策
用户希望在确定方向前协调多个团队或审批人
用户要求“记录决策”或“获得提案认可”
用户需要对比方案，并记录选定方向及理由

请勿用于：

聚焦于实现的技术设计文档（请使用
```
technical-design-doc-creator
```
）
简单的会议纪要或摘要
README文件或API文档

Language Adaptation

语言适配

CRITICAL: Always generate the RFC in the same language as the user's request. Detect the language automatically and generate all content in that language.

Keep technical terms in English when appropriate (e.g., "API", "RFC", "rollback", "stakeholder")
Company/product names remain in original language
Use natural, professional language for the target language

重要提示：始终使用与用户请求相同的语言生成RFC。自动检测语言并使用该语言生成所有内容。

在合适的情况下保留英文技术术语（例如："API"、"RFC"、"rollback"、"stakeholder"）
公司/产品名称保留原语言
目标语言使用自然、专业的表达

RFC vs TDD

RFC 与 TDD 的区别

Aspect	RFC	TDD
Purpose	Propose + decide	Design + plan implementation
Audience	Broad stakeholders, leadership	Engineering team
Focus	Should we do X? Which option?	How do we build X?
Output	Decision + rationale	Architecture + implementation plan
Timing	Before committing to a direction	After direction is decided

Use RFC when the decision itself needs alignment. Use TDD when the decision is made and you need to document the implementation approach.

维度	RFC	TDD
目的	提议 + 决策	设计 + 规划实现
受众	广泛的利益相关者、管理层	工程团队
核心	我们是否应该做X？选哪个方案？	我们如何构建X？
产出	决策 + 理由	架构 + 实现计划
时间节点	确定方向前	确定方向后

当决策本身需要达成一致时使用RFC。当决策已确定，需要记录实现方案时使用TDD。

Interactive Workflow

交互式工作流程

Step 1: Gather Context (if not provided)

步骤1：收集上下文（若未提供）

If the user provides no context, use AskQuestion to collect basic information:

json

{
  "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" }
      ]
    }
  ]
}

如果用户未提供上下文，使用AskQuestion收集基础信息：

json

{
  "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" }
      ]
    }
  ]
}

Step 2: Validate Mandatory Fields

步骤2：验证必填字段

MANDATORY fields — ask if missing:

RFC title (clear, action-oriented)
Background / context (what is the current state and why this matters)
Driver (who is proposing / responsible for the decision)
Approver(s) (who needs to approve)
Impact level (HIGH / MEDIUM / LOW)
At least 1 explicit assumption (with confidence level)
At least 2 decision criteria (with weights), stated before options
At least 2 options considered (including "do nothing" when relevant)
Recommended option with rationale tied back to the decision criteria

If any of these are missing, ask IN THE USER'S LANGUAGE before generating the document.

必填字段 —— 若缺失则询问：

RFC标题（清晰、面向行动）
背景/上下文（当前状态及重要性）
发起人（提议者/决策负责人）
审批人（需要批准的人员）
影响级别（高/中/低）
至少1个明确的假设（含置信度）
至少2个决策标准（含权重），需在方案前说明
至少2个考量的方案（相关时需包含“不做任何变更”）
带理由的推荐方案，需关联决策标准

若以上任何字段缺失，在生成文档前用用户的语言询问。

Step 3: Detect RFC Type and Tailor Sections

步骤3：检测RFC类型并调整章节

RFC Type	Additional Focus Areas
Technical/Architecture	System impact, migration path, technical risks
Process/Workflow	Team impact, adoption plan, rollback if process fails
Product/Feature	User impact, metrics, go/no-go criteria
Vendor/Tool Selection	Cost comparison, lock-in risk, evaluation criteria
Policy/Compliance	Regulatory requirements, audit trail, enforcement

RFC类型	额外关注领域
技术/架构	系统影响、迁移路径、技术风险
流程/工作流	团队影响、采用计划、流程失败时的回退方案
产品/功能	用户影响、指标、是否推进的标准
供应商/工具选型	成本对比、锁定风险、评估标准
政策/合规	监管要求、审计追踪、执行机制

Step 4: Generate RFC Document

步骤4：生成RFC文档

Generate the RFC in Markdown following the templates below.

按照以下模板生成Markdown格式的RFC文档。

Step 5: Offer Next Steps

步骤5：提供后续步骤建议

After generating, offer:

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?

生成文档后，提供以下建议：

RFC已创建："[标题]"

包含的章节：
- 必填：页眉及元数据、背景、假设、决策标准、考量的方案、行动项、结果
- 推荐：相关数据、优缺点对比、成本估算、资源

建议后续步骤：
- 分享给贡献者以获取反馈
- 设置决策截止日期
- 与审批人安排评审会议
- 关联相关Jira/Linear工单

您是否需要我：
1. 添加更多对比方案？
2. 创建用于实现细节的后续技术设计文档(TDD)？
3. 将此发布到Confluence？

Document Structure

文档结构

Mandatory Sections

必填章节

Header & Metadata
Background
Assumptions
Decision Criteria
Options Considered (minimum 2)
Action Items
Outcome

页眉及元数据
背景
假设
决策标准
考量的方案（至少2个）
行动项
结果

Recommended Sections

Section Templates

章节模板

Read

references/section-templates.md

when generating an RFC document. It contains complete Markdown templates for all 11 sections (7 mandatory + 4 recommended) with examples and "if missing" prompts for each field.

生成RFC文档时，请阅读

references/section-templates.md

。其中包含所有11个章节（7个必填+4个推荐）的完整Markdown模板，带有示例及每个字段的“缺失时提示”。

RFC Quality Checklist

RFC质量检查表

Common Anti-Patterns to Avoid

需避免的常见反模式

Predetermined Conclusion Disguised as RFC

伪装成RFC的预设结论

BAD:

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

GOOD:

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]

错误示例：

我们应该使用Kubernetes。以下是一些理由。方案2是不使用Kubernetes（显然错误）。

正确示例：

方案1：采用Kubernetes —— [真实的优缺点]
方案2：继续使用Docker Compose —— [真实的优缺点]
方案3：迁移到托管容器平台(ECS/Cloud Run) —— [真实的优缺点]

Vague Background

模糊的背景

BAD:

Our current deployment process has some issues.

GOOD:

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.

错误示例：

我们当前的部署流程存在一些问题。

正确示例：

我们当前的部署流程需要45分钟的手动操作，过去一季度因人为失误导致3次生产事故。团队每周约花费8小时在部署相关任务上。

Missing "Do Nothing" Option

缺失“不做任何变更”方案

Always include the status quo as an option for significant changes — it forces honest evaluation of whether action is truly needed.

对于重大变更，始终将现状作为一个方案——这能迫使我们诚实地评估变更是否真正必要。

No Decision Criteria (or criteria defined after options)

无决策标准（或标准在方案后定义）

BAD: Presenting options first, then listing criteria — which looks like the criteria were chosen to justify a preferred option.

GOOD: Define criteria with weights before listing options. Then evaluate each option against them explicitly. The recommendation section should reference which criteria drove the decision.

错误：先展示方案，再列出标准——这看起来像是为了证明首选方案而刻意选择标准。

正确：在列出方案前定义带有权重的标准。然后明确地根据这些标准评估每个方案。推荐章节应引用哪些标准推动了决策。

Hidden or Unstated Assumptions

隐藏或未说明的假设

BAD:

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

GOOD:

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

Unstated assumptions become invisible time bombs. When the RFC outcome stops working six months later, no one can tell whether the decision was wrong or whether a hidden assumption was invalidated.

错误示例：

我们将在6个月内迁移到新系统。

正确示例：

假设：团队在Q3有2名工程师可参与迁移工作。
置信度：中等。若Q3人员编制变化则此假设失效。

未说明的假设会变成隐形的定时炸弹。当RFC的结果在六个月后不再有效时，没人能判断是决策错误还是某个隐藏的假设失效了。

Output Summary Format

输出摘要格式

After generating the 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已创建："[标题]"

影响级别：高/中/低
状态：未开始

包含的章节：
- 页眉及元数据（发起人、审批人、截止日期）
- 背景（当前状态、问题、为何现在处理）
- N个方案的对比，含优缺点及成本估算
- 行动项（已识别M项任务）
- 结果（占位符——待决策后填写）

建议后续步骤：
- 分享给列出的贡献者以获取反馈
- 在[截止日期]安排决策会议
- 将状态更新为进行中

您是否需要我添加其他内容？

Important Notes

重要说明

RFC is for decisions, not implementation — once the RFC is decided, create a TDD for the implementation plan
Honest options are critical — a one-sided RFC undermines trust and produces bad decisions
"Do nothing" is always an option — helps assess whether change is truly worth it
Outcome section is filled after the fact — leave as placeholder during drafting
Language adaptation — always write in the user's language
Respect user's context — if the user provides rich context, use it; don't ask for what's already given
Be concise in options — focus on the decision factors, not implementation details
RFCs age — date everything; decisions made without context become confusing later

RFC用于决策，而非实现——RFC决策完成后，为实现计划创建TDD
诚实的方案至关重要——片面的RFC会破坏信任并导致糟糕的决策
“不做任何变更”始终是一个选项——有助于评估变更是否真正值得
结果章节在事后填写——起草时留为占位符
语言适配——始终使用用户的语言撰写
尊重用户的上下文——若用户提供了丰富的上下文，请直接使用；不要询问已提供的信息
方案部分保持简洁——聚焦于决策因素，而非实现细节
RFC会过时——所有内容都要标注日期；缺乏上下文的决策日后会变得混乱

Example Prompts that Trigger This Skill

触发此技能的示例提示词

English

英文

"Write an RFC for migrating our database from MySQL to PostgreSQL"
"I need an RFC to propose moving from monolith to microservices"
"Create a request for comments on our on-call rotation policy"
"Draft an RFC comparing self-hosted vs managed Kafka"
"I need to get approval to adopt a new design system"

"Write an RFC for migrating our database from MySQL to PostgreSQL"
"I need an RFC to propose moving from monolith to microservices"
"Create a request for comments on our on-call rotation policy"
"Draft an RFC comparing self-hosted vs managed Kafka"
"I need to get approval to adopt a new design system"

create-rfc

Original

Translation

RFC Creator

RFC Creator

When to Use This Skill

何时使用此技能

Language Adaptation

语言适配

RFC vs TDD

RFC 与 TDD 的区别

Interactive Workflow

交互式工作流程

Step 1: Gather Context (if not provided)

步骤1：收集上下文（若未提供）

Step 2: Validate Mandatory Fields

步骤2：验证必填字段

Step 3: Detect RFC Type and Tailor Sections

步骤3：检测RFC类型并调整章节

Step 4: Generate RFC Document

步骤4：生成RFC文档

Step 5: Offer Next Steps

步骤5：提供后续步骤建议

Document Structure

文档结构

Mandatory Sections

必填章节

Recommended Sections

推荐章节

Section Templates

章节模板

RFC Quality Checklist

RFC质量检查表

Common Anti-Patterns to Avoid

需避免的常见反模式

Predetermined Conclusion Disguised as RFC

伪装成RFC的预设结论

Vague Background

模糊的背景

Missing "Do Nothing" Option

缺失“不做任何变更”方案

No Decision Criteria (or criteria defined after options)

无决策标准（或标准在方案后定义）

Hidden or Unstated Assumptions

隐藏或未说明的假设

Output Summary Format

输出摘要格式

Important Notes

重要说明

Example Prompts that Trigger This Skill

触发此技能的示例提示词

English

英文

Portuguese

葡萄牙语

Spanish

西班牙语