design-guidelines

Create canonical design guidelines and acceptance criteria for a project's visual and interaction design.

Updated May 4, 2026
One-click install
npx skills add https://github.com/antstanley/skills --skill design-guidelines-antstanley
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-guidelines
Source: https://github.com/antstanley/skills/tree/main/plugins/spec-creator/skills/design-guidelines
Command: npx skills add https://github.com/antstanley/skills --skill design-guidelines-antstanley

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams lack a single canonical record of adopted visual and interaction rules, so agents and developers build inconsistent screens and cannot tell settled design policy from accidental implementation details. ## Core Features & Use Cases - Canonical design pages: Writes .specs/design-guidelines.md or thin per-package deltas that separate adopted policy, observed implementation, and verified enforcement. - Structured discovery: Runs greenfield or existing-project discovery with focused question rounds, producing a reviewable summary before any policy is written. - Accessibility and acceptance criteria: Defines a Design definition of done with WCAG 2.2 targets, evidence labels (verified, failed, not tested, not applicable), and reusable evidence records. - Use Case: Adopting an existing app's design system into specs: the skill inspects tokens, themes, and components, confirms intent on inconsistencies, and documents settled rules while listing implementation gaps in Open questions. ## Quick Start Ask the agent to create design guidelines in .specs for your project, describing the audience, platforms, and any existing brand or UI assets.

Frequently Asked Questions about design-guidelines

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I document an existing design system in a spec?

Run the existing-project adoption path: the skill inspects tokens, themes, components, and representative screens, summarizes observed choices with evidence, then asks focused follow-up questions to confirm intent before writing settled rules into .specs/design-guidelines.md.

How do I write design guidelines for a new project with no UI?

Use greenfield discovery: the skill asks one to three focused questions about audience, brand, platforms, and constraints, presents a reviewable summary, then writes adopted policy while explicitly stating that UI, tokens, and enforcement are not yet implemented.

Does it support accessibility requirements like WCAG 2.2?

Yes. For web projects without a settled target it recommends WCAG 2.2 Level AA, records applicable keyboard, contrast, semantics, and forms requirements, and defines acceptance evidence. It never claims conformance from screenshots or automated scans alone.

Can it handle different design rules per package in a monorepo?

Yes. Shared rules live in the global .specs/design-guidelines.md, while genuine package differences go into a thin per-package delta page that links back to the global page and contains only scoped differences with rationale.

What are the limitations of design evidence records?

Evidence records only capture observations against adopted requirements; they do not change policy or the UI. Missing tools leave checks marked not tested, stale evidence is preserved as history rather than counted as a current pass, and a deferral never turns a failure into conformance.