Stats
Actions
Tags
Facilitates Request for Comments (RFC) process for technical proposals and design decisions. Supplies templates, ADR comparisons, best practices, and IETF-adapted guidance.
How this skill is triggered — by the user, by Claude, or both
Slash command
/documentation-standards:rfc-processThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill when:
Use this skill when:
Facilitate the Request for Comments (RFC) process for technical proposals and design decisions.
Before creating RFCs:
docs-management skill for RFC patternsRFC 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-[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 does NOT address]
- [Non-goal 2]
---
## Proposal
### Overview
[High-level description of the proposed solution]
### Detailed Design
[In-depth technical description. Include:
- Architecture changes
- API changes
- Data model changes
- Algorithm descriptions
- Integration points]
### Example Usage
```csharp
// Code example showing how the proposal would be used
public class ExampleUsage
{
public async Task Example()
{
// Demonstrate the proposed API or pattern
}
}
[How will existing systems/data be migrated?]
Description: [What this alternative entails]
Pros:
Cons:
Why Not Chosen: [Reason for rejecting this alternative]
[Same structure...]
Description: Continue with current approach
Pros:
Cons:
| Trade-off | Chosen Path | Alternative Path |
|---|---|---|
| [Trade-off 1] | [What we accept] | [What we give up] |
| [Trade-off 2] | [What we accept] | [What we give up] |
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | Low/Medium/High | Low/Medium/High | [Mitigation strategy] |
| [Risk 2] | Low/Medium/High | Low/Medium/High | [Mitigation strategy] |
| Phase | Description | Duration | Dependencies |
|---|---|---|---|
| Phase 1 | [Description] | [Duration] | [Dependencies] |
| Phase 2 | [Description] | [Duration] | [Dependencies] |
[How to revert if the implementation fails]
[Security implications of this proposal]
[Privacy implications of this proposal]
[How will this be tested?]
[What documentation needs to be created or updated?]
[Questions that need to be resolved during the comment period]
[Space for discussion - may link to external discussion thread]
| Date | Author | Comment | Resolution |
|---|---|---|---|
| [Date] | [Name] | [Comment] | [Resolution] |
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | [Date] | [Name] | Initial draft |
| 0.2 | [Date] | [Name] | [Changes made] |
RFC Status Flow:
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌─────────────────┐ ┌──────────────────┐ │
│ │ Draft │────▶│ Open for Comment │────▶│ Final Comment │ │
│ └──────────┘ └─────────────────┘ └──────────────────┘ │
│ │ │ │ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Withdrawn│ │ Withdrawn│ │ Accepted │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │
│ ┌──────────┐ │ │
│ │ Rejected │◀───────────┤ │
│ └──────────┘ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Implemented │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Timeline:
• Draft: Author preparing, not ready for review
• Open for Comment: 2 weeks minimum for feedback
• Final Comment: 1 week for last objections
• Accepted/Rejected: Decision made
• Implemented: Work completed
| Situation | RFC Needed? |
|---|---|
| New microservice | Yes |
| Change in data model | Yes |
| New public API | Yes |
| Internal refactoring | Maybe |
| Bug fix | No |
| Minor enhancement | No |
| Breaking change | Yes |
| New technology adoption | Yes |
| Deprecation | Yes |
| Role | Responsibility |
|---|---|
| Author | Writes RFC, addresses feedback, drives to decision |
| Reviewer | Provides technical feedback |
| Stakeholder | Represents affected team or system |
| Approver | Makes final accept/reject decision |
| Editor | Ensures RFC meets standards (optional) |
For smaller proposals, use this abbreviated format:
# Design Doc: [TITLE]
**Author:** [Name]
**Date:** [Date]
**Status:** [Draft/Review/Approved]
## Context
[What problem are we solving?]
## Proposal
[What are we going to do?]
## Alternatives
[What else did we consider?]
## Decision
[What did we decide and why?]
# RFC Registry
## Active RFCs
| RFC | Title | Author | Status | Target Date |
|-----|-------|--------|--------|-------------|
| RFC-012 | [Title] | [Author] | Open for Comment | 2025-02-15 |
| RFC-013 | [Title] | [Author] | Draft | - |
## Accepted RFCs
| RFC | Title | Accepted | ADR |
|-----|-------|----------|-----|
| RFC-010 | [Title] | 2025-01-10 | ADR-025 |
| RFC-011 | [Title] | 2025-01-15 | ADR-026 |
## Rejected/Withdrawn RFCs
| RFC | Title | Status | Reason |
|-----|-------|--------|--------|
| RFC-008 | [Title] | Rejected | [Brief reason] |
| RFC-009 | [Title] | Withdrawn | [Brief reason] |
When creating RFCs:
For detailed guidance:
Last Updated: 2025-12-26
npx claudepluginhub melodic-software/claude-code-plugins --plugin documentation-standardsGuides writing RFCs for features, architecture, processes, deprecations, migrations, and standards with workflow: type selection, git research, required sections (summary, problem, solution, alternatives, risks), review management, decision logging, and git commit to docs/rfcs/. Use for proposals needing team buy-in on large changes.
Structure Request for Comments processes to document major technical decisions, surface concerns, and build consensus. Use before implementing significant architectural changes.
Produces a complete engineering RFC document covering problem statement, proposed solution, alternatives, implementation plan, migration, security, performance, observability, and rollout.