plcode-linux-x64-baseline-musl 2.1.0

package/.plcode/skill/experimental/design-tokens/SKILL.md

@@ -0,0 +1,456 @@
+---
+name: design-tokens
+description: Create and manage design tokens (colors, typography, spacing, shadows, radii) in a structured format compatible with Tailwind CSS, CSS variables, and shadcn/ui. Use this skill when the user asks to define, audit, refactor, or export a design token system for their project.
+category: design
+---
+
+# Design Tokens
+
+A structured skill for creating and managing design tokens in PLCODE projects. Design tokens are the atomic values — colors, typography, spacing, shadows, radii — that define a visual identity. This skill produces tokens in formats native to the PLCODE stack: Tailwind CSS config, CSS custom properties, and shadcn/ui-compatible variables.
+
+## When To Use
+
+- User asks to create a design system, token set, or visual identity for a project
+- User wants to define or refactor colors, typography, spacing, shadows, or radii
+- User asks to audit an existing `tailwind.config.ts` or `globals.css` for consistency
+- User wants to port a brand guide, Figma tokens, or external design system into Tailwind
+- User asks for WCAG contrast checks on their color palette
+- User wants dark mode token support added to an existing project
+- User wants to export tokens to a different format (CSS variables, JSON, DTCG)
+
+For building actual UI components or pages, use `frontend-design` instead. For applying a pre-built theme to an artifact, use `theme-factory`. This skill is for the **token layer itself** — the structured values that components consume.
+
+## Token Categories
+
+A complete token system covers these categories. Not all are required — build what the project needs.
+
+### 1. Colors
+
+The foundation. Define semantic color roles, not just raw hex values.
+
+| Role                                     | Purpose                      | Example                                 |
+| ---------------------------------------- | ---------------------------- | --------------------------------------- |
+| `background`                             | Page/app background          | `hsl(0 0% 100%)`                        |
+| `foreground`                             | Primary text on background   | `hsl(222 47% 11%)`                      |
+| `card` / `card-foreground`               | Card surfaces and text       | `hsl(0 0% 100%)` / `hsl(222 47% 11%)`   |
+| `popover` / `popover-foreground`         | Popover/dropdown surfaces    | `hsl(0 0% 100%)` / `hsl(222 47% 11%)`   |
+| `primary` / `primary-foreground`         | Primary actions and emphasis | `hsl(222 47% 11%)` / `hsl(210 40% 98%)` |
+| `secondary` / `secondary-foreground`     | Secondary actions            | `hsl(210 40% 96%)` / `hsl(222 47% 11%)` |
+| `muted` / `muted-foreground`             | Subdued backgrounds and text | `hsl(210 40% 96%)` / `hsl(215 16% 47%)` |
+| `accent` / `accent-foreground`           | Hover/focus highlight        | `hsl(210 40% 96%)` / `hsl(222 47% 11%)` |
+| `destructive` / `destructive-foreground` | Errors, danger, deletion     | `hsl(0 84% 60%)` / `hsl(210 40% 98%)`   |
+| `border`                                 | Default border color         | `hsl(214 32% 91%)`                      |
+| `input`                                  | Input field borders          | `hsl(214 32% 91%)`                      |
+| `ring`                                   | Focus ring color             | `hsl(222 47% 11%)`                      |
+
+**For shadcn/ui projects**, always use the HSL format without the `hsl()` wrapper in CSS variables — shadcn/ui applies `hsl()` in Tailwind config:
+
+```css
+/* globals.css */
+:root {
+  --background: 0 0% 100%;
+  --foreground: 222.2 47.4% 11.2%;
+  --primary: 222.2 47.4% 11.2%;
+  --primary-foreground: 210 40% 98%;
+  /* ... */
+}
+
+.dark {
+  --background: 222.2 84% 4.9%;
+  --foreground: 210 40% 98%;
+  --primary: 210 40% 98%;
+  --primary-foreground: 222.2 47.4% 11.2%;
+  /* ... */
+}
+```
+
+**Extended color palettes** — when the project needs a full scale (50–950), define them in `tailwind.config.ts`:
+
+```ts
+// tailwind.config.ts
+const config = {
+  theme: {
+    extend: {
+      colors: {
+        brand: {
+          50: "#f0f4ff",
+          100: "#dbe4ff",
+          200: "#bac8ff",
+          300: "#91a7ff",
+          400: "#748ffc",
+          500: "#5c7cfa",
+          600: "#4c6ef5",
+          700: "#4263eb",
+          800: "#3b5bdb",
+          900: "#364fc7",
+          950: "#2b3fa0",
+        },
+      },
+    },
+  },
+}
+```
+
+### 2. Typography
+
+Define a type scale, font families, and weight/tracking rules.
+
+```ts
+// tailwind.config.ts
+const config = {
+  theme: {
+    extend: {
+      fontFamily: {
+        sans: ["var(--font-geist-sans)", ...fontFamily.sans],
+        mono: ["var(--font-geist-mono)", ...fontFamily.mono],
+        display: ["var(--font-display)", ...fontFamily.sans],
+      },
+      fontSize: {
+        // [fontSize, { lineHeight, letterSpacing, fontWeight }]
+        "display-2xl": ["4.5rem", { lineHeight: "1.1", letterSpacing: "-0.02em", fontWeight: "700" }],
+        "display-xl": ["3.75rem", { lineHeight: "1.1", letterSpacing: "-0.02em", fontWeight: "700" }],
+        "display-lg": ["3rem", { lineHeight: "1.15", letterSpacing: "-0.02em", fontWeight: "600" }],
+        "display-md": ["2.25rem", { lineHeight: "1.2", letterSpacing: "-0.01em", fontWeight: "600" }],
+        "display-sm": ["1.875rem", { lineHeight: "1.25", letterSpacing: "-0.01em", fontWeight: "600" }],
+        "display-xs": ["1.5rem", { lineHeight: "1.3", letterSpacing: "0em", fontWeight: "600" }],
+        "body-xl": ["1.25rem", { lineHeight: "1.6" }],
+        "body-lg": ["1.125rem", { lineHeight: "1.6" }],
+        "body-md": ["1rem", { lineHeight: "1.6" }],
+        "body-sm": ["0.875rem", { lineHeight: "1.5" }],
+        "body-xs": ["0.75rem", { lineHeight: "1.5" }],
+        "label-lg": ["0.875rem", { lineHeight: "1.4", letterSpacing: "0.01em", fontWeight: "500" }],
+        "label-md": ["0.8125rem", { lineHeight: "1.4", letterSpacing: "0.01em", fontWeight: "500" }],
+        "label-sm": ["0.75rem", { lineHeight: "1.4", letterSpacing: "0.02em", fontWeight: "500" }],
+      },
+    },
+  },
+}
+```
+
+**Font loading** — use `next/font` for optimal loading:
+
+```tsx
+// app/layout.tsx
+import { GeistSans } from "geist/font/sans"
+import { GeistMono } from "geist/font/mono"
+
+export default function RootLayout({ children }: { children: React.ReactNode }) {
+  return (
+    <html lang="en" className={`${GeistSans.variable} ${GeistMono.variable}`}>
+      <body className="font-sans">{children}</body>
+    </html>
+  )
+}
+```
+
+### 3. Spacing
+
+Use Tailwind's default 4px base scale. Extend only when the project needs custom semantic spacing:
+
+```ts
+// tailwind.config.ts
+const config = {
+  theme: {
+    extend: {
+      spacing: {
+        "page-x": "clamp(1rem, 5vw, 3rem)", // responsive horizontal page padding
+        "page-y": "clamp(2rem, 8vh, 6rem)", // responsive vertical section spacing
+        section: "clamp(4rem, 12vh, 8rem)", // between major sections
+        "stack-sm": "0.5rem", // tight vertical stack
+        "stack-md": "1rem", // default vertical stack
+        "stack-lg": "1.5rem", // loose vertical stack
+      },
+    },
+  },
+}
+```
+
+**Principle:** Prefer Tailwind's built-in scale (`p-4`, `gap-6`, `mt-8`) for component-level spacing. Define custom tokens only for page-level rhythm and layout-level values that need to stay consistent across breakpoints.
+
+### 4. Shadows & Elevation
+
+Define elevation levels for layered interfaces:
+
+```ts
+// tailwind.config.ts
+const config = {
+  theme: {
+    extend: {
+      boxShadow: {
+        "elevation-1": "0 1px 2px 0 rgb(0 0 0 / 0.05)",
+        "elevation-2": "0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1)",
+        "elevation-3": "0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)",
+        "elevation-4": "0 10px 15px -3px rgb(0 0 0 / 0.1), 0 4px 6px -4px rgb(0 0 0 / 0.1)",
+        "elevation-5": "0 20px 25px -5px rgb(0 0 0 / 0.1), 0 8px 10px -6px rgb(0 0 0 / 0.1)",
+        "glow-sm": "0 0 8px -2px var(--tw-shadow-color)",
+        "glow-md": "0 0 16px -4px var(--tw-shadow-color)",
+        "inner-subtle": "inset 0 1px 2px 0 rgb(0 0 0 / 0.05)",
+      },
+    },
+  },
+}
+```
+
+For dark mode, shadows should be darker or replaced with border/glow techniques:
+
+```css
+/* globals.css */
+.dark {
+  --shadow-color: 0 0% 0%;
+  --shadow-elevation-2: 0 1px 3px 0 rgb(0 0 0 / 0.3), 0 1px 2px -1px rgb(0 0 0 / 0.3);
+}
+```
+
+### 5. Border Radius
+
+Define consistent radius tokens:
+
+```ts
+// tailwind.config.ts
+const config = {
+  theme: {
+    extend: {
+      borderRadius: {
+        lg: "var(--radius)",
+        md: "calc(var(--radius) - 2px)",
+        sm: "calc(var(--radius) - 4px)",
+      },
+    },
+  },
+}
+```
+
+```css
+/* globals.css */
+:root {
+  --radius: 0.5rem;
+}
+```
+
+This is the shadcn/ui convention — a single `--radius` variable that the entire component system references. Change the root value to reshape every component at once.
+
+### 6. Animation & Transition Tokens
+
+Define motion constants for consistency:
+
+```ts
+// tailwind.config.ts
+const config = {
+  theme: {
+    extend: {
+      transitionDuration: {
+        fast: "100ms",
+        normal: "200ms",
+        slow: "350ms",
+        slower: "500ms",
+      },
+      transitionTimingFunction: {
+        "ease-out-expo": "cubic-bezier(0.16, 1, 0.3, 1)",
+        "ease-in-out-smooth": "cubic-bezier(0.4, 0, 0.2, 1)",
+        bounce: "cubic-bezier(0.34, 1.56, 0.64, 1)",
+      },
+      keyframes: {
+        "fade-in": {
+          from: { opacity: "0" },
+          to: { opacity: "1" },
+        },
+        "slide-up": {
+          from: { opacity: "0", transform: "translateY(8px)" },
+          to: { opacity: "1", transform: "translateY(0)" },
+        },
+        "scale-in": {
+          from: { opacity: "0", transform: "scale(0.95)" },
+          to: { opacity: "1", transform: "scale(1)" },
+        },
+      },
+      animation: {
+        "fade-in": "fade-in 0.2s ease-out",
+        "slide-up": "slide-up 0.3s cubic-bezier(0.16, 1, 0.3, 1)",
+        "scale-in": "scale-in 0.2s cubic-bezier(0.16, 1, 0.3, 1)",
+      },
+    },
+  },
+}
+```
+
+## Token File Structure
+
+In a PLCODE project, tokens live in these files:
+
+```
+project/
+├── tailwind.config.ts     ← extended color scales, typography, spacing, shadows
+├── app/
+│   └── globals.css        ← CSS variables (colors, radius) consumed by Tailwind + shadcn/ui
+├── lib/
+│   └── design-tokens.ts   ← (optional) typed token export for JS consumption
+└── tokens/
+    └── tokens.json        ← (optional) W3C DTCG export for cross-tool interop
+```
+
+### Optional: Typed Token Module
+
+When tokens are needed in JavaScript (dynamic styles, charts, canvas rendering):
+
+```ts
+// lib/design-tokens.ts
+export const tokens = {
+  colors: {
+    brand: {
+      primary: "hsl(222.2 47.4% 11.2%)",
+      accent: "hsl(210 40% 96.1%)",
+      destructive: "hsl(0 84.2% 60.2%)",
+    },
+    semantic: {
+      success: "hsl(142 71% 45%)",
+      warning: "hsl(38 92% 50%)",
+      error: "hsl(0 84% 60%)",
+      info: "hsl(217 91% 60%)",
+    },
+  },
+  spacing: {
+    pageX: "clamp(1rem, 5vw, 3rem)",
+    sectionGap: "clamp(4rem, 12vh, 8rem)",
+  },
+  radii: {
+    base: "0.5rem",
+  },
+  shadows: {
+    elevation2: "0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1)",
+  },
+} as const
+
+export type DesignTokens = typeof tokens
+```
+
+### Optional: W3C DTCG Export
+
+For interop with Figma, Style Dictionary, or other design tools:
+
+```json
+{
+  "$type": "color",
+  "brand": {
+    "primary": {
+      "$value": "#1a1c2e",
+      "$description": "Primary brand color for actions and emphasis"
+    },
+    "accent": {
+      "$value": "#eef2ff",
+      "$description": "Accent background for hover/focus states"
+    }
+  }
+}
+```
+
+## Workflow: Creating a New Token System
+
+1. **Gather inputs.** Ask the user (or extract from existing assets):
+   - Brand colors or reference sites to emulate
+   - Typography direction (modern, editorial, technical, playful)
+   - Light mode, dark mode, or both
+   - Whether the project uses shadcn/ui (determines CSS variable format)
+
+2. **Audit existing files.** Before creating tokens, read:
+   - `tailwind.config.ts` — existing theme extensions
+   - `globals.css` — existing CSS variables
+   - `components/ui/` — shadcn/ui components in use
+   - `package.json` — installed font packages, dependencies
+
+3. **Define the color system.** Start with semantic roles:
+   - Background and foreground pairs (always check contrast)
+   - Primary, secondary, muted, accent
+   - Destructive / success / warning / info
+   - Border and ring colors
+   - Full scale (50–950) only if the project needs granular control
+
+4. **Define typography.** Choose:
+   - Font families (2 max: display/heading + body)
+   - Type scale with line heights, letter-spacing, and weights
+   - Set up `next/font` loading
+
+5. **Define supporting tokens:** spacing, shadows, radii, animation.
+
+6. **Write the files:**
+   - Update `globals.css` with CSS variables (light + dark)
+   - Update `tailwind.config.ts` with extended theme values
+   - Optionally create `lib/design-tokens.ts` for JS access
+   - Optionally export `tokens/tokens.json` in DTCG format
+
+7. **Validate:**
+   - Check WCAG AA contrast (4.5:1 normal text, 3:1 large text) on all foreground/background pairs
+   - Verify `tailwind.config.ts` parses without errors (`bun tsc --noEmit`)
+   - Confirm CSS variables are referenced correctly by Tailwind classes
+   - Test both light and dark modes if defined
+
+8. **Report** the files created, contrast check results, and any recommendations.
+
+## Workflow: Auditing Existing Tokens
+
+1. Read `tailwind.config.ts`, `globals.css`, and any `theme.ts` or `tokens.ts` files
+2. Inventory all color definitions — find duplicates, orphans, and inline arbitrary values
+3. Check contrast ratios for all semantic foreground/background pairs
+4. Identify missing tokens (e.g., dark mode gaps, missing semantic states)
+5. Report findings with specific fix recommendations
+6. Optionally refactor into the structured format above
+
+## Workflow: Porting External Tokens
+
+When the user provides a brand guide, Figma export, or external token file:
+
+1. Parse the source format (JSON, CSS, YAML, or prose)
+2. Map values to the semantic roles above
+3. Generate light and dark variants (compute dark mode if only light is provided)
+4. Write into the PLCODE file structure
+5. Validate contrast and completeness
+
+## Contrast Validation
+
+Always validate color contrast for these pairs:
+
+| Foreground               | Background    | Min Ratio | Standard |
+| ------------------------ | ------------- | --------- | -------- |
+| `foreground`             | `background`  | 4.5:1     | WCAG AA  |
+| `card-foreground`        | `card`        | 4.5:1     | WCAG AA  |
+| `popover-foreground`     | `popover`     | 4.5:1     | WCAG AA  |
+| `primary-foreground`     | `primary`     | 4.5:1     | WCAG AA  |
+| `secondary-foreground`   | `secondary`   | 4.5:1     | WCAG AA  |
+| `muted-foreground`       | `muted`       | 4.5:1     | WCAG AA  |
+| `muted-foreground`       | `background`  | 4.5:1     | WCAG AA  |
+| `accent-foreground`      | `accent`      | 4.5:1     | WCAG AA  |
+| `destructive-foreground` | `destructive` | 4.5:1     | WCAG AA  |
+
+Use the relative luminance formula:
+
+```
+L = 0.2126 * R + 0.7152 * G + 0.0722 * B  (where R/G/B are linearized sRGB)
+contrast = (L_lighter + 0.05) / (L_darker + 0.05)
+```
+
+Report each pair with its ratio, PASS/FAIL status, and the standard applied.
+
+## Pitfalls
+
+- **Don't scatter raw hex/hsl values across components.** Always define tokens centrally and reference them via Tailwind classes or CSS variables.
+- **Don't skip dark mode.** If the project uses shadcn/ui, dark mode is expected. Define both `:root` and `.dark` variable sets.
+- **Don't define too many tokens.** Start lean — background, foreground, primary, secondary, muted, accent, destructive, border, ring. Add more only when needed.
+- **Don't forget `foreground` pairs.** Every background token needs a corresponding foreground token with adequate contrast.
+- **Don't use `hsl()` wrapper in CSS variable values for shadcn/ui.** shadcn/ui's Tailwind config applies `hsl()` itself: `--primary: 222.2 47.4% 11.2%` not `--primary: hsl(222.2 47.4% 11.2%)`.
+- **Don't override Tailwind's base scale without reason.** Extend (`theme.extend`) instead of replacing (`theme`). Replacing wipes Tailwind's defaults.
+- **Don't forget to update `components.json`** if changing the radius or base color scheme — shadcn/ui uses this file during component generation.
+- **Quote negative values in Tailwind config.** `letterSpacing: "-0.02em"` not `letterSpacing: -0.02em`.
+- **Keep token names consistent.** Use the same naming convention across CSS variables, Tailwind config keys, and TypeScript exports (kebab-case in CSS, camelCase in TS).
+
+## Google DESIGN.md Interop
+
+For projects that also use Google's DESIGN.md format, tokens can be exported or imported:
+
+```bash
+# Export DESIGN.md to Tailwind theme JSON
+npx -y @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json
+
+# Export to W3C DTCG JSON
+npx -y @google/design.md export --format dtcg DESIGN.md > tokens.json
+```
+
+When a DESIGN.md file exists in the project, read it first and extract tokens from its YAML frontmatter before generating Tailwind config. The DESIGN.md is the source of truth; `tailwind.config.ts` and `globals.css` are derived outputs.

package/.plcode/skill/experimental/distill/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: distill
+description: Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean.
+category: design
+args:
+  - name: target
+    description: The feature or component to distill (optional)
+    required: false
+user-invokable: true
+---
+
+Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
+
+## MANDATORY PREPARATION
+
+### Context Gathering (Do This First)
+
+You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
+
+Attempt to gather these from the current thread or codebase.
+
+1. If you don't find _exact_ information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
+2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
+
+Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
+
+### Use frontend-design skill
+
+Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
+
+---
+
+## 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_instruction}}
+
+**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."