This is taking longer than expected.

Try againBrowse the library
AI Blocks

All AI specialists

Hire an AI design rule consistency reviewer

Check code against your design rules. Find inconsistent styles, changed colour pairs and missing component specs.

What you give

  • Your repo or front-end folder with components and styles
  • Your design file, so intent can be compared with code (advised)
  • Your brand guide with colours, type and rules (advised)

What you get

  • A DESIGN.md of the colours, type, spacing and parts the product really uses, for you to approve
  • Every drift item with file, line and the token or name it should use, counted against last month
  • Failing colour pairs with the closest passing colours
  • Spacing, type and layout slips on changed screens, each with a fix

An example

You have a design system and suspect the code has drifted from it.

You ask: “Check code against your design rules. Use the material I attach and ask for anything essential that is missing.”

You get back:

  • DESIGN.md. The colours, type, spacing and parts your product really uses, saved once you approve them.
  • Drift. Each hardcoded value, naming problem and undocumented variant, with file, line and the token it should use.
  • Colour pairs. Failing light and dark colour pairs with the closest passing colours, when a colour moved.

An example, not your task.

Hire this specialist

It is free and needs no account. Download the pack, give it to your AI and tell it the job. Your AI asks for anything it is missing, then does the work and checks it.

Download the specialist

Related specialists

Skills and workflows for this job: Design things people love

Details

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

  • A DESIGN.md of the colours, type, spacing and parts the product really uses, for you to approve
  • Every drift item with file, line and the token or name it should use, counted against last month
  • Failing colour pairs with the closest passing colours
  • Spacing, type and layout slips on changed screens, each with a fix
  • A quarterly ten-principles review with what to remove
  • A spec for each new pattern, and a fix list of at most fifteen

How it does the job well

  • Start from the user's task and the content, then the layout. Decoration comes last.
  • Design every state: empty, loading, error, long text and mobile.
  • Keep one visual system. Reuse spacing, type and colour tokens instead of one-off values.
  • Check text contrast (at least 4.5:1 for body text) and keyboard focus as you go.

Mistakes it avoids

  • Proposing fifty fixes and getting none.
  • Renaming components across the product in one month.
  • Adding a token for every one-off.
  • Treating the design file as truth when the code has been live for a year.
  • Designing only the happy path at desktop width.
  • Copying a reference's logo, text or claims instead of learning from its structure.

What a good result looks like

An example, not your task: You have a design system and suspect the code has drifted from it.

  • DESIGN.md. The colours, type, spacing and parts your product really uses, saved once you approve them.
  • Drift. Each hardcoded value, naming problem and undocumented variant, with file, line and the token it should use.
  • Colour pairs. Failing light and dark colour pairs with the closest passing colours, when a colour moved.
  • Polish slips. Spacing, type and layout slips on this month's changed screens, each with a fix.
  • Quarterly review. Verdicts on ten principles and what no longer earns its place, listed for removal first.
  • Specs. A spec for each new pattern: layout, tokens, props, states, breakpoints and edge cases.

How the work is checked

  • Every drift item names a file and a line, and the token or name it should use.
  • Counts in drift.md come from the audit, not from memory.
  • The polish check covered only screens that changed, or says why it covered more.
  • No spec was written for a pattern that did not pass review.
  • States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way Dieter Rams and Herb Lubalin would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

  • Write the rules once. A DESIGN.md from the colours, type, spacing and parts the code really uses, and tokens from the brand guide if none exist.
  • Read last month. Picks up which fixes were proposed and which were done.
  • Measure the drift. Counts hardcoded values, naming problems and undocumented variants with file and line, and flags a count that rose two months running.
  • Check the colours when they moved. Tests every light and dark pair after a token change and names the closest passing colour for each failure.
  • Check the changed screens. Spacing, type and layout slips on this month's screens, each with a fix.
  • Review the whole quarterly. Ten principles, with what no longer earns its place proposed for removal first.
  • Spec the new patterns. For a pattern that passed review, the spec for layout, tokens, props, states, breakpoints and edge cases.
  • Log and hand back. Updates the drift file and stops for your yes.

How the role works

  1. Checks your task, context and available tools.
  2. Picks the methods needed and prepares a work plan.
  3. Carries out supported tasks, with each method's limits and review gates.
  4. Checks the real deliverables and corrects supported faults.
  5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id monthly-design-system-keeper only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/monthly-design-system-keeper/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

  • Your repo or front-end folder with components and styles
  • Your design file, so intent can be compared with code (advised)
  • Your brand guide with colours, type and rules (advised)
  • The screens or releases that changed this month (advised)
  • Last month's keeper file, once it exists

Helpful context (optional)

  • A list of components a designer already knows are wrong, so the first audit confirms rather than discovers
  • Your release notes for the month

Tools and access

  • Claude Code: It can read the repo, keep the rules, drift and specs files and run on the first Wednesday.
  • Figma: Export or link the frames for changed screens, so intent can be compared with code.
  • Claude Code: It can read your project files, run the script and apply the fix once you agree.
  • Any AI that can run Node: The script needs Node 18 or newer. A plain chat AI can do the hand-worked version.
  • Any good chat AI that reads images: It can judge what is in a screenshot or photo, not only your description.
  • A notebook or spreadsheet: Keeping the part list and scores side by side shows progress between reviews.

Functions and deliverables

  • Design rule consistency reviewer: Check code against your design rules. Find inconsistent styles, changed colour pairs and missing component specs.
    • A DESIGN.md of the colours, type, spacing and parts the product really uses, for you to approve
    • Every drift item with file, line and the token or name it should use, counted against last month
    • Failing colour pairs with the closest passing colours
    • Spacing, type and layout slips on changed screens, each with a fix
    • A quarterly ten-principles review with what to remove
    • A spec for each new pattern, and a fix list of at most fifteen
  • Project design rules writer: Share your project. Document the colours, type, spacing and components it uses in a DESIGN.md file, with conflicts left as open questions.
    • DESIGN.md file at the project root
    • Colour, type and spacing lists
    • Component rules
    • Things to avoid
    Source: sickn33.
  • Design system reviewer: Share components and style rules. Check consistency, document variants and states, or propose a new pattern that fits the system.
    • Audit list of inconsistencies
    • Component documentation with variants
    • Design for a new pattern
    • Fixes for naming and tokens
    Source: Anthropic.
  • Colour contrast checker: Share your colour tokens. Get light and dark theme pairs checked for readability, with the closest passing colours.
    • A pass or fail line for each text and background pair, with its ratio
    • Separate results for light and dark mode
    • The closest passing colour for each failure, with the same hue
    • One value per token that passes on every background
    • A list of where each token is used, and what to check by eye
    Source: sickn33.
  • Interface polish checker: Share your page or component code. Get spacing, type and layout slips with a fix for each.
    • A list of violations with quoted lines
    • A short reason for each
    • A concrete code fix
    • Cleaner spacing and type
    Source: sickn33.
  • Ten-principle product design reviewer: Share a product, page or service. Review each part’s purpose, score ten design principles and get reasoned cuts and fixes.
    • One-sentence purpose and a list of every part with its job
    • A verdict and reason for each of the ten principles
    • Parts that serve no purpose, with proposed cuts
    • A score out of 100, with how it was worked out
  • Design handoff specification writer: Share a finished design and its rules. Get developer notes for layout, style values, component states, screen sizes and edge cases.
    • A layout and measurement spec
    • A table of component states
    • Interaction and animation details
    • Edge case and content rules
    • An accessibility checklist
    Source: Anthropic.
  • Design token and handoff builder: Share brand colours and style needs. Get shared style values, component notes and files that developers can check in the project.
    • A colour palette with contrast checks. Each colour has steps from 50 (lightest) to 900 (darkest)
    • A type scale and an 8-point spacing scale
    • Token files named design-tokens.css, _design-tokens.scss or design-tokens.json. The JSON has keys for colors, typography, spacing, sizing, borders, shadows, animation, breakpoints and z-index
    • Responsive breakpoint values
    • A developer handoff note
    Source: Alireza Rezvani.
  • Brand profile builder: Share your website. Get a reusable profile covering your products, customers, voice and approved claims, with sources.
    • A folder of eight plain files, from a start file for your AI to a claims list and a change log
    • A tag on every fact, and every claim marked approved, pending or banned
    • A two-sentence diagnosis of your biggest gap, and a list of what's missing and who can answer it
    • A short slice for your next step, if you name one
  • Dieter Rams: Simplify a product, page or form using Dieter Rams’s recorded principles. Keep what serves the purpose and check that the design is honest.
    • Your problem worked on the way Dieter Rams would: their questions, their method, their push-back
    • The answer or the work, in Dieter Rams's voice, using their ideas by name
    • Anything that goes beyond their public record, marked
    • One suggested next step
  • Herb Lubalin: Develop a wordmark, headline or poster through Herb Lubalin’s recorded approach. Make the letters carry one idea and check how well they read.
    • Your problem worked on the way Herb Lubalin would: their questions, their method, their push-back
    • The answer or the work, in Herb Lubalin's voice, using their ideas by name
    • Anything that goes beyond their public record, marked
    • One suggested next step

Tasks you can use it for

  • You have a design system and suspect the code has drifted from it.
  • A brand refresh changed a colour and you are not sure every pair still passes.
  • New screens ship every month and nobody checks them against the rules until a designer notices.

Limits to check before starting

  • Your product has no design system yet and no tokens: start with the Design token and handoff builder skill, then bring this agent in.
  • You only want to know if two colours pass contrast: use the Colour contrast checker skill on its own.
  • You want the code changed for you: this agent never edits code, so give its fix list to a developer.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

  • Start a chat with the agent. In Claude Code, add it as a skill or save it in .claude/agents, then point it at the repo.
  • On the first run, read and approve the design rules it writes from the code. They are saved.
  • Each month, tell it which screens or releases changed. Attach the design file if you have one.
  • Read the drift and the fix list. Make the changes you agree with, then tell the agent which were done.
  • Run it again on the first Wednesday of next month. It tracks the drift count over time.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/monthly-design-system-keeper for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.