design-systems-engineering
v0.1.2Design-systems engineering team — agents (design-systems-architect, design-tokens-and-component-engineer) answering 'what is the shared system every product surface builds from, and how is it versioned and adopted?': design-token architecture (primitive → semantic → component tiers, theming/dark-mode/multi-brand), component-library API design (composition vs configuration, controlled/uncontrolled, a11y baked in), Storybook/docs, Figma→code token pipeline (Style Dictionary), and versioning/adoption (semver, changesets, codemod-backed breaking changes, deprecation, governance, adoption metrics). skills, a knowledge bank (a Mermaid decision tree + a dated 2026 tooling reference). Distinct from frontend-engineering (builds apps that CONSUME the system), accessibility-engineering (WCAG compliance), and web-design (site visual design) — this team owns the SYSTEM those build from. Tooling specifics volatile: retrieval-dated + verify-at-use. Needs ravenclaude-core.
By Matt CorbettLicense: MIT7 GitHub starsUpdated last week
Directory evidence
- Runtimes
- Claude Code
- Parsed components
- 3 skill or MCP entries
- Source updated
- Sep 15, 2026
- Manifest status
- Canonical path parsed
The directory validates manifest shape and source location. It does not execute the plugin or provide a security endorsement. Review the indexing methodology →
Install design-systems-engineering for Claude Code
claude plugin marketplace add IchenDEV/agent-plugin-mkt
claude plugin marketplace update agent-plugin-marketplace
claude plugin install design-systems-engineering@agent-plugin-marketplacePaste and run these commands in a terminal with Claude Code. They add and refresh the PluginsMP catalog, then install this plugin.
The installer fetches third-party code from the source repository shown on this page. This directory validates manifest structure and source location, but does not perform a security audit; review the manifest, components, and source before installing.
Get the source manually
git clone https://github.com/mcorbett51090/RavenClaudeClone the source repository, then follow its setup instructions to add the plugin to a compatible client. The plugin root is plugins/design-systems-engineering/.
Plugin files
├── .claude-plugin/plugin.json├── skills/component-api-and-library-build/SKILL.md├── skills/design-system-versioning-and-adoption/SKILL.md└── skills/design-token-architecture/SKILL.md
Included Skills3
Design and build an accessible, composable library component with a contract-grade public API — deciding composition vs configuration and controlled vs uncontrolled, baking in roles/focus/keyboard from v1, and shipping a story and usage docs. Traverses the component-API branch of the design-systems decision tree. Reach for this when the user asks 'compose or props for this component?', 'build an accessible Menu/Dialog/Combobox', 'controlled or uncontrolled?', or 'what should this component's public API be?'. Used by design-systems-architect (API shape) and design-tokens-and-component-engineer (implementation).
Version a component library like the public contract it is (semver + changesets), ship breaking changes with codemods and loud deprecation, and drive adoption with metrics. Traverses the versioning branch of the design-systems decision tree: semver mapping → changesets/release flow → breaking-change/codemod policy → deprecation → adoption metrics. Reach for this when the user asks 'how do we version the library?', 'set up changesets', 'how do we ship this breaking change?', or 'how do we drive adoption / measure it?'. Used by design-systems-architect (policy) and design-tokens-and-component-engineer (release pipeline).
Structure design tokens across the primitive → semantic → component tiers, with theming/dark-mode and multi-brand solved as a semantic-tier value swap, then emit the platform outputs consumers use. Traverses the token branch of the design-systems decision tree: source of truth → tier structure → naming → theming → platform outputs. Reach for this when the user asks 'how should our tokens be structured?', 'set up design tokens', 'how do we do dark mode / multi-brand?', or 'primitive vs semantic tokens?'. Used by design-systems-architect (structure) and design-tokens-and-component-engineer (pipeline).
Plugin manifests1
{
"name": "design-systems-engineering",
"version": "0.1.2",
"description": "Design-systems engineering team — agents (design-systems-architect, design-tokens-and-component-engineer) answering 'what is the shared system every product surface builds from, and how is it versioned and adopted?': design-token architecture (primitive → semantic → component tiers, theming/dark-mode/multi-brand), component-library API design (composition vs configuration, controlled/uncontrolled, a11y baked in), Storybook/docs, Figma→code token pipeline (Style Dictionary), and versioning/adoption (semver, changesets, codemod-backed breaking changes, deprecation, governance, adoption metrics). skills, a knowledge bank (a Mermaid decision tree + a dated 2026 tooling reference). Distinct from frontend-engineering (builds apps that CONSUME the system), accessibility-engineering (WCAG compliance), and web-design (site visual design) — this team owns the SYSTEM those build from. Tooling specifics volatile: retrieval-dated + verify-at-use. Needs ravenclaude-core.",
"author": {
"name": "Matt Corbett"
},
"homepage": "https://github.com/mcorbett51090/RavenClaude",
"license": "MIT",
"keywords": [
"design-systems",
"design-tokens",
"component-library",
"storybook",
"style-dictionary",
"theming",
"figma-to-code",
"semver",
"changesets",
"design-system-governance"
],
"requires": {
"plugins": [
"ravenclaude-core@>=0.7.0"
]
}
}For maintainers
If you maintain this plugin, link to this source-backed listing from your README so users can review its manifest and indexed components.
[design-systems-engineering on Agent Plugins Marketplace](https://pluginsmp.com/plugins/design-systems-engineering)