6.6 KiB
Governance
How this marketplace is maintained, what you can expect from upstream, and how it's meant to be used.
TL;DR
- Solo-maintained, AI-assisted development, MIT licensed.
- Fork-and-own is the default model. Upstream is a starting point, not a vendor.
- Issues welcome as signals. Pull requests are not accepted — see Why no PRs.
- No SLA. Best-effort bug fixes and security advisories. Breaking changes happen and are noted in each plugin's CHANGELOG.
Can I trust this?
Be honest with yourself about what you're adopting:
- One maintainer. If I get hit by a bus, the bus wins. The repos stay up under MIT, but no one owes you a fix.
- AI-generated code with human review. Every plugin is built through dialog-driven development with Claude Code. I read, test, and judge the output before it ships, but I'm not auditing every line the way a security firm would. Treat it accordingly.
- No commercial interests. I'm not selling a SaaS, not steering you toward a paid tier, not collecting telemetry. The plugins run locally in your Claude Code installation.
- MIT licensed. Fork it, modify it, ship it under your own name.
If you work somewhere that needs vendor accountability, support contracts, or signed assurances — this isn't that. Use it as a reference implementation, fork it into your own organization, and own the result.
How this is meant to be used
Fork-and-own
The intended workflow:
- Fork the marketplace (or a single plugin) into your own organization or namespace.
- Tailor it to your context — terminology, integrations, whatever doesn't fit out of the box.
- Maintain it yourself. Treat your fork as the canonical version for your team.
- Watch upstream selectively. Cherry-pick changes that help, ignore changes that don't. There's no obligation to stay in sync.
For claude-design specifically, the most likely fork is a content adaptation — different intent-preset coverage (e.g., dropping frontier-design if your team never uses it), an organization-specific DESIGN.md template, a different evidence-grade discipline, or per-preset prompt patterns tuned to your team's design system. The plugin is a content surface plus a single skill. Forking it is straightforward.
What to change first when you fork
- Identity — rename the plugin, replace authorship, update README.
- Reference content — the
references/tree reflects what Anthropic published and the community converged on as of 2026-05-17. Adjust to your team's house style and design system. - Frontmatter —
nameanddescriptionshow up in/config. Pick names that won't collide with other forks installed on the same machine.
Staying current with upstream
If you want to pull in upstream changes later:
- Cherry-pick, don't merge. Each plugin moves independently.
- Read the CHANGELOG first.
- Keep your customizations distinct. A renamed skill (
my-org-design-facilitator) merges more cleanly than edits toclaude-design-facilitator.
What upstream provides
| What I do | What I don't | |
|---|---|---|
| Bug fixes | Best-effort when I notice or get a clear report | No SLA, no triage commitment |
| Security issues | Investigate within reasonable time, document in CHANGELOG | No CVE process, no embargo coordination |
| New features | When they fit my own usage | Not on request |
| Breaking changes | Documented in CHANGELOG | They happen — version pin if you need stability |
| Compatibility | Tracked against current Claude Code releases | No long-term support branches |
If any of this is a dealbreaker — fork now, version-pin, and stop reading upstream.
How to contribute
Issues — yes, please
Issues are the most valuable thing you can send me:
- Bug reports with reproduction steps. Even a screenshot helps.
- Use-case feedback. "I tried to use this in my organization and X didn't fit" is genuinely useful, even if I can't fix it for you.
- Content suggestions. If a reference file in
claude-designproduces guidance that doesn't match what you observe inclaude.ai/designtoday, tell me what you saw. Concrete examples beat abstract complaints.
Pull requests — no
This is deliberate, not laziness:
- Solo review is a bottleneck. Honest PR review takes me longer than rewriting from scratch. The math doesn't work.
- Forks are where the value is. The fork-and-own model means upstream consolidation isn't the point. Your organization's adaptations belong in your fork, not mine.
- AI-generated code complicates provenance. Every line here is produced through dialog with Claude Code, with me as the judge. Mixing in PRs from contributors with different processes and licensing assumptions creates a mess I'd rather not untangle.
If you've built something useful on top of a fork, publish it under your own name and link back. I'll happily list notable forks here once they exist.
Notable forks
(To be populated as forks emerge. If you've forked this plugin for production use, open an issue and I'll add a link.)
Relationship between plugins
These plugins are independent. Install one without the others, fork one without the others. They share conventions (slash command naming, hook patterns, AI-generated disclosure, and the shared human-friendly-style output style) but no runtime dependencies.
claude-design is a content surface with a single skill — it works without any other plugin installed. It recommends Anthropic's official knowledge-work-plugins/design as the downstream tool for post-design critique, accessibility audit, and engineering handoff, but does not depend on it being present.
The marketplace is a catalog, not a suite. Don't fork the whole repo unless you actually want to maintain everything.
Versioning and stability
- Semantic versioning per plugin. Each plugin has its own
CHANGELOG.mdand version number. - Breaking changes happen. I bump the major version when they do, but I don't run an LTS branch.
- Pin your version. If stability matters more than features, install a specific version and stay there until you choose to upgrade.
For claude-design specifically: changes to skill trigger behavior or per-preset reference content schema are minor or major bumps. Pure documentation or per-preset content refresh from Anthropic source updates are patch. The skill surface itself is meant to be stable across patch releases.
License
MIT for all plugins in this marketplace. See LICENSE in this plugin and each other plugin's LICENSE file.