contribution-workflow
Contribution workflow
A skill for creating a structured contribution workflow covering the full journey from proposal to release. Output is a document teams can actually follow — not a policy statement, but a process with named stages, decision criteria, and clear ownership at each gate.
Before you begin: verify references
Confirm that every path in this skill's frontmatter references: exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example npx skills install) dropped the repo-root knowledge-notes/ directory. Tell the user to reinstall by a method in 1-INSTALL.md and run verify-install.sh from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.
Context
Most design systems have one of two contribution problems. Either there is no process, so contributions arrive inconsistently and the design systems team becomes a bottleneck because every request is a negotiation. Or there is a process that is so heavy it discourages contribution entirely, and teams build locally rather than bother.
The goal here is a workflow that is lightweight enough to not be a burden, structured enough to produce consistent quality, and honest enough to tell contributors what will and will not make it into the system.
The six-stage structure below reflects the full lifecycle of a contribution; it is the shape most published contribution models share (Nathan Curtis and Brad Frost have both written it up), not this pack's invention. Not every contribution needs all six stages at the same depth — a small enhancement to an existing component is lighter than a new foundational component. The workflow scales accordingly, and the output notes where the path diverges by contribution type.