Rfc design docs

Skill shinzoxD/knackbox/skills/documents/rfc-design-docs

Write RFCs and technical design docs that force clear decisions. Use whenever the user asks for an RFC, design doc, architecture proposal, tech design, or "how should we build X" write-up for a feature or system change — even from a rough bullet list.From its SKILL.md

Install

npx -y skills add shinzoxD/knackbox --skill rfc-design-docs

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.8 KB, 549 tokens by cl100k_base, as published. Nobody here has run it

RFC / Design Docs

A good design doc makes the decision easy to challenge: context, options, trade-offs, and a clear recommendation. Length is not rigor.

Workflow

Problem and non-goals first — what success looks like and what you refuse to solve now.
Constraints: scale, latency, compliance, team skills, deadlines, existing systems.
Options (at least two real ones, plus "do nothing" when relevant).
Recommendation with the decisive trade-offs.
Detailed design only for the chosen path: data model, APIs, failure modes, rollout, observability.
Open questions and decision log.

Output format

# RFC: <title>
**Status:** draft | review | accepted | superseded
**Authors:** …
**Last updated:** …

## Summary
One short paragraph: what we propose and why.

## Motivation
Problem, evidence, urgency.

## Goals
- …

## Non-goals
- …

## Constraints
- …

## Options considered
### Option A — …
Pros / cons / cost

### Option B — …
Pros / cons / cost

## Recommendation
Which option and the decisive reasons.

## Detailed design
### Overview
### APIs / interfaces
### Data model
### Failure modes and consistency
### Security and privacy
### Rollout and migration
### Observability
### Testing strategy

## Alternatives rejected (brief)
…

## Open questions
- …

## Success metrics
How we know this worked 2–6 weeks after ship.

Rules

Every option must be viable enough to be chosen; strawmen waste readers.
Label assumptions. Do not invent traffic numbers; use ranges or TODOs.
Prefer diagrams described in text or mermaid only when they clarify.
Security, multi-tenant isolation, and data retention get explicit sections when user data or auth is involved.
Rollout must cover dual-write/dual-read, flags, and rollback when state changes.
Keep the first half readable by an eng manager; deep detail can follow.

Edge cases

Early brainstorm: produce a short RFC-lite (Summary, Options, Recommendation, Open questions) and say what research is needed.
Revising an existing RFC: keep a Decision log of what changed and why.
Cross-team political choice: make trade-offs explicit and fair; avoid burying the cost on the other team without stating it.
User wants only the API section: still restate goals/non-goals in brief so the API is grounded.

What ships with it: 1 file

1.7 KB alongside SKILL.md

benchmarks/

prompts.json1.7 KB