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.
Use this skill when:
Do NOT use for:
technical-design-doc-creator)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.
| Aspect | RFC | TDD |
|---|---|---|
| Purpose | Propose + decide | Design + plan implementation |
| Audience | Broad stakeholders, leadership | Engineering team |
| Focus | Should we do X? Which option? | How do we build X? |
| Output | Decision + rationale | Architecture + implementation plan |
| Timing | Before committing to a direction | After direction is decided |
Use RFC when the decision itself needs alignment. Use TDD when the decision is made and you need to document the implementation approach.
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" }
]
}
]
}
MANDATORY fields — ask if missing:
If any of these are missing, ask IN THE USER'S LANGUAGE before generating the document.
| RFC Type | Additional Focus Areas |
|---|---|
| Technical/Architecture | System impact, migration path, technical risks |
| Process/Workflow | Team impact, adoption plan, rollback if process fails |
| Product/Feature | User impact, metrics, go/no-go criteria |
| Vendor/Tool Selection | Cost comparison, lock-in risk, evaluation criteria |
| Policy/Compliance | Regulatory requirements, audit trail, enforcement |
Generate the RFC in Markdown following the templates below.
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?
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.
Before finalizing, verify:
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]
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.
Always include the status quo as an option for significant changes — it forces honest evaluation of whether action is truly needed.
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.
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.
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?