Facilitates Request for Comments (RFC) process for technical proposals and design decisions. Supplies templates, ADR comparisons, best practices, and IETF-adapted guidance.
npx claudepluginhub melodic-software/claude-code-plugins --plugin documentation-standardsThis skill is limited to using the following tools:
Use this skill when:
Guides 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.
Share bugs, ideas, or general feedback.
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