cc-design: a design skill that gates AI agents behind an approved plan

The problem cc-design targets: agents that generate HTML without a review gate

Most coding agents will happily emit a landing page from a one-line prompt and hand you the result with no intermediate checkpoint. cc-design is built around the opposite assumption. The README describes a workflow where the agent asks targeted questions, presents a visible execution plan with goals, facts and assumptions, and waits for approval before writing code. Three behavioural guarantees are stated explicitly: never builds without an approved plan, never delivers without screenshot verification, and never uses banned patterns the project groups under the label AI slop. The audience is therefore narrow and specific: engineers and designers already running Claude Code or Codex who want HTML artifacts (slide decks, landing pages, interactive prototypes, explainers) and who would rather review a plan than review a finished file they have to throw away. It is not a UI kit and not a runtime library. Nothing in the README suggests you import it into an application.

The staged pipeline and where the agent stops

The documented flow is Understand, Route, Plan, Approve, Build, Verify, Deliver. Understand is question-driven discovery. Plan produces the execution plan. Approve is a human gate. Build uses what the README calls a per-section preview pattern, so approval happens section by section rather than once for the whole artifact. Verify is a three-phase self-check covering structural, visual and design excellence. Deliver produces a screenshot-verified artifact. Two details matter more than the diagram. First, follow-ups and minor edits skip the full discovery flow, which means the expensive part of the process is paid once per artifact, not once per change. Second, verification is tied to screenshots, so the agent's own visual output is the evidence, not its description of the output. The README also states that the always-loaded core-constraints.md layer contains an Iron Law, a 12-item anti-slop quick-ref and a delivery checklist. That file is loaded on every turn, which is a deliberate cost: constant prompt overhead in exchange for consistent guardrails.

Installing it: marketplace commands and the optional export stack

Installation runs through the plugin marketplace in both supported hosts. For Claude Code the README gives three commands: /plugin marketplace add ZeroZ-lab/cc-design, then /plugin install cc-design@cc-design, then /reload-plugins. After that, activation is via /cc-design:design. For Codex the README lists the same three marketplace and install commands and states that activation is via a $cc-design reference, with agents/openai.yaml handling the integration. Core installation has no extra dependencies. Export is where dependencies appear: npx playwright install chromium for export and verification, and ffmpeg for video and audio, installed with brew install ffmpeg on macOS, sudo apt install ffmpeg on Ubuntu or Debian, and choco install ffmpeg on Windows. The README lists PDF (multi-file and single-file), PPTX (image and editable), MP4 and inline HTML as export targets, plus a dual-track audio system with a 37-item SFX catalog mixed through ffmpeg. If you only want HTML output, you can skip the entire optional block.

The design layer: 20 philosophy schools and 68+ cloned brand systems

Direction is set by naming a style in the prompt. The README shows examples such as using the Pentagram style for an infographic, applying Experimental Jetset minimalism to a poster, or mixing Takram restraint with Locomotive motion for a hero. These map to 20 schools across five traditions listed as Information Architects, Motion Poets, Minimalists, Experimental Vanguard and Eastern Philosophy, documented in references/design-styles.md. Separately, brand cloning loads design systems by name, with examples including a Stripe aesthetic for a pricing page, a Notion-style kanban board, and Vercel minimalism mixed with Linear purple accents. The README states this draws on 68+ brand design systems from getdesign.md using progressive loading. Note the dependency: brand fidelity here is a function of an external catalogue, not of anything shipped inside this repository. If getdesign.md changes or drops an entry, the prompt that names that brand is no longer backed by the same reference material. The README does not describe a fallback for a missing brand.

Where the design is thin: animation verification and the maintenance contract

The animation section is the most technically specific part of the README and also the part with the least explanation. It names a Stage+Sprite timeline engine, an easing library, a verification method described as Seek-First numerical verification using __seek and getComputedStyle, a signal protocol, and pitfall guardrails. What the README does not give is a worked example of __seek, the shape of the signal protocol, or what a failed numerical check does to the build. Treat those as undocumented until you read the references. The maintenance picture is clearer. Contributing rules cap SKILL.md at 200 lines and push technical content into references/, new references must be registered in load-manifest.json and in the routing table inside SKILL.md, and two scripts are named for validation: node scripts/lint-load-manifest.mjs and node scripts/generate-bundle-catalog.mjs. Any change to first-turn behaviour requires updating VERSION, SKILL.md, README.md and references/workflow.md, then running ./scripts/check-behavior-contract.sh against a base ref. That is a real upgrade cost for anyone forking the project: four files stay in lockstep or the behaviour contract check fails.

The wrong tool: when a single-shot generator beats a gated workflow

The approve-then-build loop is the product, and it is also the reason to look elsewhere in some cases. If you want one throwaway HTML mockup to settle an argument in a meeting, the discovery questions, the plan, the per-section approval and the three-phase verification are pure overhead. A plain agent prompt or a template will get there faster. The same applies to automated pipelines: the README describes human approval gates at Plan, Approve and per-section Build, and nothing in it suggests a non-interactive mode. There is also no retrieved release history for this repository, so there is no tagged version to pin in a reproducible build. Teams that require pinned, audited tooling should read that as a gap rather than assume one exists. The README does state the project is not archived, and the last push date is recent, but a commit stream is not a versioning scheme.

Alternatives and the actual difference in approach

The honest comparison is not another plugin of the same shape, because the README does not name one. Compare against the two things you would otherwise use. First, a general-purpose coding agent with no design skill: it will produce HTML from the same prompts, but it has no core-constraints.md loaded on every turn, no per-section preview gate, and no screenshot verification step, so quality control is whatever review you perform afterwards. Second, a component library or design system such as Tailwind or an internal React kit: those give you deterministic, testable output with no model in the loop, but they cannot produce a ten-slide deck or an interactive explainer from a sentence. cc-design sits between the two, trading determinism for generation speed while adding gates the raw agent does not have. The brand-cloning feature also has an analogue in getdesign.md itself: you can read a brand's design system directly and apply it by hand, which is slower but removes the progressive-loading layer and the external dependency.

Licence, verification duties and what to check before you install

The README states MIT. The repository metadata supplied here lists the licence as unknown, which is a discrepancy worth resolving by opening the LICENSE file at the root rather than trusting either source. MIT is permissive, but the project also pulls design references from getdesign.md and lists no licence for that catalogue, so if you intend to reuse cloned brand systems in shipped work, check the terms of that source separately. This is not legal advice. The practical verification list is short. Confirm the plugin marketplace commands work in your host version, since both Claude Code and Codex paths are documented with identical marketplace syntax. Confirm npx playwright install chromium completes, because the README ties both export and verification to it. Read references/workflow.md and core-constraints.md before your first real task, because those govern first-turn behaviour and are the files the behaviour contract check protects. If any of those three checks fails, the approved-plan and screenshot-verified guarantees described in the README are the parts that stop working first.

Editorial conclusion

Adopt cc-design if you already work inside Claude Code or Codex and want HTML deliverables (decks, landing pages, prototypes) produced through an approve-then-build loop rather than a single prompt. Do not adopt it if you need a stable API, a packaged component library, or a release history you can pin to: the repository shows no retrieved releases. Before installing, verify three things against the repo itself: that the MIT licence file is present at the root, that node scripts/lint-load-manifest.mjs runs clean on your checkout, and that npx playwright install chromium succeeds in your environment, because the README ties export and verification to that browser.

Official sources

1. Issues
2. README
3. ZeroZ-lab/cc-design on GitHub