IMPORTANT: This is a real scenario. Choose which existing frontend skill or skills to load from this directory. Use any relevant skills in this directory that match the task. User request: "This settings page feels too busy and loud. Simplify it, make it calmer, and fix the spacing and hierarchy while you're at it." Return exactly three lines: Skills: ...\nOrder: ...\nWhy: ...


total 8
drwxr-xr-x 1 alex alex  368 Apr 11 22:00 .
drwxr-xr-x 1 alex alex  122 Apr 11 17:42 ..
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 adapt
-rw-r--r-- 1 alex alex 1090 Apr 11 22:00 AGENTS.md
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 animate
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 arrange
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 audit
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 bolder
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 clarify
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 colorize
drwxr-xr-x 1 alex alex   34 Apr  9 11:27 critique
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 delight
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 distill
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 extract
drwxr-xr-x 1 alex alex   34 Apr  9 11:27 frontend-design
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 harden
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 normalize
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 onboard
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 optimize
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 overdrive
drwxr-xr-x 1 alex alex   56 Apr 11 21:56 .pi
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 polish
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 quieter
-rw-r--r-- 1 alex alex 3664 Apr 11 22:04 SKILL.md
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 teach-impeccable
drwxr-xr-x 1 alex alex   16 Apr  9 11:27 typeset


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md


---
name: frontend
description: Use when a task touches frontend UI/UX/design quality and the agent needs to choose which specialized frontend skill or combination of skills to load from this frontend skill pack.
---

# Frontend Skill Router

Pick the smallest set that matches the job.

## First checks

1. **Net-new UI or major visual direction work** → use `frontend-design`.
2. **No design context yet** and chosen skill says to invoke `frontend-design` → run `teach-impeccable` first if instructions and `.impeccable.md` do not already contain design context.
3. **If a chosen skill requires `frontend-design`, load it first. Do not skip it. Do not place it later in the sequence.**
4. **If a skill's own doc has mandatory prep, follow it.**

Skills that must route through `frontend-design`: `adapt`, `animate`, `arrange`, `audit`, `bolder`, `clarify`, `colorize`, `critique`, `delight`, `distill`, `normalize`, `onboard`, `overdrive`, `polish`, `quieter`, `typeset`.

## Choose by primary need

| Need | Skill |
|---|---|
| Build or redesign distinctive UI | `frontend-design` |
| Gather persistent design context once | `teach-impeccable` |
| Review UX/design quality | `critique` |
| Review technical UI quality: a11y, perf, theming, responsive | `audit` |
| Fix layout, spacing, hierarchy, composition | `arrange` |
| Improve typography and readability | `typeset` |
| Simplify, declutter, remove noise | `distill` |
| Tone down intensity without removing quality | `quieter` |
| Add color, warmth, palette energy | `colorize` |
| Make safe/bland UI more striking | `bolder` |
| Add joy, charm, personality | `delight` |
| Add purposeful motion and micro-interactions | `animate` |
| Push into technically ambitious wow-factor | `overdrive` |
| Improve onboarding, empty states, first-run flow | `onboard` |
| Fix labels, errors, helper text, instructions | `clarify` |
| Adapt for mobile, breakpoints, devices, contexts | `adapt` |
| Fix speed, jank, rendering, bundle/image cost | `optimize` |
| Fix resilience: errors, overflow, i18n, bad data | `harden` |
| Bring drifted UI back to system standards | `normalize` |
| Extract reusable components/tokens/patterns | `extract` |
| Final fit-and-finish before ship | `polish` |

## Common confusions

- `critique` vs `audit` → design judgment vs measurable implementation quality.
- `arrange` vs `polish` → structural layout pass vs final detail pass.
- `distill` vs `quieter` → remove complexity vs reduce visual intensity.
- `delight` vs `animate` → personality/joy vs motion mechanics.
- `normalize` vs `extract` → align to existing system vs create shared system assets.
- `bolder` vs `colorize` → stronger overall impact vs specifically more chroma.
- `optimize` vs `harden` → speed/smoothness vs resilience/edge cases.

## Common combos

- New feature: `frontend-design` → specialist skill(s) → `polish`
- UX + technical review: `frontend-design` → `critique` + `audit`
- Busy screen cleanup: `frontend-design` → `distill` + `arrange`, add `quieter` if still loud
- Repeated patterns + token drift: `extract` + `normalize`
- First-run experience: `frontend-design` → `onboard`, add `clarify`, `delight`, or `polish` only if explicitly needed

## Routing discipline

- Choose **1 primary skill** from the user's explicit ask.
- Add specialists only for clearly stated extra concerns or mandatory prep.
- Do **not** add speculative helpers just because they might help.
- `audit` is for review/check requests, not default build or refactor work.
- `polish` is for explicit final-pass or finishing-touch requests.
- `typeset` is for explicit typography/readability issues.


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

2. **No design context yet** and chosen skill says to invoke `frontend-design` → run `teach-impeccable` first if instructions and `.impeccable.md` do not already contain design context.

.impeccable.md

.impeccable.md

must-3b670e92-1

3. **If a chosen skill requires `frontend-design`, load it first. Do not skip it. Do not place it later in the sequence.**

must-3b670e92-2

Skills that must route through `frontend-design`: `adapt`, `animate`, `arrange`, `audit`, `bolder`, `clarify`, `colorize`, `critique`, `delight`, `distill`, `normalize`, `onboard`, `overdrive`, `polish`, `quieter`, `typeset`.


**Processing design instructions**

I need to follow the constraints since there's no design context yet. The user's request is to simplify a settings page that feels busy and loud. They want it decluttered, with better spacing and hierarchy—the key needs here are to simplify, arrange, and make it quieter.

I see that the necessary skills, like distill, arrange, and quieter, need to be routed through frontend-design. I've confirmed that these skills are indeed included in the skills list.

**Checking design context**

The router indicates that if a selected skill requires frontend-design, I need to load that first. Since there's no design context yet, I should run teach-impeccable if the instructions and .impeccable.md lack that context. So the next step is to check the .impeccable.md file to see what information is available. This will help me determine how to proceed while ensuring I follow the guidelines correctly. Time to read that file!


ENOENT: no such file or directory, access '/home/alex/.pi/agent/skills/frontend/.impeccable.md'


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

.impeccable.md

.impeccable.md

must-3b670e92-1

must-3b670e92-2


**Checking skill requirements**

The user's question seems to expect a response involving skills like frontend design, teaching impeccable skills, distilling, arranging, and perhaps quieter approaches. However, I need to remember that I must always include the caveman skill. First, I should verify if "teach-impeccable" is listed in the directory. I'll check the directory for "teach-impeccable" and look at its SKILL.md file to get more information. Let's see what's inside!


---
name: teach-impeccable
description: One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.
---

Gather design context for this project, then persist it for all future sessions.

## Step 1: Explore the Codebase

Before asking questions, thoroughly scan the project to discover what you can:

- **README and docs**: Project purpose, target audience, any stated goals
- **Package.json / config files**: Tech stack, dependencies, existing design libraries
- **Existing components**: Current design patterns, spacing, typography in use
- **Brand assets**: Logos, favicons, color values already defined
- **Design tokens / CSS variables**: Existing color palettes, font stacks, spacing scales
- **Any style guides or brand documentation**

Note what you've learned and what remains unclear.

## Step 2: Ask UX-Focused Questions

ask the user directly to clarify what you cannot infer. Focus only on what you couldn't infer from the codebase:

### Users & Purpose
- Who uses this? What's their context when using it?
- What job are they trying to get done?
- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

### Brand & Personality
- How would you describe the brand personality in 3 words?
- Any reference sites or apps that capture the right feel? What specifically about them?
- What should this explicitly NOT look like? Any anti-references?

### Aesthetic Preferences
- Any strong preferences for visual direction? (minimal, bold, elegant, playful, technical, organic, etc.)
- Light mode, dark mode, or both?
- Any colors that must be used or avoided?

### Accessibility & Inclusion
- Specific accessibility requirements? (WCAG level, known user needs)
- Considerations for reduced motion, color blindness, or other accommodations?

Skip questions where the answer is already clear from the codebase exploration.

## Step 3: Write Design Context

Synthesize your findings and the user's answers into a `## Design Context` section:

```markdown
## Design Context

### Users
[Who they are, their context, the job to be done]

### Brand Personality
[Voice, tone, 3-word personality, emotional goals]

### Aesthetic Direction
[Visual tone, references, anti-references, theme]

### Design Principles
[3-5 principles derived from the conversation that should guide all design decisions]
```

Write this section to `.impeccable.md` in the project root. If the file already exists, update the Design Context section in place.

Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to AGENTS.md. If yes, append or update the section there as well.

Confirm completion and summarize the key design principles that will now guide all future work.


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

.impeccable.md

.impeccable.md

must-3b670e92-1

must-3b670e92-2

Package.js

Package.js

must-8fafe0e3-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-8fafe0e3-1

- What should this explicitly NOT look like? Any anti-references?

must-8fafe0e3-2

- Any colors that must be used or avoided?

must-8fafe0e3-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md


---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Generates creative, polished code that avoids generic AI aesthetics. Use when the user asks to build web components, pages, artifacts, posters, or applications, or when any design skill requires project context.
license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
---

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

## Context Gathering Protocol

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

**Required context** — every design skill needs at minimum:
- **Target audience**: Who uses this product and in what context?
- **Use cases**: What jobs are they trying to get done?
- **Brand personality/tone**: How should the interface feel?

Individual skills may require additional context — check the skill's preparation section for specifics.

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

**Gathering order:**
1. **Check current instructions (instant)**: If your loaded instructions already contain a **Design Context** section, proceed immediately.
2. **Check .impeccable.md (fast)**: If not in instructions, read `.impeccable.md` from the project root. If it exists and contains the required context, proceed.
3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

---

## Design Direction

Commit to a BOLD aesthetic direction:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work—the key is intentionality, not intensity.

Then implement working code that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail

## Frontend Aesthetics Guidelines

### Typography
→ *Consult [typography reference](reference/typography.md) for scales, pairing, and loading strategies.*

Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.

**DO**: Use a modular type scale with fluid sizing (clamp)
**DO**: Vary font weights and sizes to create clear visual hierarchy
**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults
**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes
**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

### Color & Theme
→ *Consult [color reference](reference/color-and-contrast.md) for OKLCH, palettes, and dark mode.*

Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.

**DO**: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes
**DO**: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion
**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead
**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature
**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds
**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful
**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

### Layout & Space
→ *Consult [spatial reference](reference/spatial-design.md) for grids, rhythm, and container queries.*

Create visual rhythm through varied spacing—not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis.

**DO**: Create visual rhythm through varied spacing—tight groupings, generous separations
**DO**: Use fluid spacing with clamp() that breathes on larger screens
**DO**: Use asymmetry and unexpected compositions; break the grid intentionally for emphasis
**DON'T**: Wrap everything in cards—not everything needs a container
**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy
**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly
**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent
**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed
**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

### Visual Details
**DO**: Use intentional, purposeful decorative elements that reinforce brand
**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully
**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional
**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful
**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output
**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

### Motion
→ *Consult [motion reference](reference/motion-design.md) for timing, easing, and reduced motion.*

Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions.

**DO**: Use motion to convey state changes—entrances, exits, feedback
**DO**: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration
**DO**: For height animations, use grid-template-rows transitions instead of animating height directly
**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only
**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

### Interaction
→ *Consult [interaction reference](reference/interaction-design.md) for forms, focus, and loading patterns.*

Make interactions feel fast. Use optimistic UI—update immediately, sync later.

**DO**: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions)
**DO**: Design empty states that teach the interface, not just say "nothing here"
**DO**: Make every interactive surface feel intentional and responsive
**DON'T**: Repeat the same information—redundant headers, intros that restate the heading
**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

### Responsive
→ *Consult [responsive reference](reference/responsive-design.md) for mobile-first, fluid design, and container queries.*

**DO**: Use container queries (@container) for component-level responsiveness
**DO**: Adapt the interface for different contexts—don't just shrink it
**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

### UX Writing
→ *Consult [ux-writing reference](reference/ux-writing.md) for labels, errors, and empty states.*

**DO**: Make every word earn its place
**DON'T**: Repeat information users can already see

---

## The AI Slop Test

**Critical quality check**: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

---

## Implementation Principles

Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details.

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

.impeccable.md

.impeccable.md

must-3b670e92-1

must-3b670e92-2

Package.js

Package.js

must-8fafe0e3-0

must-8fafe0e3-1

must-8fafe0e3-2

must-8fafe0e3-3

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

NOTICE.md

NOTICE.md

must-01ae6492-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-01ae6492-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-01ae6492-2

- **Brand personality/tone**: How should the interface feel?

must-01ae6492-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-01ae6492-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-01ae6492-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-01ae6492-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-01ae6492-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-01ae6492-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-01ae6492-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-01ae6492-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-01ae6492-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-01ae6492-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-01ae6492-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-01ae6492-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-01ae6492-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-01ae6492-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-01ae6492-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-01ae6492-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-01ae6492-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-01ae6492-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-01ae6492-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-01ae6492-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-01ae6492-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-01ae6492-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-01ae6492-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-01ae6492-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-01ae6492-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-01ae6492-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-01ae6492-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-01ae6492-30

**DON'T**: Repeat information users can already see

must-01ae6492-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-01ae6492-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-01ae6492-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-01ae6492-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.


---
name: distill
description: Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean. Use when the user asks to simplify, declutter, reduce noise, remove elements, or make a UI cleaner and more focused.
---

Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.

## MANDATORY PREPARATION

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

---

## Assess Current State

Analyze what makes the design feel complex or cluttered:

1. **Identify complexity sources**:
   - **Too many elements**: Competing buttons, redundant information, visual clutter
   - **Excessive variation**: Too many colors, fonts, sizes, styles without purpose
   - **Information overload**: Everything visible at once, no progressive disclosure
   - **Visual noise**: Unnecessary borders, shadows, backgrounds, decorations
   - **Confusing hierarchy**: Unclear what matters most
   - **Feature creep**: Too many options, actions, or paths forward

2. **Find the essence**:
   - What's the primary user goal? (There should be ONE)
   - What's actually necessary vs nice-to-have?
   - What can be removed, hidden, or combined?
   - What's the 20% that delivers 80% of value?

If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.

**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.

## Plan Simplification

Create a ruthless editing strategy:

- **Core purpose**: What's the ONE thing this should accomplish?
- **Essential elements**: What's truly necessary to achieve that purpose?
- **Progressive disclosure**: What can be hidden until needed?
- **Consolidation opportunities**: What can be combined or integrated?

**IMPORTANT**: Simplification is hard. It requires saying no to good ideas to make room for great execution. Be ruthless.

## Simplify the Design

Systematically remove complexity across these dimensions:

### Information Architecture
- **Reduce scope**: Remove secondary actions, optional features, redundant information
- **Progressive disclosure**: Hide complexity behind clear entry points (accordions, modals, step-through flows)
- **Combine related actions**: Merge similar buttons, consolidate forms, group related content
- **Clear hierarchy**: ONE primary action, few secondary actions, everything else tertiary or hidden
- **Remove redundancy**: If it's said elsewhere, don't repeat it here

### Visual Simplification
- **Reduce color palette**: Use 1-2 colors plus neutrals, not 5-7 colors
- **Limit typography**: One font family, 3-4 sizes maximum, 2-3 weights
- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function
- **Flatten structure**: Reduce nesting, remove unnecessary containers—never nest cards inside cards
- **Remove unnecessary cards**: Cards aren't needed for basic layout; use spacing and alignment instead
- **Consistent spacing**: Use one spacing scale, remove arbitrary gaps

### Layout Simplification
- **Linear flow**: Replace complex grids with simple vertical flow where possible
- **Remove sidebars**: Move secondary content inline or hide it
- **Full-width**: Use available space generously instead of complex multi-column layouts
- **Consistent alignment**: Pick left or center, stick with it
- **Generous white space**: Let content breathe, don't pack everything tight

### Interaction Simplification
- **Reduce choices**: Fewer buttons, fewer options, clearer path forward (paradox of choice is real)
- **Smart defaults**: Make common choices automatic, only ask when necessary
- **Inline actions**: Replace modal flows with inline editing where possible
- **Remove steps**: Can signup be one step instead of three? Can checkout be simplified?
- **Clear CTAs**: ONE obvious next step, not five competing actions

### Content Simplification
- **Shorter copy**: Cut every sentence in half, then do it again
- **Active voice**: "Save changes" not "Changes will be saved"
- **Remove jargon**: Plain language always wins
- **Scannable structure**: Short paragraphs, bullet points, clear headings
- **Essential information only**: Remove marketing fluff, legalese, hedging
- **Remove redundant copy**: No headers restating intros, no repeated explanations, say it once

### Code Simplification
- **Remove unused code**: Dead CSS, unused components, orphaned files
- **Flatten component trees**: Reduce nesting depth
- **Consolidate styles**: Merge similar styles, use utilities consistently
- **Reduce variants**: Does that component need 12 variations, or can 3 cover 90% of cases?

**NEVER**:
- Remove necessary functionality (simplicity ≠ feature-less)
- Sacrifice accessibility for simplicity (clear labels and ARIA still required)
- Make things so simple they're unclear (mystery ≠ minimalism)
- Remove information users need to make decisions
- Eliminate hierarchy completely (some things should stand out)
- Oversimplify complex domains (match complexity to actual task complexity)

## Verify Simplification

Ensure simplification improves usability:

- **Faster task completion**: Can users accomplish goals more quickly?
- **Reduced cognitive load**: Is it easier to understand what to do?
- **Still complete**: Are all necessary features still accessible?
- **Clearer hierarchy**: Is it obvious what matters most?
- **Better performance**: Does simpler design load faster?

## Document Removed Complexity

If you removed features or options:
- Document why they were removed
- Consider if they need alternative access points
- Note any user feedback to monitor

Remember: You have great taste and judgment. Simplification is an act of confidence - knowing what to keep and courage to remove the rest. As Antoine de Saint-Exupéry said: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

2. **No design context yet** and chosen skill says to invoke `frontend-design` → run `teach-impeccable` first if instructions and `.impeccable.md` do not already contain design context.

.impeccable.md

.impeccable.md

must-3b670e92-1

3. **If a chosen skill requires `frontend-design`, load it first. Do not skip it. Do not place it later in the sequence.**

must-3b670e92-2

Skills that must route through `frontend-design`: `adapt`, `animate`, `arrange`, `audit`, `bolder`, `clarify`, `colorize`, `critique`, `delight`, `distill`, `normalize`, `onboard`, `overdrive`, `polish`, `quieter`, `typeset`.

ENOENT: no such file or directory, access '/home/alex/.pi/agent/skills/frontend/.impeccable.md'

Package.js

Package.js

must-8fafe0e3-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-8fafe0e3-1

- What should this explicitly NOT look like? Any anti-references?

must-8fafe0e3-2

- Any colors that must be used or avoided?

must-8fafe0e3-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

NOTICE.md

NOTICE.md

must-01ae6492-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-01ae6492-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-01ae6492-2

- **Brand personality/tone**: How should the interface feel?

must-01ae6492-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-01ae6492-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-01ae6492-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-01ae6492-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-01ae6492-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-01ae6492-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-01ae6492-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-01ae6492-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-01ae6492-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-01ae6492-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-01ae6492-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-01ae6492-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-01ae6492-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-01ae6492-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-01ae6492-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-01ae6492-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-01ae6492-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-01ae6492-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-01ae6492-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-01ae6492-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-01ae6492-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-01ae6492-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-01ae6492-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-01ae6492-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-01ae6492-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-01ae6492-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-01ae6492-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-01ae6492-30

**DON'T**: Repeat information users can already see

must-01ae6492-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-01ae6492-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-01ae6492-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-01ae6492-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

must-7c68fbe2-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-7c68fbe2-1

- What's the primary user goal? (There should be ONE)

must-7c68fbe2-2

**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.

must-7c68fbe2-3

- **Core purpose**: What's the ONE thing this should accomplish?

must-7c68fbe2-4

- **Remove redundancy**: If it's said elsewhere, don't repeat it here

must-7c68fbe2-5

- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function

must-7c68fbe2-6

- **Generous white space**: Let content breathe, don't pack everything tight

must-7c68fbe2-7

- Eliminate hierarchy completely (some things should stand out)


---
name: arrange
description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
---

Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.

## MANDATORY PREPARATION

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

---

## Assess Current Layout

Analyze what's weak about the current spatial design:

1. **Spacing**:
   - Is spacing consistent or arbitrary? (Random padding/margin values)
   - Is all spacing the same? (Equal padding everywhere = no rhythm)
   - Are related elements grouped tightly, with generous space between groups?

2. **Visual hierarchy**:
   - Apply the squint test: blur your (metaphorical) eyes — can you still identify the most important element, second most important, and clear groupings?
   - Is hierarchy achieved effectively? (Space and weight alone can be enough — but is the current approach working?)
   - Does whitespace guide the eye to what matters?

3. **Grid & structure**:
   - Is there a clear underlying structure, or does the layout feel random?
   - Are identical card grids used everywhere? (Icon + heading + text, repeated endlessly)
   - Is everything centered? (Left-aligned with asymmetric layouts feels more designed, but not a hard and fast rule)

4. **Rhythm & variety**:
   - Does the layout have visual rhythm? (Alternating tight/generous spacing)
   - Is every section structured the same way? (Monotonous repetition)
   - Are there intentional moments of surprise or emphasis?

5. **Density**:
   - Is the layout too cramped? (Not enough breathing room)
   - Is the layout too sparse? (Excessive whitespace without purpose)
   - Does density match the content type? (Data-dense UIs need tighter spacing; marketing pages need more air)

**CRITICAL**: Layout problems are often the root cause of interfaces feeling "off" even when colors and fonts are fine. Space is a design material — use it with intention.

## Plan Layout Improvements

Consult the [spatial design reference](reference/spatial-design.md) from the frontend-design skill for detailed guidance on grids, rhythm, and container queries.

Create a systematic plan:

- **Spacing system**: Use a consistent scale — whether that's a framework's built-in scale (e.g., Tailwind), rem-based tokens, or a custom system. The specific values matter less than consistency.
- **Hierarchy strategy**: How will space communicate importance?
- **Layout approach**: What structure fits the content? Flex for 1D, Grid for 2D, named areas for complex page layouts.
- **Rhythm**: Where should spacing be tight vs generous?

## Improve Layout Systematically

### Establish a Spacing System

- Use a consistent spacing scale — framework scales (Tailwind, etc.), rem-based tokens, or a custom scale all work. What matters is that values come from a defined set, not arbitrary numbers.
- Name tokens semantically if using custom properties: `--space-xs` through `--space-xl`, not `--spacing-8`
- Use `gap` for sibling spacing instead of margins — eliminates margin collapse hacks
- Apply `clamp()` for fluid spacing that breathes on larger screens

### Create Visual Rhythm

- **Tight grouping** for related elements (8-12px between siblings)
- **Generous separation** between distinct sections (48-96px)
- **Varied spacing** within sections — not every row needs the same gap
- **Asymmetric compositions** — break the predictable centered-content pattern when it makes sense

### Choose the Right Layout Tool

- **Use Flexbox for 1D layouts**: Rows of items, nav bars, button groups, card contents, most component internals. Flex is simpler and more appropriate for the majority of layout tasks.
- **Use Grid for 2D layouts**: Page-level structure, dashboards, data-dense interfaces, anything where rows AND columns need coordinated control.
- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.
- Use `repeat(auto-fit, minmax(280px, 1fr))` for responsive grids without breakpoints.
- Use named grid areas (`grid-template-areas`) for complex page layouts — redefine at breakpoints.

### Break Card Grid Monotony

- Don't default to card grids for everything — spacing and alignment create visual grouping naturally
- Use cards only when content is truly distinct and actionable — never nest cards inside cards
- Vary card sizes, span columns, or mix cards with non-card content to break repetition

### Strengthen Visual Hierarchy

- Use the fewest dimensions needed for clear hierarchy. Space alone can be enough — generous whitespace around an element draws the eye. Some of the most sophisticated designs achieve rhythm with just space and weight. Add color or size contrast only when simpler means aren't sufficient.
- Be aware of reading flow — in LTR languages, the eye naturally scans top-left to bottom-right, but primary action placement depends on context (e.g., bottom-right in dialogs, top in navigation).
- Create clear content groupings through proximity and separation.

### Manage Depth & Elevation

- Create a semantic z-index scale (dropdown → sticky → modal-backdrop → modal → toast → tooltip)
- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle
- Use elevation to reinforce hierarchy, not as decoration

### Optical Adjustments

- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.

**NEVER**:
- Use arbitrary spacing values outside your scale
- Make all spacing equal — variety creates hierarchy
- Wrap everything in cards — not everything needs a container
- Nest cards inside cards — use spacing and dividers for hierarchy within
- Use identical card grids everywhere (icon + heading + text, repeated)
- Center everything — left-aligned with asymmetry feels more designed
- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.
- Default to CSS Grid when Flexbox would be simpler — use the simplest tool for the job
- Use arbitrary z-index values (999, 9999) — build a semantic scale

## Verify Layout Improvements

- **Squint test**: Can you identify primary, secondary, and groupings with blurred vision?
- **Rhythm**: Does the page have a satisfying beat of tight and generous spacing?
- **Hierarchy**: Is the most important content obvious within 2 seconds?
- **Breathing room**: Does the layout feel comfortable, not cramped or wasteful?
- **Consistency**: Is the spacing system applied uniformly?
- **Responsiveness**: Does the layout adapt gracefully across screen sizes?

Remember: Space is the most underused design tool. A layout with the right rhythm and hierarchy can make even simple content feel polished and intentional.


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

2. **No design context yet** and chosen skill says to invoke `frontend-design` → run `teach-impeccable` first if instructions and `.impeccable.md` do not already contain design context.

.impeccable.md

.impeccable.md

must-3b670e92-1

3. **If a chosen skill requires `frontend-design`, load it first. Do not skip it. Do not place it later in the sequence.**

must-3b670e92-2

Skills that must route through `frontend-design`: `adapt`, `animate`, `arrange`, `audit`, `bolder`, `clarify`, `colorize`, `critique`, `delight`, `distill`, `normalize`, `onboard`, `overdrive`, `polish`, `quieter`, `typeset`.

ENOENT: no such file or directory, access '/home/alex/.pi/agent/skills/frontend/.impeccable.md'

Package.js

Package.js

must-8fafe0e3-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-8fafe0e3-1

- What should this explicitly NOT look like? Any anti-references?

must-8fafe0e3-2

- Any colors that must be used or avoided?

must-8fafe0e3-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

NOTICE.md

NOTICE.md

must-01ae6492-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-01ae6492-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-01ae6492-2

- **Brand personality/tone**: How should the interface feel?

must-01ae6492-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-01ae6492-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-01ae6492-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-01ae6492-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-01ae6492-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-01ae6492-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-01ae6492-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-01ae6492-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-01ae6492-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-01ae6492-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-01ae6492-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-01ae6492-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-01ae6492-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-01ae6492-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-01ae6492-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-01ae6492-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-01ae6492-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-01ae6492-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-01ae6492-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-01ae6492-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-01ae6492-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-01ae6492-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-01ae6492-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-01ae6492-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-01ae6492-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-01ae6492-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-01ae6492-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-01ae6492-30

**DON'T**: Repeat information users can already see

must-01ae6492-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-01ae6492-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-01ae6492-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-01ae6492-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

must-7c68fbe2-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-7c68fbe2-1

- What's the primary user goal? (There should be ONE)

must-7c68fbe2-2

**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.

must-7c68fbe2-3

- **Core purpose**: What's the ONE thing this should accomplish?

must-7c68fbe2-4

- **Remove redundancy**: If it's said elsewhere, don't repeat it here

must-7c68fbe2-5

- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function

must-7c68fbe2-6

- **Generous white space**: Let content breathe, don't pack everything tight

must-7c68fbe2-7

- Eliminate hierarchy completely (some things should stand out)

must-a8781840-0

reference/spatial-design.md

reference/spatial-design.md

must-a8781840-1

- **Rhythm**: Where should spacing be tight vs generous?

must-a8781840-2

- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.

must-a8781840-3

- Don't default to card grids for everything — spacing and alignment create visual grouping naturally

must-a8781840-4

- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle

must-a8781840-5

- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.

must-a8781840-6

- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.


---
name: quieter
description: Tones down visually aggressive or overstimulating designs, reducing intensity while preserving quality. Use when the user mentions too bold, too loud, overwhelming, aggressive, garish, or wants a calmer, more refined aesthetic.
---

Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.

## MANDATORY PREPARATION

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

---

## Assess Current State

Analyze what makes the design feel too intense:

1. **Identify intensity sources**:
   - **Color saturation**: Overly bright or saturated colors
   - **Contrast extremes**: Too much high-contrast juxtaposition
   - **Visual weight**: Too many bold, heavy elements competing
   - **Animation excess**: Too much motion or overly dramatic effects
   - **Complexity**: Too many visual elements, patterns, or decorations
   - **Scale**: Everything is large and loud with no hierarchy

2. **Understand the context**:
   - What's the purpose? (Marketing vs tool vs reading experience)
   - Who's the audience? (Some contexts need energy)
   - What's working? (Don't throw away good ideas)
   - What's the core message? (Preserve what matters)

If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.

**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.

## Plan Refinement

Create a strategy to reduce intensity while maintaining impact:

- **Color approach**: Desaturate or shift to more sophisticated tones?
- **Hierarchy approach**: Which elements should stay bold (very few), which should recede?
- **Simplification approach**: What can be removed entirely?
- **Sophistication approach**: How can we signal quality through restraint?

**IMPORTANT**: Great quiet design is harder than great bold design. Subtlety requires precision.

## Refine the Design

Systematically reduce intensity across these dimensions:

### Color Refinement
- **Reduce saturation**: Shift from fully saturated to 70-85% saturation
- **Soften palette**: Replace bright colors with muted, sophisticated tones
- **Reduce color variety**: Use fewer colors more thoughtfully
- **Neutral dominance**: Let neutrals do more work, use color as accent (10% rule)
- **Gentler contrasts**: High contrast only where it matters most
- **Tinted grays**: Use warm or cool tinted grays instead of pure gray—adds sophistication without loudness
- **Never gray on color**: If you have gray text on a colored background, use a darker shade of that color or transparency instead

### Visual Weight Reduction
- **Typography**: Reduce font weights (900 → 600, 700 → 500), decrease sizes where appropriate
- **Hierarchy through subtlety**: Use weight, size, and space instead of color and boldness
- **White space**: Increase breathing room, reduce density
- **Borders & lines**: Reduce thickness, decrease opacity, or remove entirely

### Simplification
- **Remove decorative elements**: Gradients, shadows, patterns, textures that don't serve purpose
- **Simplify shapes**: Reduce border radius extremes, simplify custom shapes
- **Reduce layering**: Flatten visual hierarchy where possible
- **Clean up effects**: Reduce or remove blur effects, glows, multiple shadows

### Motion Reduction
- **Reduce animation intensity**: Shorter distances (10-20px instead of 40px), gentler easing
- **Remove decorative animations**: Keep functional motion, remove flourishes
- **Subtle micro-interactions**: Replace dramatic effects with gentle feedback
- **Refined easing**: Use ease-out-quart for smooth, understated motion—never bounce or elastic
- **Remove animations entirely** if they're not serving a clear purpose

### Composition Refinement
- **Reduce scale jumps**: Smaller contrast between sizes creates calmer feeling
- **Align to grid**: Bring rogue elements back into systematic alignment
- **Even out spacing**: Replace extreme spacing variations with consistent rhythm

**NEVER**:
- Make everything the same size/weight (hierarchy still matters)
- Remove all color (quiet ≠ grayscale)
- Eliminate all personality (maintain character through refinement)
- Sacrifice usability for aesthetics (functional elements still need clear affordances)
- Make everything small and light (some anchors needed)

## Verify Quality

Ensure refinement maintains quality:

- **Still functional**: Can users still accomplish tasks easily?
- **Still distinctive**: Does it have character, or is it generic now?
- **Better reading**: Is text easier to read for extended periods?
- **Sophistication**: Does it feel more refined and premium?

Remember: Quiet design is confident design. It doesn't need to shout. Less is more, but less is also harder. Refine with precision and maintain intentionality.


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

2. **No design context yet** and chosen skill says to invoke `frontend-design` → run `teach-impeccable` first if instructions and `.impeccable.md` do not already contain design context.

.impeccable.md

.impeccable.md

must-3b670e92-1

3. **If a chosen skill requires `frontend-design`, load it first. Do not skip it. Do not place it later in the sequence.**

must-3b670e92-2

Skills that must route through `frontend-design`: `adapt`, `animate`, `arrange`, `audit`, `bolder`, `clarify`, `colorize`, `critique`, `delight`, `distill`, `normalize`, `onboard`, `overdrive`, `polish`, `quieter`, `typeset`.

ENOENT: no such file or directory, access '/home/alex/.pi/agent/skills/frontend/.impeccable.md'

Package.js

Package.js

must-8fafe0e3-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-8fafe0e3-1

- What should this explicitly NOT look like? Any anti-references?

must-8fafe0e3-2

- Any colors that must be used or avoided?

must-8fafe0e3-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

NOTICE.md

NOTICE.md

must-01ae6492-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-01ae6492-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-01ae6492-2

- **Brand personality/tone**: How should the interface feel?

must-01ae6492-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-01ae6492-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-01ae6492-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-01ae6492-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-01ae6492-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-01ae6492-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-01ae6492-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-01ae6492-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-01ae6492-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-01ae6492-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-01ae6492-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-01ae6492-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-01ae6492-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-01ae6492-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-01ae6492-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-01ae6492-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-01ae6492-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-01ae6492-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-01ae6492-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-01ae6492-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-01ae6492-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-01ae6492-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-01ae6492-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-01ae6492-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-01ae6492-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-01ae6492-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-01ae6492-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-01ae6492-30

**DON'T**: Repeat information users can already see

must-01ae6492-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-01ae6492-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-01ae6492-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-01ae6492-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

must-7c68fbe2-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-7c68fbe2-1

- What's the primary user goal? (There should be ONE)

must-7c68fbe2-2

**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.

must-7c68fbe2-3

- **Core purpose**: What's the ONE thing this should accomplish?

must-7c68fbe2-4

- **Remove redundancy**: If it's said elsewhere, don't repeat it here

must-7c68fbe2-5

- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function

must-7c68fbe2-6

- **Generous white space**: Let content breathe, don't pack everything tight

must-7c68fbe2-7

- Eliminate hierarchy completely (some things should stand out)

must-a8781840-0

reference/spatial-design.md

reference/spatial-design.md

must-a8781840-1

- **Rhythm**: Where should spacing be tight vs generous?

must-a8781840-2

- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.

must-a8781840-3

- Don't default to card grids for everything — spacing and alignment create visual grouping naturally

must-a8781840-4

- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle

must-a8781840-5

- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.

must-a8781840-6

- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.

must-7f1e8a9f-0

must-7f1e8a9f-1

- What's working? (Don't throw away good ideas)

must-7f1e8a9f-2

- **Hierarchy approach**: Which elements should stay bold (very few), which should recede?

must-7f1e8a9f-3

- **Remove decorative elements**: Gradients, shadows, patterns, textures that don't serve purpose


**Clarifying skill order**

I’m thinking about how to arrange skills effectively. It seems that I should prioritize "teach-impeccable" over any design work. The guideline was clear: if something requires frontend design, it should be loaded first, but it didn’t specifically say I couldn’t have other skills before it, like caveman. So, I guess it’s fine to have caveman in the mix. Ultimately, the essential order should be: teach-impeccable, frontend-design, then the others.

**Structuring skill order**

I think the user likely expects the order of skills to be clear, so let me lay it out: "Skills: caveman, teach-impeccable, frontend-design, distill, arrange, quieter." For the order, it should be: "Order: teach-impeccable → frontend-design → distill (primary) → arrange → quieter; always load caveman." I need to be concise while making sure it adheres to the three-line format. The requirement for "Order" could also be interpreted as keeping "caveman" loaded, so I'll make that work within a single line.

**Finalizing skill lines**

I need to clarify the lines while keeping them concise. For the skills, I’ll say: "Skills: caveman, teach-impeccable, frontend-design, distill, arrange, quieter." Then for the order, it should be: "Order: teach-impeccable → frontend-design → distill (primary) → arrange → quieter; load caveman alongside." Finally, I'll explain: "Why: No design context exists yet, so gather it first; distill simplifies, arrange fixes spacing, quieter calms intensity; caveman keeps it brief." It’s crucial to maintain that three-line structure without extra punctuation.

**Crafting concise skill lines**

I need to make sure to follow the project guidelines, like always loading the caveman skill and being brief by default. I should invoke frontend-design since it covers essential design principles and the Context Gathering Protocol. If there's no design context, I must run teach-impeccable first. I’ll include only the necessary skills: "Skills: caveman, teach-impeccable, frontend-design, distill, arrange, quieter." For the order, I’ll say: "Order: teach-impeccable → frontend-design → distill → arrange → quieter; always load caveman." Lastly: "Why: Gather context first, simplify with distill, fix spacing with arrange, calm visual intensity with quieter."

**Preparing final skills output**

I'm crafting the final output according to the user's request. For the skills, I’ll say: "Skills: caveman, teach-impeccable, frontend-design, distill, arrange, quieter." In terms of the order, it should be: "Order: teach-impeccable → frontend-design → distill (primary) → arrange → quieter; caveman always loaded." Lastly, for the reasoning: "Why: .impeccable.md missing, so gather design context first; distill for simplification, arrange for spacing/hierarchy, quieter to calm intensity; caveman ensures brevity." I’ll make sure there are no trailing whitespaces or extra newlines!

Skills: caveman, teach-impeccable, frontend-design, distill, arrange, quieter
Order: teach-impeccable → frontend-design → distill (primary) → arrange → quieter; caveman always loaded
Why: .impeccable.md missing so gather design context first; distill to declutter, arrange to fix spacing/hierarchy, quieter to reduce visual intensity; caveman for concise output


AGENTS.md

AGENTS.md

SKILL.md

SKILL.md

must-3b670e92-0

2. **No design context yet** and chosen skill says to invoke `frontend-design` → run `teach-impeccable` first if instructions and `.impeccable.md` do not already contain design context.

.impeccable.md

.impeccable.md

must-3b670e92-1

3. **If a chosen skill requires `frontend-design`, load it first. Do not skip it. Do not place it later in the sequence.**

must-3b670e92-2

Skills that must route through `frontend-design`: `adapt`, `animate`, `arrange`, `audit`, `bolder`, `clarify`, `colorize`, `critique`, `delight`, `distill`, `normalize`, `onboard`, `overdrive`, `polish`, `quieter`, `typeset`.

ENOENT: no such file or directory, access '/home/alex/.pi/agent/skills/frontend/.impeccable.md'

Package.js

Package.js

must-8fafe0e3-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-8fafe0e3-1

- What should this explicitly NOT look like? Any anti-references?

must-8fafe0e3-2

- Any colors that must be used or avoided?

must-8fafe0e3-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

NOTICE.md

NOTICE.md

must-01ae6492-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-01ae6492-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-01ae6492-2

- **Brand personality/tone**: How should the interface feel?

must-01ae6492-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-01ae6492-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-01ae6492-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-01ae6492-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-01ae6492-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-01ae6492-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-01ae6492-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-01ae6492-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-01ae6492-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-01ae6492-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-01ae6492-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-01ae6492-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-01ae6492-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-01ae6492-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-01ae6492-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-01ae6492-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-01ae6492-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-01ae6492-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-01ae6492-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-01ae6492-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-01ae6492-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-01ae6492-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-01ae6492-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-01ae6492-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-01ae6492-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-01ae6492-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-01ae6492-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-01ae6492-30

**DON'T**: Repeat information users can already see

must-01ae6492-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-01ae6492-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-01ae6492-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-01ae6492-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

must-7c68fbe2-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-7c68fbe2-1

- What's the primary user goal? (There should be ONE)

must-7c68fbe2-2

**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.

must-7c68fbe2-3

- **Core purpose**: What's the ONE thing this should accomplish?

must-7c68fbe2-4

- **Remove redundancy**: If it's said elsewhere, don't repeat it here

must-7c68fbe2-5

- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function

must-7c68fbe2-6

- **Generous white space**: Let content breathe, don't pack everything tight

must-7c68fbe2-7

- Eliminate hierarchy completely (some things should stand out)

must-a8781840-0

reference/spatial-design.md

reference/spatial-design.md

must-a8781840-1

- **Rhythm**: Where should spacing be tight vs generous?

must-a8781840-2

- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.

must-a8781840-3

- Don't default to card grids for everything — spacing and alignment create visual grouping naturally

must-a8781840-4

- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle

must-a8781840-5

- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.

must-a8781840-6

- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.

must-7f1e8a9f-0

must-7f1e8a9f-1

- What's working? (Don't throw away good ideas)

must-7f1e8a9f-2

- **Hierarchy approach**: Which elements should stay bold (very few), which should recede?

must-7f1e8a9f-3

- **Remove decorative elements**: Gradients, shadows, patterns, textures that don't serve purpose

.impeccable.md

.impeccable.md