Installs just this skill. Get the whole plugin for auto-invocation.
โก How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/octopus-ui-ux-design
๐๏ธ Context preview
The summary Claude sees to decide when to auto-load this skill.
Design UI/UX systems with style guides, palettes, typography, and component specs for new interfaces
๐ Stats
Stars3,869
Forks362
LanguageShell
LicenseMIT
๐ฆ Ships with octo
</> SKILL.md
octopus-ui-ux-design.SKILL.md
---name: octopus-ui-ux-design
description: "Design UI/UX systems with style guides, palettes, typography, and component specs for new interfaces"
---> **Host: Codex CLI** โ This skill was designed for Claude Code and adapted for Codex.
> Cross-reference commands use installed skill names in Codex rather than `/octo:*` slash commands.
> Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it.
> For host tool equivalents, see `skills/blocks/codex-host-adapter.md`.
## EXECUTION CONTRACT (MANDATORY - CANNOT SKIP)
<HARD-GATE>
**CRITICAL: You MUST call the BM25 search engine (search.py) via native shell command tool before producing
any design recommendations. Do NOT rely solely on your own design knowledge. The search engine
provides curated, data-driven design intelligence. If you produce a design system without
at least 3 search.py calls, you have violated this contract.**
</HARD-GATE>
This skill uses **ENFORCED execution mode**. You MUST follow this exact sequence.
### STEP 1: Interactive Questions (BLOCKING)
**You MUST call AskUserQuestion before any other action.**
```javascript
AskUserQuestion({
questions: [
{
The dial answer maps to `--variance/--motion/--density` values (v/m/d above) passed to
every `search.py` call and stated in the design direction. Infer instead of asking only
when the user's brief already names a vibe ("brutalist", "playful", "corporate").
### STEP 2: Display Banner
**MANDATORY: You MUST use the native shell command tool to run this provider check BEFORE displaying the banner. Do NOT skip it. Do NOT assume availability.**
**If MISSING_SEARCH_PY**: The vendored design intelligence files are missing โ tell the user to reinstall or update the plugin (the `vendors/ui-ux-pro-max-skill/` directory ships with it as plain files).
**If MISSING_PYTHON**: Tell user python3 is required for design intelligence.
**This step runs automatically when the provider check in Step 2 detected 3 or more available providers (counting Claude as always available).** When fewer than 3 providers are available, skip to Step 5 and use standard single-direction mode.
Dispatch the same design brief to multiple providers in parallel. Each provider generates an independent design direction without seeing the others' work.
**Launch 3+ variant agents in parallel using the host subagent tool with `background execution: true`:**
Each agent receives:
```
Design a visual direction for: [user's product description]
Product type: [from Step 1]
Stack: [from Step 1]
Search context: [key findings from Step 4 BM25 searches]
Produce:
1. A style name (2-3 words, e.g., "Warm Minimalism", "Bold Industrial", "Cobalt Editorial")
2. Primary color palette (3-5 colors with hex values)
3. Font pairing (heading + body)
4. Layout philosophy (e.g., "generous whitespace with card-based content")
5. One paragraph describing the overall feel
Be distinctive โ take a clear position rather than playing it safe.
Hard constraints (see skills/blocks/design-taste.md): do NOT produce any of the three
{label: "Mix & match", description: "Take elements from multiple variants"}
]
}]
})
```
**After selection, proceed to Step 5 using the chosen variant as the design direction.** If "Mix & match", ask which elements to combine before proceeding.
### STEP 5: Phase 2 โ Define (Design Direction)
Synthesize search results (and chosen variant if shotgun mode) into a design direction document:
1. **Style recommendation** โ which visual style best fits the product (cite search results)
2. **Color palette** โ selected palette with hex values and contrast ratios
3. **Typography** โ heading + body font pairing with Google Fonts import
6. **Taste compliance** โ one line confirming the direction passes `skills/blocks/design-taste.md` (not one of the three banned looks; no unjustified banned-default fonts; boldness spent in one place)
**Output: Write the design direction as a structured section you can reference in the next step.**
**This step runs by default.** Before committing to the design direction, it must survive adversarial critique from up to three independent perspectives. This catches accessibility failures, impractical choices, and BM25 blind spots before they get baked into tokens and components.
**Critique prompt** (sent to all participants):
```
Review this proposed design direction and find problems. Be adversarial โ your job is to catch flaws, not validate choices.
[The full design direction from Step 5]
Critique dimensions:
1. ACCESSIBILITY โ Do the proposed colors meet WCAG AA contrast ratios (4.5:1 text, 3:1 large text)? Are the font sizes readable at the proposed scale? Are touch targets viable?
2. PRACTICALITY โ Does this typography actually render well on the stated tech stack? Are the fonts available and performant (file size, loading)? Does the spacing scale work with the layout system?
3. FIT โ Does the visual style actually match the product type and audience? Would a user of [product type] feel comfortable with this aesthetic?
4. GAPS โ What did the research miss? Are there common UX patterns for this product type that aren't addressed? Are there competitive norms being ignored?
5. SLOP โ Run the checklist in skills/blocks/design-taste.md. Is this one of the three AI-slop looks (cream+serif+terracotta, near-black+acid, purple gradients)? Banned default fonts without a stated reason? Would another model given the same brief land on the same palette and fonts? Two or more checklist misses fail the direction.
For each issue found, state: what's wrong, why it matters, and what to do instead.
**๐ต Claude (Sonnet) โ independent design critique.** You MUST also write your own adversarial critique. Do NOT just summarize what external providers said. Approach the design direction as if you didn't create it โ actively look for problems across all four dimensions. This is your independent synthesis perspective, same as in `/octo:debate`.
**Display all critiques with provider indicators:**
```
๐ด/๐งญ/๐ก **External Provider Critique:** [implementation, ecosystem, accessibility, and alternative approach concerns]
If only 1-2 providers are available, run with what you have. Even Claude-only critique (minimum case) is valuable because you're explicitly switching from "designer who made the choices" to "reviewer finding problems."
**After collecting all critiques, synthesize and revise:**
1. **Triage issues** โ group by severity (must-fix, should-fix, acknowledged trade-off)
Exit 1 means at least one pair fails WCAG AA โ fix the palette and re-run before delivering. Include the checker output in the final document as evidence.
2. **Slop check** โ run the pre-ship checklist in `skills/blocks/design-taste.md`; two or more misses means revise before delivering
3. **Completeness check** โ verify all requested deliverables are present
4. **Implementation readiness** โ confirm specs are detailed enough for frontend-developer
5. **Figma push-back** (if connected) โ offer to push design tokens to Figma
### STEP 8: Present Results and Persist
Format the final design system as a structured document with:
- Executive summary (style direction + rationale)
- Design tokens (copy-paste ready)
- Component inventory
- Page layouts
- Implementation notes for the development team
- Sources (which search results informed each decision)
**Persist the design system so it survives the session** (contract: `skill-design-lineage`):