write-rfc

Generate request-for-comments documents with standardized sections for proposal review.

Updated Dec 21, 2018
One-click install
npx skills add https://github.com/dhnt/dhnt --skill write-rfc-dhnt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: write-rfc
Source: https://github.com/dhnt/dhnt/tree/main/catalog/md/plan/write-rfc
Command: npx skills add https://github.com/dhnt/dhnt --skill write-rfc-dhnt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps teams document and align on substantial, high-impact proposals before committing to implementation, reducing the risk of expensive rework and improving decision traceability.

Core Features & Use Cases

  • RFC readiness: Guides authors on when an RFC is necessary (e.g., public API changes, costly implementation, difficult-to-reverse decisions).
  • Complete, standardized structure: Ensures the proposal includes required sections such as problem statement, goals/non-goals, proposed solution, alternatives, rollout, security/privacy, compatibility, observability, and open questions.
  • Effective review process: Encourages parallel drafting of alternatives, deadline-based feedback, and resolving every comment before acceptance to keep reviewers engaged and informed.
  • Use Case: Use this skill to propose a change to an external contract or cross-team interface so stakeholders can evaluate approach tradeoffs and implementation impact before any code lands.

Quick Start

Author an RFC for your proposal at the plan phase using the /write-rfc skill, following the required section structure and sending it for review with a deadline.

Frequently Asked Questions about write-rfc

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When do I need to write an RFC for an API change?

You need an RFC for substantial changes affecting public APIs, data models, external contracts, or multi-team interfaces where the cost of disagreement or reversal is high. It secures stakeholder buy-in before implementation begins.

What sections should be included in a proposal document for stakeholder review?

A standard RFC includes title, status, authors, problem statement with no-op cost, goals, non-goals, proposed solution, alternatives, migration rollout, security, backwards compatibility, observability, open questions, and decision criteria.

How do I structure a rollout plan in an RFC?

Structure the rollout plan by detailing migration steps, backwards compatibility measures, and observability requirements. The RFC process requires resolving every comment against this plan before final acceptance.

How does the RFC process handle alternative solutions during stakeholder review?

The RFC process encourages parallel drafting of alternatives to evaluate approach tradeoffs. It uses deadline-based feedback and requires resolving every comment before acceptance to keep reviewers informed and engaged.

Can I use this RFC template for internal cross-team interface changes?

Yes, this RFC format applies to multi-team interfaces and internal cross-team changes. It helps stakeholders evaluate implementation impact and approach tradeoffs before any code lands.

What is the no-op cost in an RFC problem statement?

The no-op cost documents the expense or risk of not implementing the proposal. Including this cost in the RFC problem statement ensures stakeholders understand the baseline impact of leaving the system unchanged.