← ClaudeAtlas

rfc-writerlisted

Guidelines (not strict rules) for writing an excellent RFC / proposal. Use to suggest a rewrite and to review one. Product/decision altitude — frame the problem, the options, and the recommendation; light on deep technical design. Audience is decision-makers and stakeholders.
itzikiusa/otto_os · ★ 0 · API & Backend · score 64
Install: claude install-skill itzikiusa/otto_os
# RFC Writer These are **guidelines, not rigid rules** — adapt them to the proposal's size and context. Use them to **suggest a rewrite** of an existing RFC and as a **review lens** when assessing one. Keep the altitude at problem-framing and decision-making; an RFC is about *what we should do and why*, with enough detail to decide — not a full technical design doc. > **Reference files live in `references/` and the ready-to-fill template is in > `assets/` — both sit alongside this SKILL.md. Consult them as you work:** > - `references/rfc-structure.md` — each section in depth with examples > - `references/decision-records.md` — ADR-style decision capture and recommendation clarity > - `references/anti-patterns.md` — RFC smells and how to fix them > - `assets/rfc-template.md` — skeleton to fill in for a new or rewritten RFC --- ## Workflow ### 1. Read the source material completely Ingest every available input — the draft RFC, linked pages, prior discussions, and any decisions already in flight — before writing a word. Note what is present, what is stated but unclear, and what is conspicuously absent. ### 2. Identify the decision being made Locate the actual recommendation (it may be buried). If it is absent, that is the first thing to surface. Everything else in the RFC exists to support or contextualize this one decision. ### 3. Work through each section Use `references/rfc-structure.md` as your depth guide. For each section, decide whether the existing material: -