Create Rfc

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

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

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. Options Considered (minimum 2) 6. Action Items 7. Outcome

Recommended Sections

8. Relevant Data — metrics, research, evidence 9. Pros and Cons (per option) 10. Estimated Cost (effort/complexity/monetary) 11. Resources — links, references, prior art

---

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

Before finalizing, verify:

• [ ] Title: Clear, action-oriented, specific (not "RFC about the database")
• [ ] Impact: Assessed as HIGH / MEDIUM / LOW with justification
• [ ] Background: Current state + problem + why now + cost of inaction
• [ ] Assumptions: Explicit, with confidence levels and invalidation triggers
• [ ] Decision Criteria: Defined before options, with weights; Must-haves identified
• [ ] Data: At least some evidence supporting the need for change
• [ ] Options: Minimum 2 options (including "do nothing" for significant changes)
• [ ] Options evaluated against criteria: Not just pros/cons in isolation
• [ ] Pros/Cons: Honest assessment, not just selling one option
• [ ] Cost: Effort estimate for each option (even if rough)
• [ ] RACI: Driver, Approver(s), Contributors, Informed all identified
• [ ] Action Items: Concrete next steps after the decision
• [ ] Outcome: Left as placeholder to be filled when decision is made

---

Common Anti-Patterns to Avoid

Predetermined Conclusion Disguised as 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]

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.

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.

---

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?

---

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

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"

Portuguese

• "Escreva um RFC para migrar nosso banco de dados"
• "Preciso de um RFC para propor a adoção de uma nova ferramenta"
• "Crie um Request for Comments sobre nossa política de on-call"
• "Quero documentar a decisão de trocar de provedor de cloud"

Spanish

• "Escribe un RFC para migrar nuestra infraestructura a la nube"
• "Necesito un RFC para proponer un cambio en el proceso de deploy"
• "Crea un Request for Comments sobre la adopción de un nuevo framework"

RFC Creator

A skill for AI coding agents that helps create structured Request for Comments (RFC) documents for proposing significant changes and driving stakeholder decisions.

What It Does

This skill guides AI agents to create well-structured RFCs that include:

• Mandatory sections: Background, Assumptions, Decision Criteria, Options Considered, Action Items, Outcome
• Recommended sections: Relevant Data, Pros/Cons comparison, Cost estimates, Resources
• RACI model: Driver, Approver, Contributors, Informed — clearly separating who decides from who advises

The skill automatically adapts to:

• RFC type: Technical/Architecture, Process/Workflow, Product/Feature, Vendor Selection, Policy/Compliance
• Context provided: If you give rich context, it generates immediately; if not, it asks targeted questions
• User's language: Automatically generates the RFC in the same language as your request (for example, English, Portuguese, or Spanish)

RFC vs TDD — Which One Do You Need?

When an RFC is approved, you often create a TDD next to plan the implementation.

How to Use

Basic Usage

Just ask the agent to write an RFC:

English:

Write an RFC for migrating our database from MySQL to PostgreSQL

Portuguese:

Escreva um RFC para migrar nosso banco de dados para PostgreSQL

Spanish:

Escribe un RFC para migrar nuestra base de datos a PostgreSQL

With Rich Context (faster — skips questions)

Write an RFC for replacing our current logging infrastructure with OpenTelemetry.
We have 3 options: self-hosted Grafana stack, Datadog, or Honeycomb.
Main concern is cost and vendor lock-in. Decision needs approval from @CTO and @SRE-Lead by end of Q1.

Interactive Workflow

If you provide minimal context, the skill will ask:

1. Topic & impact: What is being proposed and how broadly it affects systems/teams 2. Urgency: Whether there's a deadline or this is open-ended 3. Options: Whether you already have alternatives in mind or need help structuring them

Then it validates mandatory fields before generating the document.

Examples

Example 1: Vendor/Tool Selection

Your request:

Write an RFC comparing self-hosted Kafka vs Amazon MSK vs Confluent Cloud for our event streaming needs

What happens: 1. Agent asks for decision deadline and who approves 2. Agent identifies this as a Vendor Selection RFC → adds cost comparison and lock-in risk focus 3. Agent ensures Decision Criteria are defined before listing options 4. Agent generates RFC with comparison matrix across all three options

Result: An RFC with:

• Background (current event streaming setup and why it needs to change)
• Assumptions (e.g., "traffic will not exceed 50k events/sec in 12 months")
• Decision Criteria (cost, operational burden, vendor lock-in, team expertise — with weights)
• Options: Self-hosted Kafka / Amazon MSK / Confluent Cloud + "Do Nothing"
• Options Comparison Matrix
• Action Items (PoC timeline, security review, cost approval)
• Outcome (placeholder for the approved decision)

Example 2: Process Change

Your request:

I need an RFC to propose changing our on-call rotation from weekly to bi-weekly shifts

What happens: 1. Agent identifies this as a Process/Workflow RFC 2. Agent asks for data backing the proposal (e.g., burnout reports, incident patterns) 3. Agent generates RFC focused on team impact and adoption plan

Result: An RFC with:

• Background (current rotation pain points with data)
• Assumptions (e.g., "team size stays at 8 engineers")
• Decision Criteria (engineer wellbeing, response time SLA, coverage gaps)
• Options: Bi-weekly / Monthly / Tooling-assisted rotation + Do Nothing
• Action Items (pilot with one team, measure for 60 days)

Example 3: Architecture Decision

Your request:

Draft an RFC for moving from our monolith to microservices

What happens: 1. Agent identifies HIGH impact → ensures Approvers are named 2. Agent asks for data: What specific pain points does the monolith cause? 3. Agent enforces "Do Nothing" option to honestly assess the cost of not changing

Result: An RFC with:

• Background (scaling limits, deployment coupling, team velocity data)
• Assumptions (e.g., "we have budget for platform engineering investment in H2")
• Decision Criteria (scalability, team autonomy, time to market, operational complexity)
• Options: Full microservices / Modular monolith / Strangler fig pattern / Do Nothing
• Comparison Matrix (effort, risk, reversibility, team impact)

What the Agent Will Ask (if context is missing)

About the proposal:

• What are you proposing and why now?
• What happens if you don't make this decision?

About assumptions:

• What are you taking for granted for this proposal to work?
• What would need to be true for your preferred option to succeed?

About decision criteria:

• What matters most when choosing between options?
• Are there any hard requirements that would disqualify an option?
• How do you weigh speed vs cost vs risk?

About stakeholders:

• Who is driving this proposal?
• Who must approve before anything moves forward?
• Who should be consulted vs just kept informed?

About options:

• What alternatives did you consider?
• Have you thought about keeping the status quo?

The Generated RFC

Every RFC includes:

1. Header & Metadata — Impact (HIGH/MEDIUM/LOW), Status, Driver, Approver, Contributors, Informed, Due Date 2. Background — Current state, problem/opportunity, why now, cost of inaction 3. Assumptions — Explicit assumptions with confidence levels (High/Medium/Low) and invalidation triggers 4. Decision Criteria — Prioritized criteria with weights (Must-have / High / Medium / Low), defined before options 5. Options Considered — Each option with description, pros, cons, and effort/risk/cost estimate 6. Options Comparison Matrix — Side-by-side view across all options and criteria 7. Action Items — Concrete tasks with owners and due dates for after the decision 8. Outcome — Placeholder to be filled when the decision is made, including rationale and follow-up

Tips for Best Results

1. Name your approvers upfront

The most common reason RFCs stall is unclear ownership. Telling the agent who needs to approve avoids placeholder @TBD entries that nobody acts on.

Write an RFC for adopting a monorepo. Approver is @VP-Engineering, contributors are @Frontend-Lead and @Backend-Lead.

2. Bring data, even rough data

RFCs with quantified problems get approved faster. Even rough numbers help:

Our current CI pipeline takes ~45 minutes. We're spending roughly 20% of engineering time
waiting on builds. Write an RFC for switching to a faster CI provider.

3. List your options explicitly

If you already know the alternatives, name them. The agent won't invent bad options just to fill the template.

Write an RFC comparing GitHub Actions, CircleCI, and Buildkite for our CI needs.

4. State your constraints upfront

Write an RFC for our logging solution. Must be SOC 2 compliant. Budget is under $2k/month.
Team has no Kubernetes experience.

These become your Must-have Decision Criteria automatically.

5. Use your language

The skill detects your language automatically:

• English: "Write an RFC for..."
• Portuguese: "Escreva um RFC para..."
• Spanish: "Escribe un RFC para..."

Language Support

All section headers and content are automatically generated in the detected language.

What Makes This Skill Different

1. Decision Criteria Before Options

Most RFC templates list options first and criteria last — which makes it easy to pick criteria that justify the preferred option after the fact. This skill enforces criteria before options, which produces decisions that hold up to scrutiny.

2. Explicit Assumptions with Invalidation Triggers

Every assumption has a confidence level and a trigger that would invalidate it. This turns assumptions from invisible time bombs into tracked risks, and gives teams a clear signal for when to revisit a decision.

3. "Do Nothing" as a First-Class Option

The status quo is always an option. Including it honestly forces the team to articulate the true cost of inaction — and sometimes reveals the change isn't worth the effort.

4. RACI-based Stakeholder Model

Driver / Approver / Contributors / Informed separates "who decides" from "who advises" from "who is notified." This prevents both design-by-committee and decisions made without the right people in the room.

5. Lifecycle-Aware

The RFC tracks status (NOT STARTED → IN PROGRESS → COMPLETE) and the Outcome section is explicitly left as a placeholder during drafting — to be filled in after the Approvers decide. Decisions are dated and signed, creating an audit trail.

Common Use Cases

Good use cases for an RFC

• Adopting a new technology, framework, or vendor
• Changing a major architectural pattern (e.g., monolith → microservices)
• Proposing a new engineering process or policy
• Deprecating a system or API
• Making a build-vs-buy decision
• Resolving a significant technical disagreement across teams
• Proposing a budget change requiring leadership approval

Not ideal for an RFC

• Implementing something already decided (use a TDD instead)
• Bug fixes or minor code changes
• One-team decisions with a single approver and low impact
• Exploratory spikes (document findings in a separate write-up first)

Output Example Structure

# RFC: Adopt OpenTelemetry for Distributed Tracing

| Field        | Value                        |
|--------------|------------------------------|
| Impact       | HIGH                         |
| Status       | IN PROGRESS                  |
| Driver       | @platform-lead               |
| Approver     | @vp-engineering, @sre-lead   |
| Contributors | @backend-lead, @frontend-lead|
| Informed     | @engineering-all             |
| Due Date     | 2026-04-15                   |

## Background
[Current observability gaps, cost of incidents without tracing...]

## Assumptions
| # | Assumption | Confidence | Invalidation Trigger |
|---|------------|------------|----------------------|
| 1 | Team can dedicate 2 sprints to migration | Medium | If Q2 roadmap changes |

## Decision Criteria
| Priority | Criterion        | Weight    |
|----------|-----------------|-----------|
| 1        | Vendor-neutral  | Must-have |
| 2        | Cost < $3k/mo   | High      |
| 3        | Team familiarity| Medium    |

## Options Considered
### Option 1: OpenTelemetry + Grafana Tempo ⭐ (Recommended)
### Option 2: Datadog APM
### Option 3: Do Nothing

## Options Comparison
[Matrix across all options and criteria]

## Action Items
[Tasks with owners and due dates]

## Outcome
[To be filled after decision]

Troubleshooting

The agent keeps asking questions

This is by design — the skill won't generate a shallow RFC. Answer the questions to get a document that will hold up in a stakeholder review. If you want to skip ahead, provide the missing information directly:

Driver is @me, Approver is @cto. Assumptions: team has capacity in Q2.
Decision criteria: cost first, then operational simplicity.

I want fewer options

Two options are the minimum — one is not a choice, it's an announcement. If you only see one viable path, make the second option "Do Nothing" and argue honestly why it's worse.

The RFC is too long

Specify the scope upfront:

Write a concise RFC for a LOW impact decision — just Background, two options, and Action Items.

I need to update a decision that was made

RFCs are historical records. Instead of editing the Outcome of a past RFC, write a new RFC that references the original and proposes a change. This preserves the audit trail.

Next Steps After Creating an RFC

1. Share with Contributors for feedback (set a comment deadline) 2. Present to Approvers in a review meeting 3. Record the decision in the Outcome section with rationale 4. Notify Informed parties of the decision 5. Create a TDD if the approved option requires implementation planning 6. Archive the RFC where the team can find it later (Confluence, Notion, GitHub)

Support

For issues or questions about this skill, refer to the main agent-skills repository.

RFC Section Templates

Complete Markdown templates for each RFC section. Read this file when generating an RFC document.

---

1. Header & Metadata (MANDATORY)

# RFC: [Clear, Action-Oriented Title]

| Field        | Value                              |
|--------------|------------------------------------|
| **Impact**   | HIGH / MEDIUM / LOW                |
| **Status**   | NOT STARTED / IN PROGRESS / COMPLETE |
| **Driver**   | @Name — responsible for the proposal |
| **Approver** | @Name1, @Name2 — must approve before action |
| **Contributors** | @Name3, @Name4 — provide input   |
| **Informed** | @Team, @Stakeholder — kept in the loop |
| **Due Date** | YYYY-MM-DD (or "TBD")              |
| **Resources** | [Link to Jira], [Link to design], [Related RFC] |
| **Created**  | YYYY-MM-DD                         |
| **Last Updated** | YYYY-MM-DD                     |

RACI Guidance:

• Driver: Owns the proposal, drives the process, implements the outcome
• Approver: Decision-maker(s) — must explicitly approve or reject
• Contributors: Provide expertise, review options, raise concerns
• Informed: Notified of the decision but don't need to act

If missing: Ask "Who is driving this proposal? Who needs to approve the final decision? Who should be consulted?"

---

2. Background (MANDATORY)

## Background

[2-4 paragraphs describing the current state and why a decision is needed]

**Current State**:
What exists today? What system, process, or situation does this RFC address?

**Problem or Opportunity**:
What is the specific pain point, risk, or opportunity driving this RFC?
Include data or evidence where possible (e.g., "we're spending 10h/week on X" or "incident rate has doubled").

**Why Now**:
What makes this decision urgent or timely?
- Business driver (deadline, market change, regulatory requirement)
- Technical driver (scaling limit, security risk, accumulating debt)
- Team driver (onboarding friction, process inefficiency)

**What Happens If We Don't Decide**:
- [Consequence 1 — e.g., continued cost, growing risk]
- [Consequence 2 — e.g., missed opportunity]

If unclear: Ask "What is the current situation? Why is this decision needed now? What happens if we do nothing?"

---

3. Assumptions (MANDATORY)

## Assumptions

[Explicit statements taken as true for this proposal to hold. If any assumption proves false, this RFC should be revisited.]

| # | Assumption | Owner | Confidence | Invalidation Trigger |
|---|------------|-------|------------|----------------------|
| 1 | [e.g., "Current traffic will not exceed 10k req/s in the next 12 months"] | @Name | High | If traffic projections change |
| 2 | [e.g., "The team has capacity to implement this in Q2"] | @Name | Medium | If Q2 roadmap changes |
| 3 | [e.g., "Vendor X's pricing remains stable"] | @Name | Low | If pricing changes >20% |

**Confidence levels**:
- **High** — backed by data or contractual guarantees
- **Medium** — reasonable expectation, but not verified
- **Low** — uncertain; decision may need revisiting if this assumption shifts

**If any assumption is invalidated**: The Driver is responsible for reassessing the RFC outcome and communicating changes to Approvers and Informed parties.

If missing: Ask "What are you taking for granted for this proposal to work? What would need to be true for the recommended option to succeed?"

---

4. Decision Criteria (MANDATORY)

## Decision Criteria

[State how the decision will be made — before listing options. This prevents criteria from being chosen retroactively to justify a preferred option.]

The option chosen must best satisfy the following criteria, listed in order of priority:

| Priority | Criterion | Description | Weight |
|----------|-----------|-------------|--------|
| 1 | [e.g., Security compliance] | Must meet SOC 2 / GDPR requirements | Must-have |
| 2 | [e.g., Time to production] | Decision should enable delivery within Q2 | High |
| 3 | [e.g., Total cost of ownership] | Prefer lower long-term cost over short-term savings | High |
| 4 | [e.g., Team expertise] | Prefer technologies the team already knows | Medium |
| 5 | [e.g., Reversibility] | Prefer options that are easier to undo if wrong | Medium |
| 6 | [e.g., Vendor lock-in] | Avoid deep dependence on a single vendor | Low |

**Weight guidance**:
- **Must-have**: Non-negotiable. An option that fails this criterion is disqualified.
- **High**: Strong influence on the decision.
- **Medium**: Considered, but can be traded off.
- **Low**: Nice to have; tiebreaker only.

**Decision rule**: The recommended option is the one that satisfies all Must-haves and scores highest across High and Medium criteria. Explicitly call out trade-offs when no option wins on all criteria.

If missing: Ask "What matters most when choosing between options? Are there any hard requirements that would disqualify an option? How will you weigh speed vs cost vs risk?"

---

5. Relevant Data (RECOMMENDED)

## Relevant Data

[Evidence, metrics, or research that informs the decision]

**Quantitative Data**:
- Current cost/time: [e.g., "$X/month", "Y hours/week"]
- Usage/adoption: [e.g., "Z% of users affected"]
- Frequency: [e.g., "N incidents per quarter"]

**Qualitative Data**:
- User/team feedback: [summary of pain points or requests]
- Prior attempts: [what was tried before, why it didn't work]

**External References**:
- Industry benchmarks or standards
- Vendor documentation or case studies
- Research papers or technical articles

---

6. Options Considered (MANDATORY — minimum 2)

For each option, use this template. Evaluate against the Decision Criteria defined above.

## Options Considered

### Option 1: [Option Name] ⭐ (Recommended)

**Description**:
[Clear description of this approach in 1-3 paragraphs]

**How It Works**:
1. Step or component A
2. Step or component B
3. Step or component C

**Pros**:
- [Advantage 1 — be specific]
- [Advantage 2]
- [Advantage 3]

**Cons**:
- [Disadvantage 1 — be honest]
- [Disadvantage 2]

**Estimated Cost**: LARGE / MEDIUM / SMALL
- Effort: [X weeks / person-days]
- Financial: [$X/month] (if applicable)
- Risk: HIGH / MEDIUM / LOW

---

### Option 2: [Option Name]

**Description**:
[Clear description of this approach]

**How It Works**:
1. Step or component A
2. Step or component B

**Pros**:
- [Advantage 1]
- [Advantage 2]

**Cons**:
- [Disadvantage 1]
- [Disadvantage 2]

**Estimated Cost**: LARGE / MEDIUM / SMALL
- Effort: [X weeks / person-days]
- Financial: [$X/month] (if applicable)
- Risk: HIGH / MEDIUM / LOW

---

### Option 3: Do Nothing (always consider)

**Description**:
Maintain the status quo and accept the current situation.

**Pros**:
- No immediate cost or disruption
- No migration risk

**Cons**:
- [Consequence of inaction 1]
- [Consequence of inaction 2]

**Estimated Cost**: SMALL (upfront) / potentially LARGE (long-term)

Option Comparison Matrix (for 3+ options):

## Options Comparison

| Criterion              | Option 1 | Option 2 | Option 3 |
|------------------------|----------|----------|----------|
| Implementation effort  | Medium   | Low      | None     |
| Cost                   | $X/mo    | $Y/mo    | $Z/mo    |
| Time to value          | 4 weeks  | 1 week   | N/A      |
| Risk                   | Low      | Medium   | High     |
| Reversibility          | Easy     | Hard     | N/A      |
| Team impact            | Minimal  | Moderate | None     |

**Recommended**: Option 1 because [brief rationale]

---

7. Action Items (MANDATORY)

## Action Items

[What happens after the decision is made — tasks required to implement the chosen option]

| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [Task 1 — e.g., "Evaluate vendor X with a PoC"] | @Name | YYYY-MM-DD | NOT STARTED |
| [Task 2 — e.g., "Update runbook for new process"] | @Name | YYYY-MM-DD | NOT STARTED |
| [Task 3 — e.g., "Communicate decision to affected teams"] | @Name | YYYY-MM-DD | NOT STARTED |
| [Task 4 — e.g., "Create follow-up TDD for implementation"] | @Name | YYYY-MM-DD | NOT STARTED |

**Note**: If this RFC is approved, a Technical Design Document (TDD) may be needed to plan the implementation in detail.

---

8. Outcome (MANDATORY — filled after decision)

## Outcome

**Decision**: [Option X was chosen / RFC was rejected / deferred]

**Decision Date**: YYYY-MM-DD

**Decided By**: @Approver1, @Approver2

**Rationale**:
[Why this option was chosen over the alternatives. Be specific — future readers need to understand the reasoning, especially if circumstances change.]

**Key Factors**:
- [Factor 1 that drove the decision]
- [Factor 2]
- [Factor 3]

**Conditions / Caveats** (if any):
- [e.g., "Approved for Q1 only, will be revisited in Q2"]
- [e.g., "Requires security review before implementation"]

**Follow-up**:
- [ ] Create TDD for implementation (if applicable)
- [ ] Update affected documentation
- [ ] Notify informed stakeholders of decision
- [ ] Schedule retrospective in [X months] to evaluate outcome