Create and manage Requests for Comments (RFCs) — structured proposals committed to the repo that open a decision for discussion before committing to an approach. Use this skill when the user wants to write an RFC, propose a significant change for review, open a design discussion, or draft a technical proposal. Also activate when the user says things like "I want to propose", "we need to discuss before deciding", "let's get feedback on this approach", "write up a proposal", "request for comments", "design proposal", "technical proposal", or "I want input from the team on". PROACTIVELY suggest an RFC when the user is debating a large change that affects multiple consumers, teams, or system boundaries — especially migrations, breaking API changes, new system architecture, or choosing between competing approaches where structured discussion would help. Do NOT use for: decisions already made (use /adr instead), small choices that don't need group input, general documentation, or post-mortems.
How this skill is triggered — by the user, by Claude, or both
Slash command
/architecture-decisions:rfcThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create structured proposals that open a significant decision for discussion before the team commits to an approach. RFCs live in the repo alongside ADRs so the full decision lifecycle — proposal, debate, outcome — is captured in version control.
Create structured proposals that open a significant decision for discussion before the team commits to an approach. RFCs live in the repo alongside ADRs so the full decision lifecycle — proposal, debate, outcome — is captured in version control.
An RFC answers: "Here's a problem, here's what I think we should do about it, and here's what I want your input on."
When the RFC concludes, it should be converted to an ADR (use /adr) to record the final decision. Both documents are kept — the RFC preserves the reasoning and alternatives explored; the ADR is the authoritative record.
An RFC is the right tool when a decision is significant enough to benefit from structured input before committing. Signals:
If consensus already exists or the decision is small, an ADR (without a preceding RFC) is usually sufficient.
RFCs live in docs/decisions/ alongside ADRs:
docs/decisions/
INDEX.md
RFC-001-auth-strategy.md
RFC-002-api-versioning.md
ADR-001-use-react-hooks.md
File naming: RFC-{NNN}-{slug}.md — zero-padded 3-digit ID, kebab-case slug from the title.
Auto-incrementing: Scan docs/decisions/ for existing RFC-*.md files, find the highest number, use the next one. If the directory doesn't exist, create it and start at 001.
---
id: RFC-{NNN}
title: "{Title}"
status: draft | open | closed | withdrawn
date: {YYYY-MM-DD}
author: {name}
related: []
tags: []
---
# RFC-{NNN}: {Title}
## Summary
A one-paragraph elevator pitch: what is being proposed and why it matters.
Someone skimming the index should be able to decide whether to read further
based on this summary alone.
## Problem statement
What problem does this solve? Why does it need solving now? Describe the
forces at play — technical limitations, user pain points, scaling concerns,
business requirements. Include enough context that someone unfamiliar with
the codebase understands the motivation without reading source code.
## Goals and non-goals
**Goals:**
- What this proposal aims to achieve
**Non-goals:**
- What is explicitly out of scope — this prevents scope creep and
clarifies boundaries for reviewers
## Proposed solution
Describe the recommended approach. Be specific about the choices and
trade-offs that matter for the decision, but don't write a full design
spec — focus on *why this approach* over the alternatives.
Include enough technical detail that reviewers can evaluate feasibility,
but defer implementation minutiae to the actual work.
## Alternatives considered
### {Alternative A}
What it is, why it was considered, and what made it less attractive than
the proposed solution. Be fair — if an alternative is genuinely close,
say so.
### {Alternative B}
Same treatment. The goal is to show that the design space was explored,
not just to justify a foregone conclusion.
## Risks and trade-offs
What could go wrong? What are we giving up? Be honest — reviewers trust
RFCs that name their own weaknesses. Include mitigation strategies where
possible.
## Rollout plan
How would this be implemented and adopted? Consider:
- Can it be done incrementally or does it require a big-bang migration?
- What's the rough sequence of work?
- Are there dependencies or prerequisites?
- How will we know it's working? (metrics, tests, user feedback)
This section can be brief for early-stage proposals and expanded as the
RFC matures.
## Open questions
- [ ] {Question that needs input from reviewers}
- [ ] {Unresolved technical detail}
- [ ] {Organizational or process question}
## Resolution
_To be filled in when this RFC is closed._
**Decision:** {what was decided}
**Date:** {when}
**ADR:** [ADR-{NNN}](ADR-{NNN}-slug.md)
| Section | Required? | Notes |
|---|---|---|
| Summary | Yes | Keep it to one paragraph |
| Problem statement | Yes | The foundation — if this isn't clear, nothing else matters |
| Goals and non-goals | Recommended | Especially valuable for large or ambiguous proposals |
| Proposed solution | Yes | The core of the RFC |
| Alternatives considered | Yes | At least one alternative, even if it's "do nothing" |
| Risks and trade-offs | Recommended | Builds trust, surfaces concerns early |
| Rollout plan | Optional | More important for migrations and breaking changes |
| Open questions | Yes | Even if just one — signals this is genuinely open for input |
| Resolution | Filled later | Left blank until the RFC concludes |
draft → open → closed (decision made) → ADR created
└→ withdrawn (abandoned, no decision)
status field and share with reviewers./adr.When an RFC reaches a conclusion:
status to closed/adr) — pull context and alternatives from the RFC rather than rewriting from scratchrelated field includes the RFC ID; the RFC's resolution links to the ADRAfter creating or modifying an RFC, update the RFCs table in docs/decisions/INDEX.md. If the index doesn't exist, create it. Sort newest first.
An RFC is an invitation to think together, not a decree. Write it to be challenged.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub heyitsgilbert/marketplace --plugin architecture-decisions