designer-skills: eight agent skills that make a coding tool follow a design process

Instructions, packaged as skills

The premise is stated in the project description. These are agent skills for designers who prototype and build with AI coding tools, and they exist to encode design process so that the AI follows a structured path instead of producing random output.

That framing matters, because the repository contains no library and no program. The top level is a set of directories, one per skill, alongside a plugin manifest directory, a licence, a security policy and the images used in the project notes. The primary language is not even a programming language, because the content is instructions written for an agent to read and follow.

That is a different kind of open source project from a package you import, and it carries a different kind of risk. The instructions are executed by a tool with access to your filesystem and possibly your API keys, and the project notes are unusually direct about that: the files are instructions for local AI tools, and you should treat them like any other project dependency, reviewing the skills before using them in sensitive or production contexts and keeping your editor, CLI and API keys on trusted machines.

One command for many agents, or a plugin for Claude Code

Installation goes through a skills command line tool, and the command is short:

npx skills add julianoczkowski/designer-skills

The tool is interactive. It walks you through which skills to install, which agents to target, and whether to install at project or global scope, and it is described as working with Claude Code, Cursor, Codex, Windsurf and more than forty other agents. That breadth is the reason to use the command rather than copying files by hand, since the same skill has to land in a different place for each agent.

If you use Claude Code there is a second route, installing all eight skills as a plugin straight from the repository:

/plugin marketplace add julianoczkowski/designer-skills
/plugin install designer-skills@designer-skills

The skills then load automatically, and Claude invokes them based on each skill's description, or you can call one explicitly, for example with the design brief skill. Installs track the latest commit on the main branch, so you always get the newest skills and fixes, and updating later is one command:

/plugin update designer-skills@designer-skills

To try the set before installing anything, there is a local directory flag for the Claude Code command line that points at a checkout on disk.

The flow, and what each step produces

The skills follow a deliberate sequence, and you can use any of them on its own or run the design flow command to be guided through the whole thing automatically. The flow diagram in the project notes shows the shape: the flow orchestrates the questioning step through to the review, with an iteration loop back to the start.

The order starts with the grilling skill, which interrogates you about your plan until every design decision is resolved. The design brief skill then turns that session into a structured brief, and it includes codebase exploration so that the AI respects what already exists. The information architecture skill defines the structural skeleton, covering navigation, content hierarchy, page structure, URL patterns and user flows. The design tokens skill generates a complete token system of colours, spacing, typography and motion, with light and dark palettes, based on a chosen aesthetic philosophy.

Then the work turns into something buildable. The brief to tasks skill breaks the brief into an ordered checklist of independently buildable vertical slices, and the frontend design skill builds with a named aesthetic philosophy, mobile first, with dark mode included, drawing on eight design philosophies with concrete implementation parameters. The last skill is the design review, a structured critique against the brief, supporting both code review and screenshot based review, and it runs on request rather than automatically, so it is used once you have something built.

That ordering is the argument of the whole project: decide before you build, and review after.

Respecting the code that is already there

The first key principle is that every skill touching the codebase includes a detailed detection checklist, and the list is specific: CSS variables, Tailwind config, UI framework themes, component directories, Storybook stories, token files, font loading, and package.json dependencies.

The stated purpose is prevention. It stops the AI generating a new button when one exists, and stops it inventing a colour that clashes with the established palette. That is a real failure mode of AI assisted interface work, and it is a failure that a human reviewer catches easily and an agent does not, because the agent has no memory of the design system it has already been shown.

The design brief skill reinforces the same idea from the other end, by including codebase exploration as part of producing the brief. So the detection is not only a review step at the end, it happens before the decisions are written down, which is the cheaper place to catch it.

Mobile first, and dark mode as a requirement

The second and third principles are about how the output is built, and both are stated as requirements rather than suggestions.

The frontend design skill mandates building the mobile layout first at 375 pixels, then scaling up with min-width media queries, with touch targets, text sizing and navigation patterns all specified for mobile. Mobile first is not a preference here so much as a constraint that forces the layout to survive a narrow viewport before it is allowed to grow.

Dark mode is handled the same way, from three directions. The design tokens skill generates both a light and a dark palette rather than a light one you darken later. The frontend design skill builds with CSS custom properties that support both the prefers-color-scheme media query and a manual toggle, so the user can override the system preference. And the design review skill checks that dark mode has been implemented correctly, which means a half-done dark theme is something the review is supposed to catch.

Three skills cooperating on one requirement is a reasonable signal that the author expected this to be skipped otherwise.

Naming a style is optional

The fourth principle is about how much vocabulary the user has to bring. The aesthetic philosophies in the frontend design skill are described as a menu rather than a requirement. If you name one, in the style of asking for a specific designer's aesthetic, the AI follows those parameters. If you describe a vibe, such as wanting something warm and clean, it maps to the closest philosophy. And if you say nothing at all, it picks one based on context and tells you which it chose.

That last behaviour is the useful one for a designer who does not want to think in the vocabulary of eight named styles. The trade is that the output is now a decision the agent made, and the only defence against an aesthetic you did not choose is to read what it produced. The review skill is the place to do that, and it is why the flow ends in a critique rather than in a handoff.

What persists, and the security note

The last principle is about persistence. All design documents are saved to a .design folder in the project, organised by feature, with the folder name derived from the feature being designed. Running the flow for different features creates separate subfolders so nothing gets overwritten, and every skill in the flow reads from and writes to the same subfolder. The contents are the design brief, the information architecture, the task list and the design review documents.

The practical benefit is stated plainly: if you return to a project later, the flow detects which features exist and where you left off. That matters more than it sounds, because a design pass that exists only in a chat transcript is a design pass that has to be repeated to be useful.

The security section is the part to read before installing this into anything client-facing. The project asks for responsible disclosure through the process in the security policy file rather than through public issues, and it states the Apache 2.0 licence and disclaimer. The last push was on 2026-07-06 and the repository publishes no tagged releases, so an install tracks the branch rather than a fixed version.

Editorial conclusion

designer-skills suits a designer who works with an AI coding agent and finds the output inconsistent, because the value is in the sequence and the checklists rather than in any model, and the documents it leaves behind are usable with a human. It is the wrong choice if you want a different design workflow, since the eight skills encode one opinionated path, and it is the wrong choice if you cannot review what the agent reads, because the files are instructions that the agent follows. Before you install it into a client project, read the skill files yourself the way the project notes tell you to read any dependency, and set the scope deliberately, since the installer offers both project and global installation. The licence is Apache-2.0, the last push was on 2026-07-06, and the repository publishes no releases, so the install tracks the branch rather than a version.

Frequently asked questions

Official sources

1. Issues
2. julianoczkowski/designer-skills on GitHub
3. License: Apache-2.0
4. README