Design

---
description: >
  UX/UI design — wireframes, component mapping, interaction design, accessibility.
  Bridge between /spec and /eng for features with user interfaces.
    /design         — full design pass (from spec requirements)
    /design review  — review existing UI against spec or heuristics
---

# Design

Translate product requirements into UI requirements. Define **what the user
sees and does**, before engineering decides **how to build it**. Two gates,
streamed output, rigor preserved.

**This is read-only. No code changes.**

> Follows `rules/integrity.md` — evidence-based, state assumptions (I8),
> neutrality check (I9), forward-looking durability (I10), question inherited
> rules (I11). Shared formatting + Visual Emphasis + Option A inverted-pyramid
> output in `skills/shared/formatting.md`.

---

## When to use

| Signal | Action |
|--------|--------|
| Feature has user-facing screens or interactions | `/design` |
| `/spec` produced UI-related ACs | `/design` |
| Redesigning or improving existing UI | `/design review` |
| Component library or design system changes | `/design` |
| Pure backend, API, or infrastructure work | Skip to `/eng` |

> **Invoke explicitly.** This skill is not auto-triggered. The feature recipe
> includes it as a conditional step: `/spec → /design (if UI) → /eng`.

---

## Complexity routing

| Complexity | Signal | Behavior |
|---|---|---|
| **Small** | 1–2 screens, simple forms or displays, existing patterns | Single response. 1 gate (final). |
| **Medium** | 3–5 screens, some new components, standard interactions | Stream continuously. 2 gates (wireframes, final). |
| **Large** | 6+ screens, new design patterns, complex state machines | Stream, with wireframe gate treated as cascade-risk checkpoint. Still 2 gates. |

---

## Before you start

- Read **Project Profile** in consumer `CLAUDE.md` (component framework, SPA/SSR, mobile).
- If `/spec` ran in context, read the full spec phases directly (no separate
  handoff summary) — ACs map to screens and states; the user-language summary
  on each AC names the screen's purpose.
- Scan existing UI:

  ```bash
  ls src/components/ src/ui/ src/design-system/ app/components/ 2>/dev/null
  ls src/pages/ src/views/ src/app/ app/ pages/ 2>/dev/null
  ls src/styles/ src/theme/ tailwind.config.* 2>/dev/null
  ```

- Build the **Impact Map** (`skills/shared/impact-map.md`) — grounded
  components, existing utilities, missing capabilities.

---

## Output structure — Option A inverted pyramid

`/design` follows the **Inverted-Pyramid Output** pattern in
`skills/shared/formatting.md`. Read that section once; the rules below specify
only `/design`-specific bindings. Mirrors `/spec` 1.9.6: receipts on demand
at Gate 1, full detail on demand at Gate 2, full progress block re-emitted
at Gate 2 (Gate 1 is contiguous with the top emission).

### Progress block

```
/design ══════════════════════════════════════════════════════════════════════════════

  ▸ Phase 1  Inventory & Impact Map
  ○ Phase 2  Layout & Wireframes
  ○ Phase 3  Interactions & Final

══════════════════════════════════════════════════════════════════════════════════════
```

No inline title — topic appears inside `★ THE OVERVIEW` below.

For Small complexity: collapse to a single `▸ Design (streaming)` marker.

For `/design review`: progress block shows `▸ Phase 1 Review Checklist` and
`○ Phase 2 Findings` only — see `/design review` mode below.

---

## Flow

### Phase 1 · Inventory & Impact Map (internal reasoning, no visible output yet)

Build the inventory (existing components, design tokens, layout patterns,
new-vs-reuse map) and the Impact Map per `skills/shared/impact-map.md`.
**Reason fully but don't emit yet** — content held in scratch context for
on-demand expansion at Gate 1 (see §2c). Phase 1 closes with a single-line
transition `✓ Phase 1   ▸ Phase 2  Layout & Wireframes`.

### Phase 2 · Layout & Wireframes — emit, then Gate 1

Phase 2 emits the inverted-pyramid header (TL;DR), then the wireframes
themselves (the primary artifact), then the gate. Receipts (per-screen
inventory, component tree, per-decision rationale) are reasoned through but
**not emitted by default** — they expand only when the user asks (§2c).

#### 2a · Inverted-pyramid header (TL;DR before the wireframes)

```
▎ ★ THE OVERVIEW
▎
▎ {2–4 plain-English lines: how many screens, what they do, what gets
▎ reused, what's new. The reader who only reads this block knows the
▎ overall design choice before they look at any wireframe.}

▎ ⚠ HEADLINE RISKS
▎
▎ • {plain-language risk — accessibility, breakpoint, regression scope}
▎ • {plain-language risk}

▎ ✎ {N} KEY DECISIONS
▎
▎ D1  {plain-language decision question}     →  {answer}
▎ D2  {decision question}                     →  {answer}
```

If there are no design decisions to surface (e.g., entirely re-using existing
patterns), drop the `✎` block. Wireframes follow immediately.

**`★ THE OVERVIEW` plain-English self-check.** Before emitting, run the lines
through the rule from `skills/shared/formatting.md` §Plain-English. The cap is
4 lines and stack-internal terms belong in receipts, not the headline.
Concrete `/design` example:

| Avoid (jargon-heavy, 10 lines) | Prefer (plain, 4 lines) |
|---|---|
| "DocumentPanel gains a third presentation: right-docked. We add a 40px vertical icon rail flush to the right edge, plus a sliding drawer (default 480px, resizable 360–720px). Three breakpoint variants share the same drawer component but differ in how they relate to the document body: push on ≥lg, overlay-with-backdrop on md, full-height sheet on <md. Floating-window mode is preserved verbatim. DocumentPanelDocked is rewritten as DocumentPanelRightDocked; DocumentPanelFloating is unchanged." | "The document panel gets a right-side dock alongside its existing floating mode. A thin icon rail sits flush to the right edge; clicking opens a drawer that pushes the document on big screens, overlays it on medium, and goes full-screen on mobile. The old bottom dock is replaced; floating mode is unchanged." |

Component names (`DocumentPanelDocked`, `DocumentPanelRightDocked`), pixel
specs (`480px default, 360–720px resizable`, `40px rail`), and breakpoint
identifiers (`≥lg`, `md`, `<md`) are precision tools — they belong in
`Receipts — Component Tree` and `Receipts — Per-Decision Rationale`, not in
the headline.

#### 2b · Wireframes (primary artifact, above the gate)

Present **all screen wireframes together**, then gate. Don't serialize
screen-by-screen approval.

Read `skills/design/templates.md` for ASCII wireframe templates (Dashboard,
Form, List, Detail). Pick the closest template and adapt it.

**Rules for wireframes:**
- Pick the closest template and adapt — don't draw from scratch.
- Use box-drawing characters (`┌ ┐ └ ┘ │ ─ ├ ┤ ┬ ┴`), keep lines ≤ 60 chars.
- Use `[ Button ]` for actions, `● ○` for status, `▸ ◂` for nav arrows.
- Use `▼` for dropdowns, `☐ ☑` for checkboxes, `🔍` for search.
- Always show: header/nav, main content, primary action.
- **Layout differences only.** Wireframes show different layouts (collapsed,
  open, mobile, breakpoint variants). Empty / loading / error UI lives in
  the Phase 3 state machine table — don't draw separate state-variant
  wireframes.
- **Stack vertically; no side-by-side ASCII pairs.** When two related states
  need to be shown together (e.g., closed vs. open), stack them vertically
  with a labeled separator (`── CLOSED ──` / `── OPEN ──`). Side-by-side
  ASCII boxes break in narrow terminals — the inter-box whitespace shifts
  and the boxes drift apart visually.
- **No wireframes for unchanged surfaces.** If a presentation mode is
  preserved verbatim from the existing implementation, don't allocate a
  wireframe slot for it. The `[Reuse]` tag in the Phase 3 `══ Screens ══`
  section is its representation; `Receipts — Component Tree` carries the
  `[keep]` tag on the file. A "no design change" prose paragraph is not a
  wireframe.

#### Responsive behavior — box-drawing table (only if breakpoint behavior changes)

Skip if all breakpoints render the same layout. When responsive behavior is
non-trivial, render as a box-drawing ASCII table (same rules as Phase 3 state
machine / a11y tables — fixed-width columns, no in-cell wrapping, shorten
wording before wrapping):

```
  ┌─────────────────────┬──────────────────────────────────────────┐
  │     Breakpoint      │              Layout change               │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ Desktop (>1024px)   │ {default layout}                         │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ Tablet (768–1024px) │ {what changes}                           │
  ├─────────────────────┼──────────────────────────────────────────┤
  │ Mobile (<768px)     │ {stack / collapse / hide}                │
  └─────────────────────┴──────────────────────────────────────────┘
```

#### Gate 1

**Autonomous mode:** Gate 1 is suppressed. Wireframes are reasoned through
and the design proceeds using established patterns. No output pause.

**Interactive mode:**
```
▎ ▸ GATE 1 — approve wireframes?
▎
▎ Reply "go" to accept, or comment on any screen.
▎ For receipts: "inventory", "tree", "why D{n}", or "receipts" (all).
```

*Small complexity (interactive):* Gate 1 is optional — proceed unless a layout is contested.

#### 2c · Receipts — on-demand, not inline

Receipts (per-screen inventory, component tree, per-decision rationale) are
**reasoned through but not emitted by default.** Phase 2's chat output ends
at the gate prompt — header + wireframes + responsive table + gate, ~60–80
lines visible. The reader who trusts the design replies "go" without
scrolling past extra material; the reader who wants to verify expands on
demand.

The gate prompt names the available expansions so the affordance is
discoverable. **Expansion vocabulary:**

| User reply | Expansion |
|---|---|
| `why D{n}` or `D{n}?` | Per-decision rationale for that one D only (2–4 lines) |
| `inventory` | Per-screen Reuse / Extend / New table |
| `tree` (or `component tree`) | Boxed Impact Map per `skills/shared/impact-map.md` |
| `receipts` | All three — inventory, tree, every D's rationale |
| Override (e.g. `D2: 360px`) | Treat as gate decision; expand the affected D's rationale only if user follows up with "why?" |
| `go` | Approve all — proceed to Phase 3, no receipts emit |

**Internal reasoning is unchanged.** Inventory, Impact Map, and per-D
rationale are all fully reasoned before emitting `★ THE OVERVIEW`. They're held
in scratch context and surfaced only when asked. The header content must be
defensible against the held content — emitting on demand should not require
new reasoning.

**Why on-demand, not inline:** receipts duplicate what `/eng` reads from the
in-context design phases anyway. Inline emission rendered ~80–120 extra lines
per gate that most readers skipped past. On-demand keeps header + wireframes
+ gate as the entire visible decision surface (~60–80 lines) while preserving
the right to verify.

#### 2d · Receipts — content rules (when expanded)

When the user requests expansion, the content follows these rules. Same
rigor as before, just deferred emission.

**Per-screen inventory** — single table, one row per screen:

| Screen / View | Existing Component | Action |
|---------------|-------------------|--------|
| {screen from spec} | {matching component or `none`} | **Reuse** / **Extend** / **New** |

The component-library / tokens / layout / form / nav default-pattern table is
**not emitted** — it restates Project Profile.

**Component tree** — render per `skills/shared/impact-map.md` (boxed form,
`├── └──` connectors, `★` marker on the single primary rework target,
status tags `[edit]/[rewrite]/[add]/[keep]/[verify]/[delete]` on every file).

**Per-decision rationale** — for `why D{n}`, emit only that one D. For
`receipts` (all), emit every D. Format:

```
  D{n}  {2–4 lines, hard-wrapped at ~70 chars, plain English — what makes
        this the right answer; what trade-off we're accepting; what we'd
        do instead if circumstances were different}
```

### Phase 3 · Interactions & Final — emit, gate, finish

Phase 3 covers everything after Gate 1: silently reasons about user flow,
state machines, accessibility; emits the high-level inline view; gates final
approval. **Phase 4 is removed** — it had no separate visible event; the
Gate 2 progress-block re-emit is the transition.

#### Internal reasoning (do NOT output)

Reason through these before emitting:

- **User flow** — only if the feature has 3+ screens with non-linear paths.
  Single screens and linear flows have no flow diagram.
- **State machines** — required for components with non-trivial state
  (drag-detach, inline edit, async ops, optimistic updates, multi-step
  flows). Skip universal behaviors (button press feedback, standard form
  validation). Omit the section header if no component qualifies.
- **Accessibility** — feature-specific only. Skip universal standards
  (contrast, focusable buttons, semantic HTML). Surface only:
  - Keyboard alternatives for drag/gesture/hover interactions
  - Focus management for modals, drawers, inline editors, dynamic content
  - Screen reader announcements for live regions, status, async ops
  - Color independence where UI uses color alone
  - Motion sensitivity for animations
  Omit the section entirely if zero feature-specific items apply.

> ▸ **Error UX principle:** Messages describe the user's situation, not the
> technical cause. Recovery actions must be actionable — "try again" with a
> button, not just text.

#### Display sequence at Gate 2

Emit in this order: progress-block re-emit (with all rows updated),
`══ Screens ══` section, `══ States & Flows ══` section (only if non-empty),
then the Gate 2 `▎` block.

```
/design ══════════════════════════════════════════════════════════════════════════════

  ✓ Phase 1  Inventory & Impact Map
  ✓ Phase 2  Layout & Wireframes
  ▸ Phase 3  Interactions & Final

══════════════════════════════════════════════════════════════════════════════════════
  Screens
══════════════════════════════════════════════════════════════════════════════════════

  S1  {screen-name}     [Reuse|Extend|New]   — states: {happy, error, empty, loading}
  S2  {screen-name}     [Reuse|Extend|New]   — states: {happy, error}
  ...

══════════════════════════════════════════════════════════════════════════════════════
  States & Flows
══════════════════════════════════════════════════════════════════════════════════════

  {emit user-flow ASCII box if non-trivial flow exists}
  {emit one box-drawing state machine table per component with non-trivial state}
  {emit feature-specific a11y as box-drawing table (3+ items) or inline lines (fewer)}

▎ ▸ GATE 2 — approve design?                          {interactive mode only}
▎
▎ Problem:  {one-liner from THE OVERVIEW — ≤80 chars}
▎ Next:     /hashb:eng (recommended — implementation planning){· /hashb:research → /hashb:eng (if a UI library decision is still open) — only when flagged}
▎
▎ Reply "go" → chain to default.  "go research" → /research first.  "stop" → no chain.
▎ For full detail: "screens", "states", or "all".
▎ Override: "D-N: {revision}" applies the change before final.
```

**`Next:` rendering rule.** Follow the canonical `Next:` line in
`skills/shared/formatting.md`. The line **always** carries
`/hashb:eng (recommended — implementation planning)` since `/eng` is the
default downstream of `/design`. Append `· /hashb:research → /hashb:eng
(if {the specific library/API decision} is still open)` **only when** the
design surfaced an unresolved UI library / component-library decision —
not as a static menu. If no library decision is open, the line is just
the recommendation, and that is correct.

**Skip rule:** if all three sub-sections (flow, state machines, a11y) have
zero entries, omit the entire `══ States & Flows ══` separator and section.

#### Screens — high-level inline format

One row per screen, fixed-width columns:

```
  S{n}  {screen-name}     [Reuse|Extend|New]   — states: {covered states}
```

- Pad screen-name column to align brackets vertically across all rows.
- States covered: comma-separated subset of `happy / error / empty / loading`.
  The reader sees state coverage at a glance without scrolling state machines.

#### States & Flows — high-level inline format

If user flow exists: small ASCII box (~10–15 lines) with the happy path and
key branches. Use `────▸` for forward flow, `──▸` for branches, `┌─┐ │…│ └─┘`
boxes (not brackets), labels on edges when triggers aren't obvious. Keep
node labels ≤15 chars.

If state machines exist: one **box-drawing ASCII table** per component with
columns `State | Trigger | Next state | UI change | Error recovery`. Same
style as wireframes — `┌ ┬ ┐ ├ ┼ ┤ └ ┴ ┘ │ ─` connectors, fixed-width columns,
one row per cell (no wrapped lines inside cells). Pad each column to its
widest content; if a cell would exceed ~40 chars, shorten the wording rather
than wrap. Markdown pipe tables are **not** acceptable here — they wrap
unpredictably and break alignment for cells like `focus returns to prior form
focus`.

If feature-specific a11y exists: a **box-drawing ASCII table** with columns
`Concern | Behavior` when 3+ items; inline `▸ {concern} — {behavior}` lines
when fewer. Same rendering rules as the state machine — fixed-width columns,
no in-cell wrapping, shorten wording before wrapping.

**Box-drawing table example (the canonical shape):**

```
  ┌──────────────────────┬───────────────────────────────────────────┐
  │       Concern        │                 Behavior                  │
  ├──────────────────────┼───────────────────────────────────────────┤
  │ Rail tab strip       │ role="tablist", aria-orientation vertical │
  ├──────────────────────┼───────────────────────────────────────────┤
  │ Reduced motion       │ prefers-reduced-motion collapses slide    │
  └──────────────────────┴───────────────────────────────────────────┘
```

**Skip any sub-section that has zero entries.** If all three would be empty,
omit the `══ States & Flows ══` separator too (per §Display sequence).

#### State inventory (Large complexity only)

For features with 6+ screens, add a matrix showing which states apply per
screen — emit under `══ States & Flows ══`:

| State | S1 | S2 | SN |
|-------|----|----|----|
| **Empty** | {what shows} | {what shows} | {what shows} |
| **Loading** | {what shows} | {what shows} | {what shows} |
| **Error** | {what shows} | {what shows} | {what shows} |

Mark cells `n/a` for states that don't apply. Include only relevant states.

#### Gate 2 inner block — what to keep, what to drop

- **Keep** — `Problem` and `Next:` (not visible elsewhere).
- **Drop** — count rows (`States: N machines · M flows`, `A11y: N items`)
  — counts are already in the progress-block row above.
- The `▎` block is the gate prompt + brief context, not a summary card.

#### On-demand keywords at Gate 2

Since high-level views emit by default, keywords expand to **full detail**:

| Reply | Expands to |
|---|---|
| `screens` | Full per-screen detail with state inventory matrix and reuse rationale |
| `S{n}` | Full detail for that one screen |
| `states` | Every state machine in full table form + full flow ASCII + full a11y items |
| `all` | Full screens + states + a11y together |
| `go` | Approve, re-emit progress block, immediately invoke the **default** auto-chain target (typically `/eng`). |
| `go research` | Approve, re-emit progress block, immediately invoke `/research` (which itself chains to `/eng` afterwards). |
| `stop` | Approve, re-emit progress block, do NOT chain. Output ends. |
| Override (`D-3: 360px strip`) | Apply, update progress-block row count if changed, re-render the affected line, prompt again |

#### After "go" / "go research" — confirm, chain

Two actions in order, no pause between:

1. Re-emit the progress block with Phase 3 status updated to "approved".
2. Immediately invoke the chain target:
   - `go` → the **default** target (typically `/eng`).
   - `go research` → `/research` (which chains onward to `/eng` itself).

```
/design ══════════════════════════════════════════════════════════════════════════════

  ✓ Phase 1  Inventory & Impact Map
  ✓ Phase 2  Layout & Wireframes
  ✓ Phase 3  Interactions & Final

══════════════════════════════════════════════════════════════════════════════════════

[next skill's Phase 1 progress block emits here — no prose between]
```

**No prose between the progress block and the next skill's invocation.** No
"Design approved... starting /eng now" sentence. The progress block confirms
the design landed; the next skill's own Phase 1 emission carries the handoff
visually.

#### After "stop" — approve only, pause

Same as `go` but skip step 2. Use when the user wants to pause before the
next skill (e.g. to review the design surface, switch context, or run
something else first). Output is just the re-emitted progress block.

---

## Autonomous Mode

When the HANDOFF from `/spec` includes a `Principles:` line, `/design`
runs fully autonomously — both gates are suppressed.

**Behavior:**
- Gate 1 (wireframes) and Gate 2 (final) are skipped entirely.
- All internal reasoning (inventory, impact map, wireframes, state machines,
  a11y) still runs — only the pause-for-approval is removed.
- Design decisions use P2 (architecture) to guide approach selection:
  minimal → reuse existing patterns only; balanced → extend where needed;
  ideal → design from scratch where warranted.
- If a UI library decision is unresolved, check P3 (risk): moderate/aggressive
  → pick the recommended library and proceed; conservative → escalate to user.
- After completion, emit a **transition line** and HANDOFF block:

```
══ /design · {N} screens · {key decision} ═══════════════════════════════════════

HANDOFF → /eng
  Problem:     {one-line}
  Screens:     S1 {name} [Reuse] · S2 {name} [Extend] · ...
  Components:  {N} reused · {N} new
  Decisions:   D1 → {answer} · D2 → {answer}
  Principles:  {forwarded from /spec HANDOFF}
  Spec file:   specs/{slug}.md
```

---

## Next step

**Interactive mode** (`Principles:` absent from HANDOFF):

`/design` chains automatically after Gate 2. The user types `go` once at
Gate 2; that approves the design **and** the chain.

| Recommended | Signal-gated alternative | Trigger |
|---|---|---|
| `/hashb:eng (recommended — implementation planning)` | `/hashb:research → /hashb:eng (if {specific UI library} decision is still open)` | Unresolved UI / component-library decision |

**Auto-chain semantics (both modes):**
- After completion, immediately invoke `/hashb:eng` (or `/hashb:research` if
  library decision is unresolved in interactive mode).
- No prose between `/design`'s completion and the next skill's Phase 1.
- Downstream skill reads the HANDOFF block + spec file.

**Escape hatch (interactive):** reply `stop` to approve design without chaining.

---

## `/design review` mode

Review existing UI against the spec or general heuristics. Use when the UI is
already built and needs evaluation.

#### Review checklist — markdown table

| Category | Check | Status |
|----------|-------|--------|
| Spec compliance | Does UI match the spec requirements? | pass / gaps |
| State coverage | All states handled (empty, loading, error, overflow)? | pass / gaps |
| Accessibility | Keyboard nav, screen readers, contrast, focus management? | pass / gaps |
| Responsive | Works at all declared breakpoints? | pass / gaps |
| Consistency | Uses existing design patterns and components? | pass / deviations |
| Interaction feedback | Every action has visible feedback? | pass / gaps |

Output: findings in the same format as `/review` (**BLOCKING** / **WARNING** / **SUGGESTION**).

---

## Rules

| Rule | Why |
|------|-----|
| Read-only | No code changes. Design is a specification artifact. |
| Two gates (interactive) | Gate 1 (wireframes), Gate 2 (final). Small skips Gate 1. Autonomous mode suppresses both — emits transition line instead. |
| Three phases | Phase 1 silent (Inventory), Phase 2 emits Gate 1 or auto-proceeds (Wireframes), Phase 3 emits Gate 2 or transition line (Interactions & Final). Receipts expand on demand (interactive): `inventory` / `tree` / `why D{n}` / `screens` / `states` / `all`. |
| Inverted-pyramid output | Decision-grade summary above wireframes; wireframes above Gate 1; receipts on demand below `══` separators. See `skills/shared/formatting.md`. |
| Progress block re-emits at Gate 2 | Re-emit the full `══`-framed progress block before Gate 2 with `✓` markers and per-row status. Gate 1 doesn't re-emit — it's contiguous with the top emission. No orphan `✓ Phase 2 ▸ Phase 3` transition line — the re-emit is the transition. The Phase 1 → Phase 2 single-line transition stays (Gate 1 doesn't re-emit, so it's the only transition signal). |
| Internal reasoning, signal-only output | Inventory, edge-case enumeration, verification all run internally. Output only what carries signal. Phase 3 omits flow / state-machine / a11y sub-sections that have no feature-specific content. |
| Present all wireframes together | Don't serialize screen-by-screen approval. User comments on any. |
| Wireframes show layout, not state | Layout differences (collapsed/open/mobile/breakpoint) get wireframes. Empty / loading / error UI lives in the state machine table. |
| State machine = source of truth | One **box-drawing ASCII table** per component with non-trivial state (`State | Trigger | Next state | UI change | Error recovery`). Covers states, transitions, error recovery, non-obvious interactions. Skip the section header if no component qualifies. Markdown pipe tables are not acceptable — cells like `focus returns to prior form focus` wrap and break alignment. |
| Feature-specific accessibility only | Skip universal standards. Surface only keyboard alternatives, focus management, screen reader announcements, color independence, motion sensitivity specific to this feature. Render as a **box-drawing ASCII table** (`Concern | Behavior`) when 3+ items; inline `▸ concern — behavior` lines when fewer. Same rendering rules as the state machine. |
| Map to spec | Every screen traces back to an AC. No orphan screens. |
| Plain English in prose | Use the simplest words a working designer/engineer would use mid-task. Domain terms in receipts, not headlines. Keep technical precision for component names, breakpoint values, ARIA roles, design-token names. See `skills/shared/formatting.md`. |
| Reuse first | Check existing components before designing new ones. |
| No implementation details | "Show error message", not "render `ErrorBanner variant='destructive'`." That's `/eng`'s job. |
| Auto-chain after Gate 2 | `go` chains to the **default** Next-step skill (`/eng`). `go research` chains to the alternative (`/research → /eng`). `stop` approves without chaining. No prose between `/design`'s post-approval progress block and the next skill's Phase 1 emission. Mirrors `/spec` gate chain semantics. |
| Recommend, don't list | Follow the canonical `Next:` line rule (`skills/shared/formatting.md` → "Canonical `Next:` line"): use `/hashb:` namespace, mark the recommended option `(recommended — {reason})`, append signal-gated alternatives only when triggers detected (e.g. `/hashb:research → /hashb:eng (if a UI library decision is still open)`). Don't render a static menu — a `Next:` line with no alternatives means design saw no library or scope concerns. |