rfc-process

# RFC Process Skill

## When to Use This Skill

Use this skill when:

- **Rfc Process tasks** - Working on request for comments (rfc) process for technical proposals
- **Planning or design** - Need guidance on Rfc Process approaches
- **Best practices** - Want to follow established patterns and standards

## Overview

Facilitate the Request for Comments (RFC) process for technical proposals and design decisions.

## MANDATORY: Documentation-First Approach

Before creating RFCs:

1. **Invoke `docs-management` skill** for RFC patterns
2. **Verify RFC best practices** via MCP servers (perplexity)
3. **Base guidance on IETF RFC style adapted for software teams**

## RFC vs ADR

```text
RFC vs ADR Comparison:

RFC (Request for Comments):
• For proposals BEFORE decision is made
• Invites discussion and feedback
• May be accepted, rejected, or revised
• Typically larger scope than ADRs
• Used for significant changes requiring consensus

ADR (Architecture Decision Record):
• Documents decisions AFTER they are made
• Records the decision and rationale
• Immutable once accepted
• Focused on single decisions
• Used for all significant architecture decisions

Relationship:
RFC (Proposal) → Discussion → Decision → ADR (Record)
```

## RFC Template

```markdown
# RFC-[NUMBER]: [TITLE]

| Property | Value |
|----------|-------|
| **RFC Number** | RFC-[NUMBER] |
| **Title** | [Short, descriptive title] |
| **Author(s)** | [Name(s)] |
| **Status** | [Draft \| Open for Comment \| Final Comment \| Accepted \| Rejected \| Withdrawn] |
| **Created** | [YYYY-MM-DD] |
| **Updated** | [YYYY-MM-DD] |
| **Target Decision Date** | [YYYY-MM-DD] |
| **Stakeholders** | [Teams/Individuals] |

---

## Summary

[One paragraph executive summary. What is being proposed and why?]

---

## Motivation

### Problem Statement

[What problem does this RFC solve? Why is the current situation inadequate?]

### Goals

- [Goal 1]
- [Goal 2]
- [Goal 3]

### Non-Goals

- [Non-goal 1: What this RFC explicitly doe