Experience design pack reference

Every skill in the Experience design pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

The experience around a product: the structure people navigate, the content and interface words they read, the components they use, and the service behind it all.

Skills

content-design

Write a content spec for a page or journey from user needs — user-need statements ("As a… I need… so that…"), the questions the page must answer in priority order, the page structure, a plain-language rewrite at a target reading level with a before/after readability check, and an explicit list of what to cut and why.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user wants a content spec, content design, "rewrite this page in plain English", "what should this page say", "our page is too long and nobody reads it", or content for a service or journey.

Needs: Python 3 for its scripts (standard library only).

A good result:

• Every need names a specific reader, a need and an outcome, with an evidence tag.
• Questions are ranked, and the page order follows the ranking. The top question is answered in the first two sentences.
• Headings are in the reader's words.
• The draft keeps every fact from the source, and every change of meaning is flagged. Plain language never changes a rule.
• No sentence over 25 words in the draft, and the script's before/after numbers are reported as it printed them.
• The cut list accounts for everything removed, with a reason each.
• Nothing is invented. Fees, deadlines, eligibility and contact details not in the source are {placeholder}s listed in open questions.

Hands off to: ux-writing when the page includes a form, flow or interactive component.

Not for:

• Button labels, errors, empty states and other interface strings — that's ux-writing
• A step-by-step setup guide, walkthrough or API reference — that's guide-builder
• Where pages live and how the navigation groups them — that's information-architecture
• The persona's whole path and emotions across stages — that's user-journey-map

design-system-spec

Write a design system component spec — purpose, anatomy, variants, every state (default, hover, focus, active, disabled, error, loading), the design tokens each part uses by name, behaviour, content rules, accessibility (keyboard, focus order, ARIA role, contrast, target size) cited to WCAG 2.2 criteria, do/don't examples, and the open questions engineering must answer.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user wants a component spec, design system documentation, "spec out this button / modal / text field", a component's states and tokens, or a design-to-engineering hand-off for a component.

A good result:

• Purpose and boundary are stated, including when to use a different component.
• Anatomy parts are numbered and the numbers are reused in the state and token tables.
• Variants sit on independent axes, each with a use case. No speculative variants.
• Every applicable state is specified, including focus, disabled, error and loading. Focus differs from hover and isn't shown by colour alone.
• Tokens are named, never raw values. Proposed tokens are tagged and listed as open questions.
• Accessibility covers keyboard, focus, role and name, contrast and announcements, and every WCAG citation is one from the reference list with the right number and name.
• Open questions for engineering each name the decision they block.
• Nothing is invented. Token names, brand values and platform constraints not in the input are tagged [proposed token] or [assumption].

Hands off to: accessibility-audit when the component is built; ux-writing when the content rules are set and the product needs the actual strings.

Not for:

• Auditing a built page or component against WCAG — that's accessibility-audit
• Writing the product's interface strings for a flow — that's ux-writing
• Capturing brand colours, fonts and logo — that's brand-kit
• Page-level structure or navigation — that's information-architecture

information-architecture

Design the information architecture for a product or site — a content inventory grouped by how users think, labels in their words, a navigation model split into global, local and utility nav, an indented sitemap plus a Mermaid diagram, a label rationale table, the findability risks, and the card-sort or tree-test plan that would validate it.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user wants a sitemap, IA, navigation structure, menu design, "reorganise our help centre", "where should this page live", or says users "can't find anything".

A good result:

• The inventory exists and comes first. Every item in the sitemap traces to an inventory row; every cut is listed, not silently dropped.
• One organising scheme per level, named. Mixed schemes are flagged with the reason.
• Labels are user words with a recorded reason. Every global and local label appears in the rationale table with its evidence tag.
• Global nav has 5–7 items; utility items are not in it.
• Top tasks are one click from the landing page and depth is 3 levels or fewer for weekly tasks, or the exception is stated.
• The tree and the Mermaid diagram match node for node, and the Mermaid renders.
• Findability risks are named with severity and a mitigation.
• The validation plan has tasks written without label words, correct destinations, a threshold, and what result would change the design.
• Nothing is invented. Content items, audiences and evidence not in the input are tagged [inferred] or [assumption].

Hands off to: content-design when the structure is agreed and a key landing page needs its content; ux-writing when the nav labels are settled and the menus and buttons need final strings.

Not for:

• The steps and emotions of one persona reaching an outcome — that's user-journey-map
• What one page should say and in what order — that's content-design
• The exact wording of menu items, buttons and errors across a flow — that's ux-writing
• The requirements and scope of a new feature — that's prd-draft

service-blueprint

Build a service blueprint — per step, the evidence the customer sees, the customer's actions, frontstage staff and system actions, backstage actions, and support processes, separated by the lines of interaction, visibility and internal interaction, with fail points, wait times and owners marked — as a table plus a Mermaid diagram and the ranked fixes.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user wants a service blueprint, "what happens behind the scenes when a customer does X", to find where a service breaks or stalls, or to take a journey map down to the people, systems and handoffs that deliver it.

A good result:

• One scenario, one customer type, with a trigger and an end state, named in the title.
• All five lanes and all three lines are present. Evidence, customer, frontstage, backstage, support; interaction, visibility, internal interaction.
• Every frontstage and backstage action has an owner (role or team), or is flagged as unowned.
• Every handoff across teams is marked, and fail points ⚠ and waits ⏱ are marked where they occur, with durations or [estimate].
• Customer pains are traced to backstage or support causes.
• 2–3 fixes are ranked and named, stated as outcomes, each with an owner and the lane it changes.
• The table and the Mermaid diagram match, and the Mermaid renders.
• Nothing is invented. Teams, systems, SLAs and durations not in the input are tagged [assumption] or [estimate], and the evidence level is declared at the top.

Hands off to: user-journey-map when there is no journey map and the customer's stages and emotions aren't known; prd-draft when a ranked fix is accepted as committed work.

Not for:

• One persona's stages, emotions and pains, frontstage only — that's user-journey-map (run it first if the customer side isn't known)
• The technical architecture of the systems in the support lane — that's architecture-diagrams
• Requirements for a fix the blueprint found — that's prd-draft

ux-writing

Write the interface copy for a flow or component — buttons, labels, hints, errors, empty states, confirmations, loading and success messages — as a string table where each string has its context, a character budget, a recommended version and one variant, with error messages that say what happened and what to do next, and a terminology list so the same thing has the same name everywhere.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user wants UI copy, microcopy, button text, error messages, empty states, "write the strings for this screen", or "our wording is inconsistent".

A good result:

• Every slot in the flow has a string, including each error, the empty state, loading and success. No "TBD".
• Every string shows its character count against its budget, and none is over.
• Every error says what happened and what to do next, names the field or object, and blames no one. No error codes on their own.
• Buttons are verb + object. No "Submit", "OK" or "Yes" on a primary action.
• Each string has one labelled variant and a recommendation.
• The terminology list exists, and every string obeys it. One concept, one term.
• The voice matches the given brand or the stated default.
• Nothing is invented about the product. Limits, prices, timings and policies not in the input are left as {placeholder} and listed in open questions.

Hands off to: accessibility-audit when the strings are built into a working UI.

Not for:

• Deciding what a whole page or journey should say from user needs — that's content-design
• A help article, setup guide or walkthrough — that's guide-builder
• Capturing the brand's voice and visual identity — that's brand-kit
• Checking a built UI against WCAG — that's accessibility-audit
• The full component spec (states, tokens, behaviour) — that's design-system-spec; this skill can supply its content rules

Included from core

Installed with this pack. Details: Core pack reference.

• brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.
• context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.
• council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."
• doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.
• output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.

Edit this page on GitHub · View source