From design-system-ops
Creates or documents multi-stage contribution workflows for design systems from proposal to release, with decision criteria, ownership, and scaling for team size.
npx claudepluginhub murphytrueman/design-system-opsThis skill uses the workspace's default tool permissions.
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.
Establishes governance for design systems covering contribution models, deprecation processes, versioning strategies, adoption metrics, and documentation. Use when launching, scaling past 30 components, or measuring health.
Automates design system construction from repository analysis: extracts patterns, builds OKLCH token hierarchies, implements accessible components with tests, verifies via multi-reviewer panels.
Enforces structured design validation before coding features, components, or changes. Explores context, proposes approaches with trade-offs, sets up git worktrees, and requires user approval.
Share bugs, ideas, or general feedback.
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.
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. 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 should scale accordingly, and the output should note where the path diverges by contribution type.
Ask for or confirm:
Capacity is the variable most contribution processes ignore. A six-stage review process designed for a four-person dedicated team will break immediately if there is only one part-time maintainer.
Small-system note (fewer than 5 components): For systems this size, the full six-stage workflow is almost certainly too heavy. Produce a lightweight three-stage workflow instead: Propose (async, one paragraph) → Build (with review from the maintainer) → Ship (documentation + release note). The community review stage and the detailed assessment stage add overhead that small teams cannot absorb. The contribution criteria should still be documented — but they can be a short checklist, not a policy document. Ask: "Is there one person maintaining this, or is it shared?" If one person, the workflow is essentially "talk to them first."
Version: [version number or date] Owner: [who maintains this document] Last reviewed: [date]
Before the stages, establish the contribution types. Different types move through the process at different speeds.
Type A: Bug fix or small enhancement Scope: Correcting a documented error, adding a missing state, fixing a token reference. Path: Lightweight — skips proposal and community review, moves directly to build.
Type B: Component enhancement Scope: Adding a new variant, prop, or behaviour to an existing component. Path: Standard — proposal, design review, build, documentation, release.
Type C: New component Scope: A component that does not currently exist in the system. Path: Full — all six stages.
Type D: System-level change Scope: Token architecture changes, naming convention updates, governance policy changes. Path: Full, with extended community review. These changes have the widest blast radius.
Purpose: Establish whether a contribution is worth building before anyone builds it.
What the contributor submits:
Proposal template:
## Contribution proposal
**What:** [One sentence — what you want to add or change]
**Why:** [The problem this solves, in business or user terms]
**Evidence:** [Two or more distinct product use cases demonstrating the need]
**Existing awareness:** [What currently exists in the system that partially addresses this? Why is it insufficient?]
**Contributor commitment:** [Are you willing to own the build phase? Y/N]
What happens next: The design systems team reviews the proposal within [SLA — e.g. five working days]. Three outcomes are possible:
Deferred proposals: Proposals marked as "deferred" are real needs with wrong timing. To prevent them from being forgotten:
Contribution criteria checklist: A proposal meets the criteria if it satisfies all of the following:
Document why each declined proposal was declined. This creates a record that protects the team from re-litigating the same decisions and gives contributors an honest answer.
Purpose: Establish the design direction and component API before any build work begins.
What the contributor produces:
Review: Design review with the design systems team and, where possible, a representative from each product team that raised the original need. One round of structured feedback, then sign-off.
Sign-off criteria:
If new tokens are needed, the token decision runs in parallel and must be resolved before Stage 3 begins.
Purpose: Implement the component to the agreed spec.
What the contributor produces:
Handshake points: Mid-build check with the design systems team when the happy path is functional but before edge cases and tests are complete. Catch misalignments early.
Build is considered complete when:
Purpose: Make the component usable by teams who were not in the room when it was designed.
What must be documented before release:
The ai-component-description skill should also be run at this stage to produce the Figma MCP-optimised description.
Documentation is not complete until someone who was not involved in the build can follow the guidelines to use the component correctly. Consider a brief documentation review with a designer from a consuming team.
Purpose: A final check before release, giving consuming teams visibility before the component ships.
For Type A and B contributions, this stage can be abbreviated to a release note preview.
For Type C (new components) and Type D (system-level changes): share the component and documentation with consuming teams at least [SLA — e.g. one week] before release. Invite feedback. Document any significant responses. Make the rationale for any changes or non-changes explicit.
This stage is not a veto mechanism. It is a courtesy that reduces post-release surprises and builds contributor trust.
Purpose: Ship the contribution with enough communication that consuming teams know it exists and can use it.
What ships:
Release notes for a new component should name the contributor. Contribution is a social act as much as a technical one.
After release: log the contribution in the system's change history and update the proposal record with the outcome.
As important as the stages above: be explicit about what the contribution process is not for.
The system does not accept:
Saying no clearly is part of a healthy contribution process. A system that accepts everything eventually becomes a system no one trusts.
When a proposal is declined, document the decision using the decision-record skill. The record should include:
Rejection records serve two purposes: they give the contributor a clear, written explanation, and they prevent the same proposal from being re-litigated without new evidence. A healthy contribution process produces rejection records as often as it produces new components.
At the staff level, the contribution workflow must account for the component's API as a versioned contract:
For Type B (enhancements):
For Type C (new components):
For Type D (system-level changes):
Include the versioning contract in the contribution workflow document as a section that contributors and reviewers reference at the Build and Release stages.
For new components (Type C) and system-level changes (Type D), the workflow should include a consumer contract validation step:
This step sits between Stage 5 (Community review) and Stage 6 (Release). It converts "we told them about the change" into "we verified the change works for them."
After writing the workflow, add a note on how to calibrate the SLAs and review stages for the team's actual capacity. A part-time maintainer cannot run the same process as a four-person dedicated team. Name where the process can be compressed without compromising quality, and where it cannot.