| name | write-rfc |
| description | Draft or revise a Video.js RFC. Use for public APIs, product direction, user-facing DX, shared architecture, or hard-to-reverse proposals needing buy-in. |
RFC
Read rfc/README.md for the current lifecycle and format. If the user explicitly asks for an internal record instead, use a design or decision record when the author owns the choice and no wider agreement is needed.
Workflow
- Verify that an RFC is warranted; skip it for local implementation details, ordinary bugs, or already-approved work.
- Read current code, existing RFCs/design records, related issues, and relevant user evidence.
- Define the problem, affected users, constraints, goals, and explicit non-goals.
- Present the proposed direction at the level needed for agreement, not a line-by-line implementation plan.
- Compare credible alternatives and make costs, compatibility, migration, and unresolved questions explicit.
- Define how success will be evaluated and what happens after acceptance.
- Keep status
draft until the repository's approval process changes it.
Make public API and DX tradeoffs explicit when central. Keep implementation detail in code, or in a later design record or plan only when the user explicitly requests one.
Example
Input: “Draft an RFC for a new plugin extension model.”
Output: A draft proposal with user evidence, goals, non-goals, compatibility and migration costs, credible alternatives, open questions, and success measures.
