Request for Comments (RFC) process for technical proposals
Creates RFCs for technical proposals using IETF-style templates. Use when proposing significant changes that require team consensus and discussion before implementation.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install documentation-standards@melodic-softwareThis skill is limited to using the following tools:
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
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.