# Design

> Design front door — interview first, then route to the right design skill. Use when the user says "/design", "design something", "I want to design an app/screen/feature", "make this beautiful", "which design skill should I use", or gives a design request too vague to route (no clear target, stage, or deliverable). Asks 3-4 multiple-choice questions (what/where/constraints/depth), then invokes the…

- **Type:** Skill
- **Install:** `agentstack add skill-dndungu-agent-skills-design`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [dndungu](https://agentstack.voostack.com/s/dndungu)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [dndungu](https://github.com/dndungu)
- **Source:** https://github.com/dndungu/agent-skills/tree/main/design

## Install

```sh
agentstack add skill-dndungu-agent-skills-design
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# design — the interview-then-route front door

One job: turn a vague design wish into a precisely-invoked design skill.
Never do design work here — this skill only interviews and dispatches.

## Step 0 — Read first (silently, before any question)

1. If the user named a repo, resolve it via `~/.claude/repo-map.md`; else
   note the cwd repo. Peek for an existing design system
   (`docs/design/*/DESIGN.md`, `*Theme*.swift`, project design skills) —
   its existence changes the routing default and the questions you ask.
2. Skip any question whose answer is already in the user's message or in
   the repo. Never ask what you can infer; the interview is 3-4 questions
   MAX, one AskUserQuestion call.

## Step 1 — Interview (one AskUserQuestion call, ≤4 questions)

Ask only the questions still open after Step 0, drawn from this bank:

- **Goal** (always, unless stated): What are we doing?
  a) Design something new — app, feature, or screen (mockups first)
  b) Improve existing screens — they work but look off
  c) Choose or iterate a theme/palette on an existing component kit
  d) Turn approved mockups into production UI with fidelity checks
  e) Liquid Glass adoption/refactor
  f) App Store presence — screenshots, listing, review prep
  g) Review/critique an existing app's design (pixels + source, report)
  h) Design the experience — journeys, flows, navigation, habit loops
  i) Review an existing app's UX — taps, flows, dead ends, habit ethics
- **Platform** (always, unless obvious from the repo — a SwiftUI repo is
  iOS, a Next/Vue repo is web): native iOS, web, or both. This selects the
  column in the routing table below; goal and platform are orthogonal.
- **Target**: which repo/app? Offer the repo-map's likely candidates as
  options plus Other.
- **Constraints** (multiSelect): existing brand/design system is sacred ·
  full visual reset allowed · dark-mode-first · iOS 26+ (Liquid Glass ok) ·
  must ship this week (speed over depth)
- **Depth**: quick single pass, or full workflow with direction anchors,
  verify loops, and iteration gates?

## Step 2 — Route (invoke exactly one skill via the Skill tool)

| Answer | Route (iOS) | Route (web) | Args to pass |
|---|---|---|---|
| (a) new design | `/ios-design` | `/web-design` | repo path + goal + constraint answers ("full reset" vs "extend system", tone hints, depth) |
| (b) improve existing | `/swiftui-craft` | `/web-craft` | repo path + the screens/views named + "review then apply" or "review only" |
| (c) theme A/B | `/skin-gallery` | `/skin-gallery` | repo path + kit location |
| (d) mockups → production | `/design-fidelity` | `/design-fidelity` | mockup dir + target |
| (e) Liquid Glass | `/liquid-glass` | (iOS only) | repo path + adopt vs refactor vs review |
| (f) App Store | `/app-store` | (iOS only) | mode hint: OPTIMIZE / PREPARE / AUDIT |
| (g) design review | `/ui-review` | `/ui-review` | repo path + screens + PLATFORM + "can it run?" answer |
| (h) experience/UX | `/ux-design` | `/ux-design` | repo path + hero-job hint + existing journeys doc if any |
| (i) UX review | `/ux-review` | `/ux-review` | repo path + journeys doc + PLATFORM + "can it run?" answer |

The review skills (g, i) and the experience skills (d, h) are one skill with
two lanes — always pass the platform in the args so the routed skill picks
the right capture and rubric. Only (e) and (f) are iOS-only; a web request
there routes to /web-craft (glass-style effects) or is out of scope.

Compose the args string from the interview so the routed skill can skip
its own redundant questions — pass the answers, not a summary of them
(e.g. `Reimagine the home screen of ~/Code/foo — full palette reset,
dark-first, full workflow with anchors`).

Edge cases:
- Goal (a) but a design system exists and "brand is sacred": still
  /ios-design or /web-design — both extend existing systems (Phase 0); say so.
- Web goal (a) where the deliverable is a STANDALONE page, deck, or a design
  system to browse rather than product code: that is Claude Design via
  DesignSync, not /web-design. Say which and why.
- Goal (b) but the repo has NO design system and screens are beyond
  polish: offer the user the (a) path before routing — polishing chaos
  wastes /swiftui-craft.
- Mixed goals: route the FIRST deliverable only; name the follow-on skill
  in one sentence for after it lands.

## Output format

After the routed skill is invoked, this skill's job is done — no summary,
no double-reporting; the routed skill owns the conversation from there.
If the user aborts the interview, print the routing table above as plain
text so they can self-route next time.

## Does not do

- Any actual design, review, rendering, or code — the routed skills own
  that. If the user's request was already specific enough to route without
  questions, invoke the target skill directly and say why (interview
  skipped) — asking questions you can answer is a defect, not diligence.
- Cross-repo programs (kit-first fleets) — that is /design-fidelity-loop;
  mention it only when the user describes multi-agent scale.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [dndungu](https://github.com/dndungu)
- **Source:** [dndungu/agent-skills](https://github.com/dndungu/agent-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-dndungu-agent-skills-design
- Seller: https://agentstack.voostack.com/s/dndungu
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.