Skills
Claude skills for UX and product design workflows.
The Vois design system skills here (vois-tokens, vois-patterns, vois-components, vois-dataviz, righter) are part of Vois design intelligence, the name for the whole Vois suite. Skill and folder names do not change.
Install
npx skills add ommakes/Skills
Design System Skills (Read in Order)
These skills work together as a stack, and each one works standalone — no orchestrator or MCP server required. Read them in this order when building UI: vois-patterns → vois-components → vois-tokens (with vois-dataviz between patterns and components for any screen that shows data), with righter consulted throughout for copy. Any telemetry tool call a skill mentions (vois_record_pattern_choice, vois_record_component_choice, vois_record_rule_usage, vois_get_microcopy) is optional — if the tool isn't available in your environment, the skill degrades gracefully and the instruction is simply skipped.
Each skill's data/*.json is the canonical source for its rules — references/*.md restates them for readability and worked examples, but the JSON wins on conflict. scripts/check-rule-sync.mjs enforces that the two never silently disagree, and runs in CI alongside scripts/check-verification.py (every rule in vois-tokens, vois-dataviz and the vois-components lookalike table declares verification, and each detector it names exists in code and each detector in code is claimed by a rule; it needs node) and vois-tokens' own detector regression suite (see .github/workflows/design-system-checks.yml).
Vois Patterns
Structural decision trees and UI patterns that tell agents what to build before implementing it. Covers container types (forms, tables, dialogs, settings pages, pricing pages), state management (view/edit), and routing to righter skill for all microcopy. Marketing pages (landing pages, homepages) have their own taste rules: one idea per section, three blocks max, detail behind a link, no dividers. Tables cover simple vs complex, how a row opens (drawer by default, full page for big records), where editing happens, selection and bulk actions, and loading, empty, and error states.
Read first to determine the structure and architecture of what you're building.
Use when: building a new page, form, table, modal, or feature and need to decide on the container type and layout pattern before writing code.
Ships as SKILL.md plus a references/ folder split by pattern (detail pages, forms, dialogs, settings pages, etc.) — SKILL.md is the decision tree and index, references hold the full path detail.
→ vois-patterns/
Vois Components
Component selection rubrics organized by job-to-be-done. Covers 20 high-ambiguity component pairs (Dialog vs Drawer, Toast vs Banner, Select vs Combobox, etc.) with decision trees and "why not X" reasoning.
Read second (after vois-patterns determines structure) to pick the right specific component for each job.
Use when: you need to decide between similar components — which one actually fits what you're building? Optionally calls vois_record_component_choice after selecting, if that tool is available.
Ships as SKILL.md plus a references/ folder grouped by job (forms, navigation, display, selection, overlays, feedback) — SKILL.md holds the quick-reference table and job index, references hold the full decision trees.
→ vois-components/
Vois Dataviz
Data visualization and dashboard guidance, usable for both building and reviewing. A chart-selection decision tree (12 viewer jobs to 49 results), do's and don'ts for 14 principles, 114 checkable rules, a 48-form chart catalog covering the 23 families in the UX Magazine data viz playbook, six dashboard templates, and 57 pieces of Mobbin evidence marked adopt or watch-out. Everything is machine-readable JSON, with a chart spec checker, a code detector for Recharts and shadcn chart code, and a review protocol so agents can audit and improve existing dashboards.
Read after vois-patterns decides the screen is a dashboard or contains charts, and before vois-components.
Use when: building or reviewing a chart, KPI tile, sparkline, heatmap, dashboard, date-range or filter row, or the loading, empty and error states of any of them. Optionally calls vois_record_component_choice and vois_record_rule_usage, if those tools are available.
Ships as SKILL.md plus data/*.json (canonical), generated references/*.md, and scripts/ with tests.
→ vois-dataviz/
Vois Tokens
A skill for AI coding agents (Cursor, Claude Code, v0) that encodes design system rules — spacing, typography, color tokens, component patterns, animation, and accessibility — so agents produce consistent UI without guessing.
Read third (after patterns and components are locked in) to implement with the correct tokens, spacing, and styling rules.
Use when: building components or pages that should conform to a design system using shadcn/ui, Tailwind v4 or StyleX, and Motion.
Tunes within the design system's guardrails using taste dials (VARIANCE/MOTION/DENSITY, 1–10, defaulting to 5/4/5 if none are supplied) — dials adjust degree, never override safety, accessibility, or hard token rules. Flags DS-SLOP-* anti-tells (centered-hero, AI-gradient backgrounds, uniform three-card grids, eyebrow overuse, zigzag sections, spec-sheet tables) as advisory warnings, and enforces the redesign no-silent-changes contract when working on existing UI.
Ships as SKILL.md plus a references/ folder split by topic (spacing, color, typography, components, accessibility, animation, CSS architecture, data tables, anti-slop, etc.) — read only the reference file(s) relevant to what you're building instead of the whole skill. Marketing surfaces get their own type scale and spacing ratios (references/marketing-type-and-spacing.md). Also ships a zero-dependency scripts/ detector that mechanically checks the regex-verifiable subset of the rules (including DS-SLOP-002 and the table-wrapper check DS-TABLE-001) and can run as a per-edit hook in Claude Code, Cursor, or Codex — complementary to, not a replacement for, the GitHub-integrated token-drift app.
→ vois-tokens/
Righter
UX writing skill. Reviews existing UI copy or writes new copy from scratch applying a defined set of principles. Covers UI components, error messages, microcopy, and transactional product emails. If a vois_get_microcopy MCP tool is available, calls it first to check workspace-specific overrides before writing. Otherwise it applies the skill's principles directly.
Every principle and error-message rule carries a stable id for cross-referencing from other skills. The reading target adapts to the audience through three tiers (consumer is the default at ARI 6 or lower, professional at 10, technical at 12), and only the reading target changes: every other principle still applies. Principle 18, accessible-copy, covers labels, link text, and status that work without the visuals. data/components.json adds empty-state and permission-prompt for non-error surfaces. Reference files cover tone by context, a voice chart template, and a Figma review workflow, and load only when relevant. Ships with scripts/ari.mjs (deterministic ARI/reading-level scoring with an optional --target, in place of computing the formula by hand), data/rhetorical-devices.json (9 literary/rhetorical devices scoped to copy that's allowed personality: marketing surfaces, taglines, empty states, feature names, never error messages or system copy), and evals/cases.json (a fixed regression corpus for checking that edits to principles or data files don't silently change what the skill flags). See righter/CHANGELOG.md for version history.
Read throughout. Vois Patterns and Vois Components route to this skill for all copy: button labels, error messages, field descriptions, helper text, status labels, empty states, toasts, confirmations.
Use when: writing, reviewing, or improving any UI copy, error messages, button labels, tooltips, empty states, onboarding copy, form text, product emails, or marketing-page copy. Marketing slots (hero, section head, card, button) have word limits in data/marketing-limits.json, checked by scripts/check-slots.mjs.
→ righter/
Auxiliary Skills
Metrics Tagging
Analyzes UI mockups or screenshots and generates a complete analytics event taxonomy table for handoff to a tag implementation team — including task-level flow completion events (start/end event pairs linked by a shared flow_id), cascading and high-impact input flagging, and coverage gaps across screen states.
Use when: planning what to track in a flow, creating a tagging spec for handoff, tagging a multi-step create/edit/delete task, or auditing a screen for analytics coverage.
Ships as SKILL.md plus a references/event-registry.md starter template — a project-local ledger the skill reads from and appends to so event names stay consistent across sessions instead of drifting screen to screen. See metrics-tagging/CHANGELOG.md for version history.
→ metrics-tagging/
Conversion Patterns
Condition-gated patterns for paywalls, checkout, retention, referral, and pricing-page CTAs, drawn from published A/B test case studies. Every rule is a single result from one company, so the skill makes you name your funnel stage, trust level, and product type before it lets you pick a lever. Two modes: diagnose a new ticket, or audit an existing screen. It always ends by handing structure to vois-patterns, copy to righter, and a success metric plus kill condition to metrics-tagging.
Use when: a ticket touches paywalls, trial structure, checkout, upsells, streaks or habit loops, referral flows, or pricing-page CTA and price display. For the layout of a pricing page itself, use vois-patterns (PATH-F) alongside it.
Ships as SKILL.md, data/conversion-rules.json (32 rules across 6 categories), and scripts/check-rule-sync.mjs to keep the two in sync. See conversion-patterns/CHANGELOG.md for version history.
→ conversion-patterns/
Design Ask
Unpacks poorly written Jira or Azure DevOps tickets into design-relevant framing. Identifies what design work is actually being asked for, flags when tickets prescribe a UI solution instead of describing a user need, and produces a ready-to-use list of questions to bring to the PM before starting.
Use when: a ticket is unclear, overly prescriptive, missing context, or you need to scope the design work before touching anything.
→ design-ask/
Onboarding Flow
Designs new onboarding flows or evaluates/critiques existing ones — signup sequences, setup checklists, first-run wizards, personalization quizzes, permission priming, paywalls — for SaaS/web products and consumer/mobile apps. SaaS and consumer onboarding fail for opposite reasons if you cross the patterns, so the skill picks the right shape (companion checklist vs. linear sequence) before designing or evaluating anything, requires naming the product's activation event before sequencing screens, and pulls current visual reference from Mobbin when available. Routes all UI copy to righter and all structure/styling decisions to the vois skills (vois-patterns → vois-components → vois-tokens).
Ships as SKILL.md plus two shape-specific references/ files (saas-onboarding.md, consumer-onboarding.md), a data/onboarding-rules.json canonical rule set (18 rules, each tagged MUST or SHOULD: 5 universal, 6 SaaS, 7 consumer), its own scripts/check-rule-sync.mjs to keep the rules and worked examples in sync — same convention as vois-patterns' own rule-sync script — and an evals/cases.json regression corpus of worked flows. See onboarding-flow/CHANGELOG.md for version history.
Use when: designing a new onboarding flow from scratch, or reviewing/auditing an existing one from screenshots or a description — signup sequences, setup checklists, first-run wizards, personalization quizzes, permission priming, or paywalls.
→ onboarding-flow/
Designer IC Assessment
Runs a structured behavioral interview to assess an IC designer across five categories and 19 competency areas, including AI fluency. Produces a competency-by-competency narrative, a scores-at-a-glance table, and a CSV export for Notion / FigJam handoff. Supports both designer self-assessment and manager assessment as independent sessions.
Use when: running a designer self-assessment, a manager assessment, or preparing for an IC level calibration conversation.
→ designer-ic-assessment/
GTM Positioning
Framework for B2B product positioning, GTM strategy selection, and website messaging. Covers three positioning strategies (mature category, emerging category, new category), five GTM types (Vertical through Platform), page-by-page website messaging guide, persona-based messaging matrix, marketing assets by awareness stage, and value prop variations by awareness stage. Based on the Fletch framework by Anthony Pierri.
Use when: positioning a product, choosing a GTM motion, writing homepage or website copy, crafting messaging for different buyer personas, planning content by awareness stage, or writing ads and landing page copy.
→ gtm-positioning/
Longform
Applies a consistent persona and voice to long-form writing: essays, blog posts, LinkedIn and newsletter pieces, and the narrative sections of a GTM page. Built on Nancy Duarte's storytelling structure (contrast, audience-as-hero, "what is" to "what could be") fused with Wes Kao's operator-voice frameworks (BLUF, Minimum Viable Backstory, signposting, Most Obvious Objection, named frameworks). A third reference file maps rhetorical devices (metaphor, anaphora, epithet, etc.) onto those structural beats and extends phonaesthetics from word-level sound (Righter's job) to sentence- and paragraph-level rhythm. See longform/README.md for the full breakdown and longform/CHANGELOG.md for version history.
Three-layer split with the other writing skills: gtm-positioning owns page/asset structure, this skill owns how the argument builds, Righter owns sentence mechanics. Hands the finished draft to Righter's scripts/ari.mjs and data/weakeners.json check before calling a piece done.
Use when: writing, drafting, editing, or reviewing an essay, blog post, thought leadership piece, LinkedIn post, or newsletter, or writing the Problem/Benefit sections of a GTM page.
→ longform/
Case Study
Writes or reviews portfolio case study teasers. Write mode asks one multiple choice question at a time (recommended option first) and builds a teaser with a plain headline, a proof line with a baseline, first-person contributions and a regret line, with no generic section labels. Review mode critiques an existing teaser or full case study and returns edits with the principle behind each. Routes to righter for sentence mechanics only. Optionally reads persona.md, voice.md and rhetoric-and-rhythm.md (the longform skill has all three) so drafts sound like you, and offers a five-question setup if you have none. See case-study/CHANGELOG.md for version history.
Use when: writing a case study teaser for a role, reviewing or tightening an existing case study, or checking that a result actually proves its goal.
→ case-study/
Changelog Writer
Writes external-facing changelog and release note entries in a pithy, tastefully sassy, occasionally clever voice that makes software updates fun to read without burying what actually shipped. Modeled on what Slack, Basecamp, Linear, Raycast, and Tumblr do well. Ships with check-all.mjs and friends — scripts that check every draft for structure, sass budget, voice, length, and cadence before it's published.
This skill is for external/end-user changelogs — if the audience is internal engineering or the changelog needs to double as a searchable technical record, skip this skill and use a precise, Stripe-style format instead.
Use when: writing, drafting, or reviewing a changelog entry, release notes, "what's new" post, or product update announcement for end users, or turning a raw list of shipped features/fixes into public-facing copy.
→ changelog-writer/
Design Rationale
Help designers articulate their design decisions using cognitive science, behavioral psychology, and platform standards as the language — not intuition or preference. Includes a comprehensive library of 28+ named principles across three tiers (cognitive/behavioral laws, platform standards, applied patterns) and 15+ real-world product precedents organized by moment type (onboarding, navigation, conversion, errors, empty states, offboarding).
Use when: explaining a design decision in a critique or design review, preparing to defend a design choice against pushback, auditing a screen for principle alignment, or evaluating whether a decision is truly irreversible.
→ design-rationale/
UX Research Skills
Four skills that work together as a research team — programming
surveys, synthesizing quant + qual feedback, and writing stakeholder
reports — plus a router that orchestrates the loop between them. Unlike
the design system stack below, this one includes an actual orchestrator
skill (research-loop) that can route backward when a downstream skill
can't proceed cleanly, not just forward.
Full breakdown, the file structure it maintains, and testing
instructions: ux-research/README.md.
Version history: ux-research/CHANGELOG.md.
Use when: programming a survey, making sense of raw survey/feedback
data, or writing up UX research findings for stakeholders.
The Design System Stack
The four design system skills form a complete pipeline:
1. vois-patterns
↓ (structures → container types)
2. vois-components
↓ (selects → specific components for each job)
3. vois-tokens
↓ (implements → tokens, spacing, accessibility)
4. righter (consulted throughout for all UI copy)
Read them in order. Each skill assumes you've read the previous one and points forward to the next. No orchestrator or MCP server is required — each skill works standalone.
- Patterns answers "what structure am I building?"
- Components answers "which component for this job?"
- Tokens answers "how do I implement this correctly?"
- Righter answers "what words go here?" (consulted at every step)
Design Previews (for Claude Design)
design-previews/ is a rendered, static HTML/CSS companion to the four design system skills — 33 self-contained preview files (foundations, highest-confusion component pairs, page-level patterns, and anti-pattern demonstrations) built for Claude Design (claude.ai/design), a visual design-system browser, not a coding agent. Run design-previews/scripts/validate-previews.sh for the current per-folder counts rather than trusting this prose as file counts change.
This is not a skill. It has no SKILL.md and isn't listed in skills.json or installed via npx skills add — it's a rendered artifact derived from the skill content above, kept in this repo because it's versioned alongside it. See design-previews/README.md for what's sourced directly from the skills vs. invented to fill a documented gap, and how to sync it into a live Claude Design project.
Evaluation Harness
vois-eval/ is a set of scenarios for checking whether a screen an agent generates with these skills actually followed the decision layer — vois-components' job trees and vois-patterns' path trees — not just whether it used the right tokens. Each scenario is drawn from an existing decision tree's condition/recommendation rather than a new invented format; the 55 scenarios are checked by hand, and score categories are defined without weights until they have been run enough to know where drift concentrates. A separate runner, vois-eval/run/run.mjs, builds screens with the claude CLI with the skills on and off and scores them with scripts; CI checks its committed results for a drop in the skills-on pass rate. See vois-eval/README.md.
vois-teams/ is how a team changes the base rules for itself without forking them. A team override file can add a rule, tighten a limit the base marks as tunable, or choose a value inside a range the base leaves open. It cannot loosen anything. A change every team should inherit goes through a base-change proposal instead. There is a validator and tests, and the hook does not read the overrides yet. See vois-teams/README.md.
This is also not a skill, for the same reason design-previews/ isn't — it's a testing artifact for the skills above, not instructions an agent reads mid-build.
Quick Links
Maintained by: Om Suthar
Last updated: 2026-09-26
