/create-rfc

name: create-rfc
description: Creates structured Request for Comments (RFC) documents for proposing and deciding on significant changes. Use when the user says "write an RFC", "create a proposal", "I need to propose a change", "draft an RFC", "document a decision", or needs stakeholder alignment before making a major technical or process decision. Do NOT use for TDDs/implementation docs (use technical-design-doc-creator instead), README files, or general documentation.
license: CC-BY-4.0
metadata:
  author: Tech Leads Club - github.com/tech-leads-club
  version: '1.0.0'

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.

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

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 vs 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**.

Interactive Workflow

Step 1: Gather Context (if not provided)

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

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

**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.

Step 3: Detect RFC Type and Tailor Sections

| 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 |

Step 4: Generate RFC Document

Generate the RFC in Markdown following the templates below.

Step 5: Offer Next Steps

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?

Document Structure

Mandatory Sections

1. **Header & Metadata** 2. **Background** 3. **Assumptions** 4. **Decision Criteria** 5. **