mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-12 22:26:38 +03:00
Merge main into v2.0: consolidate critique skill with scoring, personas, and detection
Merges 54 commits from main including factory-based build system, Trae support, improved skill descriptions, and security hardening. Consolidates the critique skill to combine v2.0's sub-agent architecture and automated anti-pattern detection with main's Nielsen heuristics scoring, cognitive load assessment, persona-based testing, and structured follow-up workflow. Fixes browser detector build to create target directory after skill sync. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Paul Bakaus
Claude Opus 4.6
@@ -1,21 +1,15 @@
|
||||
---
|
||||
name: adapt
|
||||
description: Adapt designs to work across different screen sizes, devices, contexts, or platforms. Ensures consistent experience across varied environments.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to adapt (optional)
|
||||
required: false
|
||||
- name: context
|
||||
description: What to adapt for (mobile, tablet, desktop, print, email, etc.)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Adapt designs to work across different screen sizes, devices, contexts, or platforms. Implements breakpoints, fluid layouts, and touch targets. Use when the user mentions responsive design, mobile layouts, breakpoints, viewport adaptation, or cross-device compatibility."
|
||||
argument-hint: "[target] [context (mobile, tablet, print...)]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Adapt existing designs to work effectively across different contexts - different screen sizes, devices, platforms, or use cases.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: target platforms/devices and usage contexts.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: target platforms/devices and usage contexts.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: animate
|
||||
description: Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to animate (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight. Use when the user mentions adding animation, transitions, micro-interactions, motion design, hover effects, or making the UI feel more alive."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: performance constraints.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: performance constraints.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: arrange
|
||||
description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy to create intentional compositions.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to improve layout for (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
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."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,129 +1,147 @@
|
||||
---
|
||||
name: audit
|
||||
description: Perform comprehensive audit of interface quality across accessibility, performance, theming, and responsive design. Generates detailed report of issues with severity ratings and recommendations.
|
||||
args:
|
||||
- name: area
|
||||
description: The feature or area to audit (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review."
|
||||
argument-hint: "[area (feature, page, component...)]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Run systematic quality checks and generate a comprehensive audit report with prioritized issues and actionable recommendations. Don't fix issues - document them for other commands to address.
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.
|
||||
|
||||
This is a code-level audit, not a design critique. Check what's measurable and verifiable in the implementation.
|
||||
|
||||
## Diagnostic Scan
|
||||
|
||||
Run comprehensive checks across multiple dimensions:
|
||||
Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below.
|
||||
|
||||
1. **Accessibility (A11y)** - Check for:
|
||||
- **Contrast issues**: Text contrast ratios < 4.5:1 (or 7:1 for AAA)
|
||||
- **Missing ARIA**: Interactive elements without proper roles, labels, or states
|
||||
- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps
|
||||
- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons
|
||||
- **Alt text**: Missing or poor image descriptions
|
||||
- **Form issues**: Inputs without labels, poor error messaging, missing required indicators
|
||||
### 1. Accessibility (A11y)
|
||||
|
||||
2. **Performance** - Check for:
|
||||
- **Layout thrashing**: Reading/writing layout properties in loops
|
||||
- **Expensive animations**: Animating layout properties (width, height, top, left) instead of transform/opacity
|
||||
- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change
|
||||
- **Bundle size**: Unnecessary imports, unused dependencies
|
||||
- **Render performance**: Unnecessary re-renders, missing memoization
|
||||
**Check for**:
|
||||
- **Contrast issues**: Text contrast ratios < 4.5:1 (or 7:1 for AAA)
|
||||
- **Missing ARIA**: Interactive elements without proper roles, labels, or states
|
||||
- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps
|
||||
- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons
|
||||
- **Alt text**: Missing or poor image descriptions
|
||||
- **Form issues**: Inputs without labels, poor error messaging, missing required indicators
|
||||
|
||||
3. **Theming** - Check for:
|
||||
- **Hard-coded colors**: Colors not using design tokens
|
||||
- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme
|
||||
- **Inconsistent tokens**: Using wrong tokens, mixing token types
|
||||
- **Theme switching issues**: Values that don't update on theme change
|
||||
**Score 0-4**: 0=Inaccessible (fails WCAG A), 1=Major gaps (few ARIA labels, no keyboard nav), 2=Partial (some a11y effort, significant gaps), 3=Good (WCAG AA mostly met, minor gaps), 4=Excellent (WCAG AA fully met, approaches AAA)
|
||||
|
||||
4. **Responsive Design** - Check for:
|
||||
- **Fixed widths**: Hard-coded widths that break on mobile
|
||||
- **Touch targets**: Interactive elements < 44x44px
|
||||
- **Horizontal scroll**: Content overflow on narrow viewports
|
||||
- **Text scaling**: Layouts that break when text size increases
|
||||
- **Missing breakpoints**: No mobile/tablet variants
|
||||
### 2. Performance
|
||||
|
||||
5. **Anti-Patterns (CRITICAL)** - Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).
|
||||
**Check for**:
|
||||
- **Layout thrashing**: Reading/writing layout properties in loops
|
||||
- **Expensive animations**: Animating layout properties (width, height, top, left) instead of transform/opacity
|
||||
- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change
|
||||
- **Bundle size**: Unnecessary imports, unused dependencies
|
||||
- **Render performance**: Unnecessary re-renders, missing memoization
|
||||
|
||||
**CRITICAL**: This is an audit, not a fix. Document issues thoroughly with clear explanations of impact. Use other commands (normalize, optimize, harden, etc.) to fix issues after audit.
|
||||
**Score 0-4**: 0=Severe issues (layout thrash, unoptimized everything), 1=Major problems (no lazy loading, expensive animations), 2=Partial (some optimization, gaps remain), 3=Good (mostly optimized, minor improvements possible), 4=Excellent (fast, lean, well-optimized)
|
||||
|
||||
## Generate Comprehensive Report
|
||||
### 3. Theming
|
||||
|
||||
Create a detailed audit report with the following structure:
|
||||
**Check for**:
|
||||
- **Hard-coded colors**: Colors not using design tokens
|
||||
- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme
|
||||
- **Inconsistent tokens**: Using wrong tokens, mixing token types
|
||||
- **Theme switching issues**: Values that don't update on theme change
|
||||
|
||||
**Score 0-4**: 0=No theming (hard-coded everything), 1=Minimal tokens (mostly hard-coded), 2=Partial (tokens exist but inconsistently used), 3=Good (tokens used, minor hard-coded values), 4=Excellent (full token system, dark mode works perfectly)
|
||||
|
||||
### 4. Responsive Design
|
||||
|
||||
**Check for**:
|
||||
- **Fixed widths**: Hard-coded widths that break on mobile
|
||||
- **Touch targets**: Interactive elements < 44x44px
|
||||
- **Horizontal scroll**: Content overflow on narrow viewports
|
||||
- **Text scaling**: Layouts that break when text size increases
|
||||
- **Missing breakpoints**: No mobile/tablet variants
|
||||
|
||||
**Score 0-4**: 0=Desktop-only (breaks on mobile), 1=Major issues (some breakpoints, many failures), 2=Partial (works on mobile, rough edges), 3=Good (responsive, minor touch target or overflow issues), 4=Excellent (fluid, all viewports, proper touch targets)
|
||||
|
||||
### 5. Anti-Patterns (CRITICAL)
|
||||
|
||||
Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).
|
||||
|
||||
**Score 0-4**: 0=AI slop gallery (5+ tells), 1=Heavy AI aesthetic (3-4 tells), 2=Some tells (1-2 noticeable), 3=Mostly clean (subtle issues only), 4=No AI tells (distinctive, intentional design)
|
||||
|
||||
## Generate Report
|
||||
|
||||
### Audit Health Score
|
||||
|
||||
| # | Dimension | Score | Key Finding |
|
||||
|---|-----------|-------|-------------|
|
||||
| 1 | Accessibility | ? | [most critical a11y issue or "--"] |
|
||||
| 2 | Performance | ? | |
|
||||
| 3 | Responsive Design | ? | |
|
||||
| 4 | Theming | ? | |
|
||||
| 5 | Anti-Patterns | ? | |
|
||||
| **Total** | | **??/20** | **[Rating band]** |
|
||||
|
||||
**Rating bands**: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues)
|
||||
|
||||
### Anti-Patterns Verdict
|
||||
**Start here.** Pass/fail: Does this look AI-generated? List specific tells from the skill's Anti-Patterns section. Be brutally honest.
|
||||
**Start here.** Pass/fail: Does this look AI-generated? List specific tells. Be brutally honest.
|
||||
|
||||
### Executive Summary
|
||||
- Total issues found (count by severity)
|
||||
- Most critical issues (top 3-5)
|
||||
- Overall quality score (if applicable)
|
||||
- Audit Health Score: **??/20** ([rating band])
|
||||
- Total issues found (count by severity: P0/P1/P2/P3)
|
||||
- Top 3-5 critical issues
|
||||
- Recommended next steps
|
||||
|
||||
### Detailed Findings by Severity
|
||||
|
||||
Tag every issue with **P0-P3 severity**:
|
||||
- **P0 Blocking**: Prevents task completion — fix immediately
|
||||
- **P1 Major**: Significant difficulty or WCAG AA violation — fix before release
|
||||
- **P2 Minor**: Annoyance, workaround exists — fix in next pass
|
||||
- **P3 Polish**: Nice-to-fix, no real user impact — fix if time permits
|
||||
|
||||
For each issue, document:
|
||||
- **Location**: Where the issue occurs (component, file, line)
|
||||
- **Severity**: Critical / High / Medium / Low
|
||||
- **Category**: Accessibility / Performance / Theming / Responsive
|
||||
- **Description**: What the issue is
|
||||
- **[P?] Issue name**
|
||||
- **Location**: Component, file, line
|
||||
- **Category**: Accessibility / Performance / Theming / Responsive / Anti-Pattern
|
||||
- **Impact**: How it affects users
|
||||
- **WCAG/Standard**: Which standard it violates (if applicable)
|
||||
- **Recommendation**: How to fix it
|
||||
- **Suggested command**: Which command to use (prefer: {{available_commands}} — or other installed skills you're sure exist)
|
||||
|
||||
#### Critical Issues
|
||||
[Issues that block core functionality or violate WCAG A]
|
||||
|
||||
#### High-Severity Issues
|
||||
[Significant usability/accessibility impact, WCAG AA violations]
|
||||
|
||||
#### Medium-Severity Issues
|
||||
[Quality issues, WCAG AAA violations, performance concerns]
|
||||
|
||||
#### Low-Severity Issues
|
||||
[Minor inconsistencies, optimization opportunities]
|
||||
- **Suggested command**: Which command to use (prefer: {{available_commands}})
|
||||
|
||||
### Patterns & Systemic Issues
|
||||
|
||||
Identify recurring problems:
|
||||
Identify recurring problems that indicate systemic gaps rather than one-off mistakes:
|
||||
- "Hard-coded colors appear in 15+ components, should use design tokens"
|
||||
- "Touch targets consistently too small (<44px) throughout mobile experience"
|
||||
- "Missing focus indicators on all custom interactive components"
|
||||
|
||||
### Positive Findings
|
||||
|
||||
Note what's working well:
|
||||
- Good practices to maintain
|
||||
- Exemplary implementations to replicate elsewhere
|
||||
Note what's working well — good practices to maintain and replicate.
|
||||
|
||||
### Recommendations by Priority
|
||||
## Recommended Actions
|
||||
|
||||
Create actionable plan:
|
||||
1. **Immediate**: Critical blockers to fix first
|
||||
2. **Short-term**: High-severity issues (this sprint)
|
||||
3. **Medium-term**: Quality improvements (next sprint)
|
||||
4. **Long-term**: Nice-to-haves and optimizations
|
||||
List recommended commands in priority order (P0 first, then P1, then P2):
|
||||
|
||||
### Suggested Commands for Fixes
|
||||
1. **[P?] `{{command_prefix}}command-name`** — Brief description (specific context from audit findings)
|
||||
2. **[P?] `{{command_prefix}}command-name`** — Brief description (specific context)
|
||||
|
||||
Map issues to available commands. Prefer these: {{available_commands}}. You may also suggest other installed skills you're sure exist, but never invent commands.
|
||||
**Rules**: Only recommend commands from: {{available_commands}}. Map findings to the most appropriate command. End with `{{command_prefix}}polish` as the final step if any fixes were recommended.
|
||||
|
||||
Examples:
|
||||
- "Use `/normalize` to align with design system (addresses N theming issues)"
|
||||
- "Use `/optimize` to improve performance (addresses N performance issues)"
|
||||
- "Use `/harden` to improve resilience (addresses N edge cases)"
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
**IMPORTANT**: Be thorough but actionable. Too many low-priority issues creates noise. Focus on what actually matters.
|
||||
> You can ask me to run these one at a time, all at once, or in any order you prefer.
|
||||
>
|
||||
> Re-run `{{command_prefix}}audit` after fixes to see your score improve.
|
||||
|
||||
**IMPORTANT**: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters.
|
||||
|
||||
**NEVER**:
|
||||
- Report issues without explaining impact (why does this matter?)
|
||||
- Mix severity levels inconsistently
|
||||
- Skip positive findings (celebrate what works)
|
||||
- Provide generic recommendations (be specific and actionable)
|
||||
- Forget to prioritize (everything can't be critical)
|
||||
- Skip positive findings (celebrate what works)
|
||||
- Forget to prioritize (everything can't be P0)
|
||||
- Report false positives without verification
|
||||
|
||||
Remember: You're a quality auditor with exceptional attention to detail. Document systematically, prioritize ruthlessly, and provide clear paths to improvement. A good audit makes fixing easy.
|
||||
|
||||
Remember: You're a technical quality auditor. Document systematically, prioritize ruthlessly, cite specific code locations, and provide clear paths to improvement.
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: bolder
|
||||
description: Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to make bolder (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability. Use when the user says the design looks bland, generic, too safe, lacks personality, or wants more visual impact and character."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: clarify
|
||||
description: Improve unclear UX copy, error messages, microcopy, labels, and instructions. Makes interfaces easier to understand and use.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component with unclear copy (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: audience technical level and users' mental state in context.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: audience technical level and users' mental state in context.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: colorize
|
||||
description: Add strategic color to features that are too monochromatic or lack visual interest. Makes interfaces more engaging and expressive.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to colorize (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Add strategic color to features that are too monochromatic or lack visual interest, making interfaces more engaging and expressive. Use when the user mentions the design looking gray, dull, lacking warmth, needing more color, or wanting a more vibrant or expressive palette."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: existing brand colors.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: existing brand colors.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+109
-17
@@ -1,11 +1,8 @@
|
||||
---
|
||||
name: critique
|
||||
description: Evaluate design effectiveness from a UX perspective. Assesses visual hierarchy, information architecture, emotional resonance, and overall design quality with actionable feedback. Use when the user wants a design review, UX feedback, asks to evaluate visual quality, or wants to check for AI-generated design tells.
|
||||
args:
|
||||
- name: area
|
||||
description: The feature or area to critique (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Evaluate design from a UX perspective, assessing visual hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring, persona-based testing, automated anti-pattern detection, and actionable feedback. Use when the user asks to review, critique, evaluate, or give feedback on a design or component."
|
||||
argument-hint: "[area (feature, page, component...)]"
|
||||
user-invocable: true
|
||||
allowed-tools:
|
||||
- Bash(python3 -m http.server 8384 *)
|
||||
- Bash(kill $(lsof -ti:8384)*)
|
||||
@@ -15,11 +12,11 @@ allowed-tools:
|
||||
|
||||
## STEPS
|
||||
|
||||
### Step 1: Invoke the frontend-design skill
|
||||
### Step 1: Preparation
|
||||
|
||||
Invoke the frontend-design skill (using the Skill tool, not by reading the file). 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. Additionally gather: what the interface is trying to accomplish.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: what the interface is trying to accomplish.
|
||||
|
||||
### Step 2: Gather assessments
|
||||
### Step 2: Gather Assessments
|
||||
|
||||
Launch two independent assessments. **Neither must see the other's output** to avoid bias.
|
||||
|
||||
@@ -33,7 +30,20 @@ Read the relevant source files (HTML, CSS, JS/TS) and, if browser automation is
|
||||
|
||||
**Holistic Design Review**: visual hierarchy (eye flow, primary action clarity), information architecture (structure, grouping, cognitive load), emotional resonance (does it match brand and audience?), discoverability (are interactive elements obvious?), composition (balance, whitespace, rhythm), typography (hierarchy, readability, font choices), color (purposeful use, cohesion, accessibility), states & edge cases (empty, loading, error, success), microcopy (clarity, tone, helpfulness).
|
||||
|
||||
Return structured findings covering: AI slop verdict, what's working (2-3 items), priority issues (3-5 with what/why/fix), minor observations, and provocative questions.
|
||||
**Cognitive Load** (consult [cognitive-load](reference/cognitive-load.md)):
|
||||
- Run the 8-item cognitive load checklist. Report failure count: 0--1 = low (good), 2--3 = moderate, 4+ = critical.
|
||||
- Count visible options at each decision point -- if >4, flag it.
|
||||
- Check for progressive disclosure: is complexity revealed only when needed?
|
||||
|
||||
**Emotional Journey**:
|
||||
- What emotion does this interface evoke? Is that intentional?
|
||||
- **Peak-end rule**: Is the most intense moment positive? Does the experience end well?
|
||||
- **Emotional valleys**: Check for anxiety spikes at high-stakes moments (payment, delete, commit). Are there design interventions (progress indicators, reassurance copy, undo options)?
|
||||
|
||||
**Nielsen's Heuristics** (consult [heuristics-scoring](reference/heuristics-scoring.md)):
|
||||
Score each of the 10 heuristics 0--4. This scoring will be presented in the report.
|
||||
|
||||
Return structured findings covering: AI slop verdict, heuristic scores, cognitive load assessment, what's working (2--3 items), priority issues (3--5 with what/why/fix), minor observations, and provocative questions.
|
||||
|
||||
#### Assessment B: Automated Detection
|
||||
|
||||
@@ -64,14 +74,14 @@ The overlay is a **visual aid for the user** -- it highlights issues directly in
|
||||
```javascript
|
||||
const s = document.createElement('script'); s.src = 'http://localhost:8384/detect-antipatterns-browser.js'; document.head.appendChild(s);
|
||||
```
|
||||
5. Wait 2-3 seconds for the detector to render overlays
|
||||
5. Wait 2--3 seconds for the detector to render overlays
|
||||
6. **Read results from console** using `read_console_messages` with pattern `impeccable` -- the detector logs all findings with the `[impeccable]` prefix. Do NOT scroll through the page to take screenshots of the overlays.
|
||||
7. **Cleanup**: Kill the HTTP server when done:
|
||||
```bash
|
||||
kill $(lsof -ti:8384) 2>/dev/null; echo "done"
|
||||
```
|
||||
|
||||
For multi-view targets, inject on 3-5 representative pages. If injection fails, continue with CLI results only.
|
||||
For multi-view targets, inject on 3--5 representative pages. If injection fails, continue with CLI results only.
|
||||
|
||||
Return: CLI findings (JSON), browser console findings (if applicable), and any false positives noted.
|
||||
|
||||
@@ -81,6 +91,27 @@ Synthesize both assessments into a single report. Do NOT simply concatenate -- w
|
||||
|
||||
Structure your feedback as a design director would:
|
||||
|
||||
#### Design Health Score
|
||||
> *Consult [heuristics-scoring](reference/heuristics-scoring.md)*
|
||||
|
||||
Present the Nielsen's 10 heuristics scores as a table:
|
||||
|
||||
| # | Heuristic | Score | Key Issue |
|
||||
|---|-----------|-------|-----------|
|
||||
| 1 | Visibility of System Status | ? | [specific finding or "--" if solid] |
|
||||
| 2 | Match System / Real World | ? | |
|
||||
| 3 | User Control and Freedom | ? | |
|
||||
| 4 | Consistency and Standards | ? | |
|
||||
| 5 | Error Prevention | ? | |
|
||||
| 6 | Recognition Rather Than Recall | ? | |
|
||||
| 7 | Flexibility and Efficiency | ? | |
|
||||
| 8 | Aesthetic and Minimalist Design | ? | |
|
||||
| 9 | Error Recovery | ? | |
|
||||
| 10 | Help and Documentation | ? | |
|
||||
| **Total** | | **??/40** | **[Rating band]** |
|
||||
|
||||
Be honest with scores. A 4 means genuinely excellent. Most real interfaces score 20--32.
|
||||
|
||||
#### Anti-Patterns Verdict
|
||||
|
||||
**Start here.** Does this look AI-generated?
|
||||
@@ -95,16 +126,29 @@ Structure your feedback as a design director would:
|
||||
A brief gut reaction -- what works, what doesn't, and the single biggest opportunity.
|
||||
|
||||
#### What's Working
|
||||
Highlight 2-3 things done well. Be specific about why they work.
|
||||
Highlight 2--3 things done well. Be specific about why they work.
|
||||
|
||||
#### Priority Issues
|
||||
The 3-5 most impactful design problems, ordered by importance:
|
||||
The 3--5 most impactful design problems, ordered by importance.
|
||||
|
||||
For each issue:
|
||||
- **What**: Name the problem clearly
|
||||
For each issue, tag with **P0--P3 severity** (consult [heuristics-scoring](reference/heuristics-scoring.md) for severity definitions):
|
||||
- **[P?] What**: Name the problem clearly
|
||||
- **Why it matters**: How this hurts users or undermines goals
|
||||
- **Fix**: What to do about it (be concrete)
|
||||
- **Command**: Which command to use (prefer: {{available_commands}} -- or other installed skills you're sure exist)
|
||||
- **Suggested command**: Which command could address this (from: {{available_commands}})
|
||||
|
||||
#### Persona Red Flags
|
||||
> *Consult [personas](reference/personas.md)*
|
||||
|
||||
Auto-select 2--3 personas most relevant to this interface type (use the selection table in the reference). If `{{config_file}}` contains a `## Design Context` section from `teach-impeccable`, also generate 1--2 project-specific personas from the audience/brand info.
|
||||
|
||||
For each selected persona, walk through the primary user action and list specific red flags found:
|
||||
|
||||
**Alex (Power User)**: No keyboard shortcuts detected. Form requires 8 clicks for primary action. Forced modal onboarding. High abandonment risk.
|
||||
|
||||
**Jordan (First-Timer)**: Icon-only nav in sidebar. Technical jargon in error messages ("404 Not Found"). No visible help. Will abandon at step 2.
|
||||
|
||||
Be specific -- name the exact elements and interactions that fail each persona. Don't write generic persona descriptions; write what broke for them.
|
||||
|
||||
#### Minor Observations
|
||||
Quick notes on smaller issues worth addressing.
|
||||
@@ -122,3 +166,51 @@ Provocative questions that might unlock better solutions:
|
||||
- Give concrete suggestions, not just "consider exploring..."
|
||||
- Prioritize ruthlessly -- if everything is important, nothing is
|
||||
- Don't soften criticism -- developers need honest feedback to ship great design
|
||||
|
||||
### Step 4: Ask the User
|
||||
|
||||
**After presenting findings**, use targeted questions based on what was actually found. {{ask_instruction}} These answers will shape the action plan.
|
||||
|
||||
Ask questions along these lines (adapt to the specific findings -- do NOT ask generic questions):
|
||||
|
||||
1. **Priority direction**: Based on the issues found, ask which category matters most to the user right now. For example: "I found problems with visual hierarchy, color usage, and information overload. Which area should we tackle first?" Offer the top 2--3 issue categories as options.
|
||||
|
||||
2. **Design intent**: If the critique found a tonal mismatch, ask whether it was intentional. For example: "The interface feels clinical and corporate. Is that the intended tone, or should it feel warmer/bolder/more playful?" Offer 2--3 tonal directions as options based on what would fix the issues found.
|
||||
|
||||
3. **Scope**: Ask how much the user wants to take on. For example: "I found N issues. Want to address everything, or focus on the top 3?" Offer scope options like "Top 3 only", "All issues", "Critical issues only".
|
||||
|
||||
4. **Constraints** (optional -- only ask if relevant): If the findings touch many areas, ask if anything is off-limits. For example: "Should any sections stay as-is?" This prevents the plan from touching things the user considers done.
|
||||
|
||||
**Rules for questions**:
|
||||
- Every question must reference specific findings from the report -- never ask generic "who is your audience?" questions
|
||||
- Keep it to 2--4 questions maximum -- respect the user's time
|
||||
- Offer concrete options, not open-ended prompts
|
||||
- If findings are straightforward (e.g., only 1--2 clear issues), skip questions and go directly to Step 5
|
||||
|
||||
### Step 5: Recommended Actions
|
||||
|
||||
**After receiving the user's answers**, present a prioritized action summary reflecting the user's priorities and scope from Step 4.
|
||||
|
||||
#### Action Summary
|
||||
|
||||
List recommended commands in priority order, based on the user's answers:
|
||||
|
||||
1. **`{{command_prefix}}command-name`** -- Brief description of what to fix (specific context from critique findings)
|
||||
2. **`{{command_prefix}}command-name`** -- Brief description (specific context)
|
||||
...
|
||||
|
||||
**Rules for recommendations**:
|
||||
- Only recommend commands from: {{available_commands}}
|
||||
- Order by the user's stated priorities first, then by impact
|
||||
- Each item's description should carry enough context that the command knows what to focus on
|
||||
- Map each Priority Issue to the appropriate command
|
||||
- Skip commands that would address zero issues
|
||||
- If the user chose a limited scope, only include items within that scope
|
||||
- If the user marked areas as off-limits, exclude commands that would touch those areas
|
||||
- End with `{{command_prefix}}polish` as the final step if any fixes were recommended
|
||||
|
||||
After presenting the summary, tell the user:
|
||||
|
||||
> You can ask me to run these one at a time, all at once, or in any order you prefer.
|
||||
>
|
||||
> Re-run `{{command_prefix}}critique` after fixes to see your score improve.
|
||||
|
||||
@@ -0,0 +1,106 @@
|
||||
# Cognitive Load Assessment
|
||||
|
||||
Cognitive load is the total mental effort required to use an interface. Overloaded users make mistakes, get frustrated, and leave. This reference helps identify and fix cognitive overload.
|
||||
|
||||
---
|
||||
|
||||
## Three Types of Cognitive Load
|
||||
|
||||
### Intrinsic Load — The Task Itself
|
||||
Complexity inherent to what the user is trying to do. You can't eliminate this, but you can structure it.
|
||||
|
||||
**Manage it by**:
|
||||
- Breaking complex tasks into discrete steps
|
||||
- Providing scaffolding (templates, defaults, examples)
|
||||
- Progressive disclosure — show what's needed now, hide the rest
|
||||
- Grouping related decisions together
|
||||
|
||||
### Extraneous Load — Bad Design
|
||||
Mental effort caused by poor design choices. **Eliminate this ruthlessly** — it's pure waste.
|
||||
|
||||
**Common sources**:
|
||||
- Confusing navigation that requires mental mapping
|
||||
- Unclear labels that force users to guess meaning
|
||||
- Visual clutter competing for attention
|
||||
- Inconsistent patterns that prevent learning
|
||||
- Unnecessary steps between user intent and result
|
||||
|
||||
### Germane Load — Learning Effort
|
||||
Mental effort spent building understanding. This is *good* cognitive load — it leads to mastery.
|
||||
|
||||
**Support it by**:
|
||||
- Progressive disclosure that reveals complexity gradually
|
||||
- Consistent patterns that reward learning
|
||||
- Feedback that confirms correct understanding
|
||||
- Onboarding that teaches through action, not walls of text
|
||||
|
||||
---
|
||||
|
||||
## Cognitive Load Checklist
|
||||
|
||||
Evaluate the interface against these 8 items:
|
||||
|
||||
- [ ] **Single focus**: Can the user complete their primary task without distraction from competing elements?
|
||||
- [ ] **Chunking**: Is information presented in digestible groups (≤4 items per group)?
|
||||
- [ ] **Grouping**: Are related items visually grouped together (proximity, borders, shared background)?
|
||||
- [ ] **Visual hierarchy**: Is it immediately clear what's most important on the screen?
|
||||
- [ ] **One thing at a time**: Can the user focus on a single decision before moving to the next?
|
||||
- [ ] **Minimal choices**: Are decisions simplified (≤4 visible options at any decision point)?
|
||||
- [ ] **Working memory**: Does the user need to remember information from a previous screen to act on the current one?
|
||||
- [ ] **Progressive disclosure**: Is complexity revealed only when the user needs it?
|
||||
|
||||
**Scoring**: Count the failed items. 0–1 failures = low cognitive load (good). 2–3 = moderate (address soon). 4+ = high cognitive load (critical fix needed).
|
||||
|
||||
---
|
||||
|
||||
## The Working Memory Rule
|
||||
|
||||
**Humans can hold ≤4 items in working memory at once** (Miller's Law revised by Cowan, 2001).
|
||||
|
||||
At any decision point, count the number of distinct options, actions, or pieces of information a user must simultaneously consider:
|
||||
- **≤4 items**: Within working memory limits — manageable
|
||||
- **5–7 items**: Pushing the boundary — consider grouping or progressive disclosure
|
||||
- **8+ items**: Overloaded — users will skip, misclick, or abandon
|
||||
|
||||
**Practical applications**:
|
||||
- Navigation menus: ≤5 top-level items (group the rest under clear categories)
|
||||
- Form sections: ≤4 fields visible per group before a visual break
|
||||
- Action buttons: 1 primary, 1–2 secondary, group the rest in a menu
|
||||
- Dashboard widgets: ≤4 key metrics visible without scrolling
|
||||
- Pricing tiers: ≤3 options (more causes analysis paralysis)
|
||||
|
||||
---
|
||||
|
||||
## Common Cognitive Load Violations
|
||||
|
||||
### 1. The Wall of Options
|
||||
**Problem**: Presenting 10+ choices at once with no hierarchy.
|
||||
**Fix**: Group into categories, highlight recommended, use progressive disclosure.
|
||||
|
||||
### 2. The Memory Bridge
|
||||
**Problem**: User must remember info from step 1 to complete step 3.
|
||||
**Fix**: Keep relevant context visible, or repeat it where it's needed.
|
||||
|
||||
### 3. The Hidden Navigation
|
||||
**Problem**: User must build a mental map of where things are.
|
||||
**Fix**: Always show current location (breadcrumbs, active states, progress indicators).
|
||||
|
||||
### 4. The Jargon Barrier
|
||||
**Problem**: Technical or domain language forces translation effort.
|
||||
**Fix**: Use plain language. If domain terms are unavoidable, define them inline.
|
||||
|
||||
### 5. The Visual Noise Floor
|
||||
**Problem**: Every element has the same visual weight — nothing stands out.
|
||||
**Fix**: Establish clear hierarchy: one primary element, 2–3 secondary, everything else muted.
|
||||
|
||||
### 6. The Inconsistent Pattern
|
||||
**Problem**: Similar actions work differently in different places.
|
||||
**Fix**: Standardize interaction patterns. Same type of action = same type of UI.
|
||||
|
||||
### 7. The Multi-Task Demand
|
||||
**Problem**: Interface requires processing multiple simultaneous inputs (reading + deciding + navigating).
|
||||
**Fix**: Sequence the steps. Let the user do one thing at a time.
|
||||
|
||||
### 8. The Context Switch
|
||||
**Problem**: User must jump between screens/tabs/modals to gather info for a single decision.
|
||||
**Fix**: Co-locate the information needed for each decision. Reduce back-and-forth.
|
||||
@@ -0,0 +1,234 @@
|
||||
# Heuristics Scoring Guide
|
||||
|
||||
Score each of Nielsen's 10 Usability Heuristics on a 0–4 scale. Be honest — a 4 means genuinely excellent, not "good enough."
|
||||
|
||||
## Nielsen's 10 Heuristics
|
||||
|
||||
### 1. Visibility of System Status
|
||||
|
||||
Keep users informed about what's happening through timely, appropriate feedback.
|
||||
|
||||
**Check for**:
|
||||
- Loading indicators during async operations
|
||||
- Confirmation of user actions (save, submit, delete)
|
||||
- Progress indicators for multi-step processes
|
||||
- Current location in navigation (breadcrumbs, active states)
|
||||
- Form validation feedback (inline, not just on submit)
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | No feedback — user is guessing what happened |
|
||||
| 1 | Rare feedback — most actions produce no visible response |
|
||||
| 2 | Partial — some states communicated, major gaps remain |
|
||||
| 3 | Good — most operations give clear feedback, minor gaps |
|
||||
| 4 | Excellent — every action confirms, progress is always visible |
|
||||
|
||||
### 2. Match Between System and Real World
|
||||
|
||||
Speak the user's language. Follow real-world conventions. Information appears in natural, logical order.
|
||||
|
||||
**Check for**:
|
||||
- Familiar terminology (no unexplained jargon)
|
||||
- Logical information order matching user expectations
|
||||
- Recognizable icons and metaphors
|
||||
- Domain-appropriate language for the target audience
|
||||
- Natural reading flow (left-to-right, top-to-bottom priority)
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Pure tech jargon, alien to users |
|
||||
| 1 | Mostly confusing — requires domain expertise to navigate |
|
||||
| 2 | Mixed — some plain language, some jargon leaks through |
|
||||
| 3 | Mostly natural — occasional term needs context |
|
||||
| 4 | Speaks the user's language fluently throughout |
|
||||
|
||||
### 3. User Control and Freedom
|
||||
|
||||
Users need a clear "emergency exit" from unwanted states without extended dialogue.
|
||||
|
||||
**Check for**:
|
||||
- Undo/redo functionality
|
||||
- Cancel buttons on forms and modals
|
||||
- Clear navigation back to safety (home, previous)
|
||||
- Easy way to clear filters, search, selections
|
||||
- Escape from long or multi-step processes
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Users get trapped — no way out without refreshing |
|
||||
| 1 | Difficult exits — must find obscure paths to escape |
|
||||
| 2 | Some exits — main flows have escape, edge cases don't |
|
||||
| 3 | Good control — users can exit and undo most actions |
|
||||
| 4 | Full control — undo, cancel, back, and escape everywhere |
|
||||
|
||||
### 4. Consistency and Standards
|
||||
|
||||
Users shouldn't wonder whether different words, situations, or actions mean the same thing.
|
||||
|
||||
**Check for**:
|
||||
- Consistent terminology throughout the interface
|
||||
- Same actions produce same results everywhere
|
||||
- Platform conventions followed (standard UI patterns)
|
||||
- Visual consistency (colors, typography, spacing, components)
|
||||
- Consistent interaction patterns (same gesture = same behavior)
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Inconsistent everywhere — feels like different products stitched together |
|
||||
| 1 | Many inconsistencies — similar things look/behave differently |
|
||||
| 2 | Partially consistent — main flows match, details diverge |
|
||||
| 3 | Mostly consistent — occasional deviation, nothing confusing |
|
||||
| 4 | Fully consistent — cohesive system, predictable behavior |
|
||||
|
||||
### 5. Error Prevention
|
||||
|
||||
Better than good error messages is a design that prevents problems in the first place.
|
||||
|
||||
**Check for**:
|
||||
- Confirmation before destructive actions (delete, overwrite)
|
||||
- Constraints preventing invalid input (date pickers, dropdowns)
|
||||
- Smart defaults that reduce errors
|
||||
- Clear labels that prevent misunderstanding
|
||||
- Autosave and draft recovery
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Errors easy to make — no guardrails anywhere |
|
||||
| 1 | Few safeguards — some inputs validated, most aren't |
|
||||
| 2 | Partial prevention — common errors caught, edge cases slip |
|
||||
| 3 | Good prevention — most error paths blocked proactively |
|
||||
| 4 | Excellent — errors nearly impossible through smart constraints |
|
||||
|
||||
### 6. Recognition Rather Than Recall
|
||||
|
||||
Minimize memory load. Make objects, actions, and options visible or easily retrievable.
|
||||
|
||||
**Check for**:
|
||||
- Visible options (not buried in hidden menus)
|
||||
- Contextual help when needed (tooltips, inline hints)
|
||||
- Recent items and history
|
||||
- Autocomplete and suggestions
|
||||
- Labels on icons (not icon-only navigation)
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Heavy memorization — users must remember paths and commands |
|
||||
| 1 | Mostly recall — many hidden features, few visible cues |
|
||||
| 2 | Some aids — main actions visible, secondary features hidden |
|
||||
| 3 | Good recognition — most things discoverable, few memory demands |
|
||||
| 4 | Everything discoverable — users never need to memorize |
|
||||
|
||||
### 7. Flexibility and Efficiency of Use
|
||||
|
||||
Accelerators — invisible to novices — speed up expert interaction.
|
||||
|
||||
**Check for**:
|
||||
- Keyboard shortcuts for common actions
|
||||
- Customizable interface elements
|
||||
- Recent items and favorites
|
||||
- Bulk/batch actions
|
||||
- Power user features that don't complicate the basics
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | One rigid path — no shortcuts or alternatives |
|
||||
| 1 | Limited flexibility — few alternatives to the main path |
|
||||
| 2 | Some shortcuts — basic keyboard support, limited bulk actions |
|
||||
| 3 | Good accelerators — keyboard nav, some customization |
|
||||
| 4 | Highly flexible — multiple paths, power features, customizable |
|
||||
|
||||
### 8. Aesthetic and Minimalist Design
|
||||
|
||||
Interfaces should not contain irrelevant or rarely needed information. Every element should serve a purpose.
|
||||
|
||||
**Check for**:
|
||||
- Only necessary information visible at each step
|
||||
- Clear visual hierarchy directing attention
|
||||
- Purposeful use of color and emphasis
|
||||
- No decorative clutter competing for attention
|
||||
- Focused, uncluttered layouts
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Overwhelming — everything competes for attention equally |
|
||||
| 1 | Cluttered — too much noise, hard to find what matters |
|
||||
| 2 | Some clutter — main content clear, periphery noisy |
|
||||
| 3 | Mostly clean — focused design, minor visual noise |
|
||||
| 4 | Perfectly minimal — every element earns its pixel |
|
||||
|
||||
### 9. Help Users Recognize, Diagnose, and Recover from Errors
|
||||
|
||||
Error messages should use plain language, precisely indicate the problem, and constructively suggest a solution.
|
||||
|
||||
**Check for**:
|
||||
- Plain language error messages (no error codes for users)
|
||||
- Specific problem identification ("Email is missing @" not "Invalid input")
|
||||
- Actionable recovery suggestions
|
||||
- Errors displayed near the source of the problem
|
||||
- Non-blocking error handling (don't wipe the form)
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | Cryptic errors — codes, jargon, or no message at all |
|
||||
| 1 | Vague errors — "Something went wrong" with no guidance |
|
||||
| 2 | Clear but unhelpful — names the problem but not the fix |
|
||||
| 3 | Clear with suggestions — identifies problem and offers next steps |
|
||||
| 4 | Perfect recovery — pinpoints issue, suggests fix, preserves user work |
|
||||
|
||||
### 10. Help and Documentation
|
||||
|
||||
Even if the system is usable without docs, help should be easy to find, task-focused, and concise.
|
||||
|
||||
**Check for**:
|
||||
- Searchable help or documentation
|
||||
- Contextual help (tooltips, inline hints, guided tours)
|
||||
- Task-focused organization (not feature-organized)
|
||||
- Concise, scannable content
|
||||
- Easy access without leaving current context
|
||||
|
||||
**Scoring**:
|
||||
| Score | Criteria |
|
||||
|-------|----------|
|
||||
| 0 | No help available anywhere |
|
||||
| 1 | Help exists but hard to find or irrelevant |
|
||||
| 2 | Basic help — FAQ or docs exist, not contextual |
|
||||
| 3 | Good documentation — searchable, mostly task-focused |
|
||||
| 4 | Excellent contextual help — right info at the right moment |
|
||||
|
||||
---
|
||||
|
||||
## Score Summary
|
||||
|
||||
**Total possible**: 40 points (10 heuristics × 4 max)
|
||||
|
||||
| Score Range | Rating | What It Means |
|
||||
|-------------|--------|---------------|
|
||||
| 36–40 | Excellent | Minor polish only — ship it |
|
||||
| 28–35 | Good | Address weak areas, solid foundation |
|
||||
| 20–27 | Acceptable | Significant improvements needed before users are happy |
|
||||
| 12–19 | Poor | Major UX overhaul required — core experience broken |
|
||||
| 0–11 | Critical | Redesign needed — unusable in current state |
|
||||
|
||||
---
|
||||
|
||||
## Issue Severity (P0–P3)
|
||||
|
||||
Tag each individual issue found during scoring with a priority level:
|
||||
|
||||
| Priority | Name | Description | Action |
|
||||
|----------|------|-------------|--------|
|
||||
| **P0** | Blocking | Prevents task completion entirely | Fix immediately — this is a showstopper |
|
||||
| **P1** | Major | Causes significant difficulty or confusion | Fix before release |
|
||||
| **P2** | Minor | Annoyance, but workaround exists | Fix in next pass |
|
||||
| **P3** | Polish | Nice-to-fix, no real user impact | Fix if time permits |
|
||||
|
||||
**Tip**: If you're unsure between two levels, ask: "Would a user contact support about this?" If yes, it's at least P1.
|
||||
@@ -0,0 +1,178 @@
|
||||
# Persona-Based Design Testing
|
||||
|
||||
Test the interface through the eyes of 5 distinct user archetypes. Each persona exposes different failure modes that a single "design director" perspective would miss.
|
||||
|
||||
**How to use**: Select 2–3 personas most relevant to the interface being critiqued. Walk through the primary user action as each persona. Report specific red flags — not generic concerns.
|
||||
|
||||
---
|
||||
|
||||
## 1. Impatient Power User — "Alex"
|
||||
|
||||
**Profile**: Expert with similar products. Expects efficiency, hates hand-holding. Will find shortcuts or leave.
|
||||
|
||||
**Behaviors**:
|
||||
- Skips all onboarding and instructions
|
||||
- Looks for keyboard shortcuts immediately
|
||||
- Tries to bulk-select, batch-edit, and automate
|
||||
- Gets frustrated by required steps that feel unnecessary
|
||||
- Abandons if anything feels slow or patronizing
|
||||
|
||||
**Test Questions**:
|
||||
- Can Alex complete the core task in under 60 seconds?
|
||||
- Are there keyboard shortcuts for common actions?
|
||||
- Can onboarding be skipped entirely?
|
||||
- Do modals have keyboard dismiss (Esc)?
|
||||
- Is there a "power user" path (shortcuts, bulk actions)?
|
||||
|
||||
**Red Flags** (report these specifically):
|
||||
- Forced tutorials or unskippable onboarding
|
||||
- No keyboard navigation for primary actions
|
||||
- Slow animations that can't be skipped
|
||||
- One-item-at-a-time workflows where batch would be natural
|
||||
- Redundant confirmation steps for low-risk actions
|
||||
|
||||
---
|
||||
|
||||
## 2. Confused First-Timer — "Jordan"
|
||||
|
||||
**Profile**: Never used this type of product. Needs guidance at every step. Will abandon rather than figure it out.
|
||||
|
||||
**Behaviors**:
|
||||
- Reads all instructions carefully
|
||||
- Hesitates before clicking anything unfamiliar
|
||||
- Looks for help or support constantly
|
||||
- Misunderstands jargon and abbreviations
|
||||
- Takes the most literal interpretation of any label
|
||||
|
||||
**Test Questions**:
|
||||
- Is the first action obviously clear within 5 seconds?
|
||||
- Are all icons labeled with text?
|
||||
- Is there contextual help at decision points?
|
||||
- Does terminology assume prior knowledge?
|
||||
- Is there a clear "back" or "undo" at every step?
|
||||
|
||||
**Red Flags** (report these specifically):
|
||||
- Icon-only navigation with no labels
|
||||
- Technical jargon without explanation
|
||||
- No visible help option or guidance
|
||||
- Ambiguous next steps after completing an action
|
||||
- No confirmation that an action succeeded
|
||||
|
||||
---
|
||||
|
||||
## 3. Accessibility-Dependent User — "Sam"
|
||||
|
||||
**Profile**: Uses screen reader (VoiceOver/NVDA), keyboard-only navigation. May have low vision, motor impairment, or cognitive differences.
|
||||
|
||||
**Behaviors**:
|
||||
- Tabs through the interface linearly
|
||||
- Relies on ARIA labels and heading structure
|
||||
- Cannot see hover states or visual-only indicators
|
||||
- Needs adequate color contrast (4.5:1 minimum)
|
||||
- May use browser zoom up to 200%
|
||||
|
||||
**Test Questions**:
|
||||
- Can the entire primary flow be completed keyboard-only?
|
||||
- Are all interactive elements focusable with visible focus indicators?
|
||||
- Do images have meaningful alt text?
|
||||
- Is color contrast WCAG AA compliant (4.5:1 for text)?
|
||||
- Does the screen reader announce state changes (loading, success, errors)?
|
||||
|
||||
**Red Flags** (report these specifically):
|
||||
- Click-only interactions with no keyboard alternative
|
||||
- Missing or invisible focus indicators
|
||||
- Meaning conveyed by color alone (red = error, green = success)
|
||||
- Unlabeled form fields or buttons
|
||||
- Time-limited actions without extension option
|
||||
- Custom components that break screen reader flow
|
||||
|
||||
---
|
||||
|
||||
## 4. Deliberate Stress Tester — "Riley"
|
||||
|
||||
**Profile**: Methodical user who pushes interfaces beyond the happy path. Tests edge cases, tries unexpected inputs, and probes for gaps in the experience.
|
||||
|
||||
**Behaviors**:
|
||||
- Tests edge cases intentionally (empty states, long strings, special characters)
|
||||
- Submits forms with unexpected data (emoji, RTL text, very long values)
|
||||
- Tries to break workflows by navigating backwards, refreshing mid-flow, or opening in multiple tabs
|
||||
- Looks for inconsistencies between what the UI promises and what actually happens
|
||||
- Documents problems methodically
|
||||
|
||||
**Test Questions**:
|
||||
- What happens at the edges (0 items, 1000 items, very long text)?
|
||||
- Do error states recover gracefully or leave the UI in a broken state?
|
||||
- What happens on refresh mid-workflow? Is state preserved?
|
||||
- Are there features that appear to work but produce broken results?
|
||||
- How does the UI handle unexpected input (emoji, special chars, paste from Excel)?
|
||||
|
||||
**Red Flags** (report these specifically):
|
||||
- Features that appear to work but silently fail or produce wrong results
|
||||
- Error handling that exposes technical details or leaves UI in a broken state
|
||||
- Empty states that show nothing useful ("No results" with no guidance)
|
||||
- Workflows that lose user data on refresh or navigation
|
||||
- Inconsistent behavior between similar interactions in different parts of the UI
|
||||
|
||||
---
|
||||
|
||||
## 5. Distracted Mobile User — "Casey"
|
||||
|
||||
**Profile**: Using phone one-handed on the go. Frequently interrupted. Possibly on a slow connection.
|
||||
|
||||
**Behaviors**:
|
||||
- Uses thumb only — prefers bottom-of-screen actions
|
||||
- Gets interrupted mid-flow and returns later
|
||||
- Switches between apps frequently
|
||||
- Has limited attention span and low patience
|
||||
- Types as little as possible, prefers taps and selections
|
||||
|
||||
**Test Questions**:
|
||||
- Are primary actions in the thumb zone (bottom half of screen)?
|
||||
- Is state preserved if the user leaves and returns?
|
||||
- Does it work on slow connections (3G)?
|
||||
- Can forms leverage autocomplete and smart defaults?
|
||||
- Are touch targets at least 44×44pt?
|
||||
|
||||
**Red Flags** (report these specifically):
|
||||
- Important actions positioned at the top of the screen (unreachable by thumb)
|
||||
- No state persistence — progress lost on tab switch or interruption
|
||||
- Large text inputs required where selection would work
|
||||
- Heavy assets loading on every page (no lazy loading)
|
||||
- Tiny tap targets or targets too close together
|
||||
|
||||
---
|
||||
|
||||
## Selecting Personas
|
||||
|
||||
Choose personas based on the interface type:
|
||||
|
||||
| Interface Type | Primary Personas | Why |
|
||||
|---------------|-----------------|-----|
|
||||
| Landing page / marketing | Jordan, Riley, Casey | First impressions, trust, mobile |
|
||||
| Dashboard / admin | Alex, Sam | Power users, accessibility |
|
||||
| E-commerce / checkout | Casey, Riley, Jordan | Mobile, edge cases, clarity |
|
||||
| Onboarding flow | Jordan, Casey | Confusion, interruption |
|
||||
| Data-heavy / analytics | Alex, Sam | Efficiency, keyboard nav |
|
||||
| Form-heavy / wizard | Jordan, Sam, Casey | Clarity, accessibility, mobile |
|
||||
|
||||
---
|
||||
|
||||
## Project-Specific Personas
|
||||
|
||||
If `{{config_file}}` contains a `## Design Context` section (generated by `teach-impeccable`), derive 1–2 additional personas from the audience and brand information:
|
||||
|
||||
1. Read the target audience description
|
||||
2. Identify the primary user archetype not covered by the 5 predefined personas
|
||||
3. Create a persona following this template:
|
||||
|
||||
```
|
||||
### [Role] — "[Name]"
|
||||
|
||||
**Profile**: [2-3 key characteristics derived from Design Context]
|
||||
|
||||
**Behaviors**: [3-4 specific behaviors based on the described audience]
|
||||
|
||||
**Red Flags**: [3-4 things that would alienate this specific user type]
|
||||
```
|
||||
|
||||
Only generate project-specific personas when real Design Context data is available. Don't invent audience details — use the 5 predefined personas when no context exists.
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: delight
|
||||
description: Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or area to add delight to (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful. Use when the user asks to add polish, personality, animations, micro-interactions, delight, or make an interface feel fun or memorable."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Identify opportunities to add moments of joy, personality, and unexpected polish that transform functional interfaces into delightful experiences.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: what's appropriate for the domain (playful vs professional vs quirky vs elegant).
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: what's appropriate for the domain (playful vs professional vs quirky vs elegant).
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: distill
|
||||
description: Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to distill (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
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."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,11 +1,8 @@
|
||||
---
|
||||
name: extract
|
||||
description: Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature, component, or area to extract from (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library. Use when the user asks to create components, refactor repeated UI patterns, build a design system, or extract tokens."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: frontend-design
|
||||
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code that avoids generic AI aesthetics.
|
||||
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.
|
||||
---
|
||||
|
||||
@@ -22,7 +22,7 @@ Individual skills may require additional context — check the skill's preparati
|
||||
**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 the teach-impeccable skill NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.
|
||||
3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run {{command_prefix}}teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -84,6 +84,78 @@ For tooltips, dropdowns, and non-modal overlays, use native popovers:
|
||||
|
||||
**Benefits**: Light-dismiss (click outside closes), proper stacking, no z-index wars, accessible by default.
|
||||
|
||||
## Dropdown & Overlay Positioning
|
||||
|
||||
Dropdowns rendered with `position: absolute` inside a container that has `overflow: hidden` or `overflow: auto` will be clipped. This is the single most common dropdown bug in generated code.
|
||||
|
||||
### CSS Anchor Positioning
|
||||
|
||||
The modern solution uses the CSS Anchor Positioning API to tether an overlay to its trigger without JavaScript:
|
||||
|
||||
```css
|
||||
.trigger {
|
||||
anchor-name: --menu-trigger;
|
||||
}
|
||||
|
||||
.dropdown {
|
||||
position: fixed;
|
||||
position-anchor: --menu-trigger;
|
||||
position-area: block-end span-inline-end;
|
||||
margin-top: 4px;
|
||||
}
|
||||
|
||||
/* Flip above if no room below */
|
||||
@position-try --flip-above {
|
||||
position-area: block-start span-inline-end;
|
||||
margin-bottom: 4px;
|
||||
}
|
||||
```
|
||||
|
||||
Because the dropdown uses `position: fixed`, it escapes any `overflow` clipping on ancestor elements. The `@position-try` block handles viewport edges automatically. **Browser support**: Chrome 125+, Edge 125+. Not yet in Firefox or Safari - use a fallback for those browsers.
|
||||
|
||||
### Popover + Anchor Combo
|
||||
|
||||
Combining the Popover API with anchor positioning gives you stacking, light-dismiss, accessibility, and correct positioning in one pattern:
|
||||
|
||||
```html
|
||||
<button popovertarget="menu" class="trigger">Open</button>
|
||||
<div id="menu" popover class="dropdown">
|
||||
<button>Option 1</button>
|
||||
<button>Option 2</button>
|
||||
</div>
|
||||
```
|
||||
|
||||
The `popover` attribute places the element in the **top layer**, which sits above all other content regardless of z-index or overflow. No portal needed.
|
||||
|
||||
### Portal / Teleport Pattern
|
||||
|
||||
In component frameworks, render the dropdown at the document root and position it with JavaScript:
|
||||
|
||||
- **React**: `createPortal(dropdown, document.body)`
|
||||
- **Vue**: `<Teleport to="body">`
|
||||
- **Svelte**: Use a portal library or mount to `document.body`
|
||||
|
||||
Calculate position from the trigger's `getBoundingClientRect()`, then apply `position: fixed` with `top` and `left` values. Recalculate on scroll and resize.
|
||||
|
||||
### Fixed Positioning Fallback
|
||||
|
||||
For browsers without anchor positioning support, `position: fixed` with manual coordinates avoids overflow clipping:
|
||||
|
||||
```css
|
||||
.dropdown {
|
||||
position: fixed;
|
||||
/* top/left set via JS from trigger's getBoundingClientRect() */
|
||||
}
|
||||
```
|
||||
|
||||
Check viewport boundaries before rendering. If the dropdown would overflow the bottom edge, flip it above the trigger. If it would overflow the right edge, align it to the trigger's right side instead.
|
||||
|
||||
### Anti-Patterns
|
||||
|
||||
- **`position: absolute` inside `overflow: hidden`** - The dropdown will be clipped. Use `position: fixed` or the top layer instead.
|
||||
- **Arbitrary z-index values** like `z-index: 9999` - Use a semantic z-index scale: `dropdown (100) -> sticky (200) -> modal-backdrop (300) -> modal (400) -> toast (500) -> tooltip (600)`.
|
||||
- **Rendering dropdown markup inline** without an escape hatch from the parent's stacking context. Either use `popover` (top layer), a portal, or `position: fixed`.
|
||||
|
||||
## Destructive Actions: Undo > Confirm
|
||||
|
||||
**Undo is better than confirmation dialogs**—users click through confirmations mindlessly. Remove from UI immediately, show undo toast, actually delete after toast expires. Use confirmation only for truly irreversible actions (account deletion), high-cost actions, or batch operations.
|
||||
|
||||
@@ -1,11 +1,8 @@
|
||||
---
|
||||
name: harden
|
||||
description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or area to harden (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Strengthen interfaces against edge cases, errors, internationalization issues, and real-world usage scenarios that break idealized designs.
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: normalize
|
||||
description: Normalize design to match your design system and ensure consistency
|
||||
args:
|
||||
- name: feature
|
||||
description: The page, route, or feature to normalize (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Audits and realigns UI to match design system standards, spacing, tokens, and patterns. Use when the user mentions consistency, design drift, mismatched styles, tokens, or wants to bring a feature back in line with the system."
|
||||
argument-hint: "[feature (page, route, component...)]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,16 +1,13 @@
|
||||
---
|
||||
name: onboard
|
||||
description: Design or improve onboarding flows, empty states, and first-time user experiences. Helps users get started successfully and understand value quickly.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or area needing onboarding (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,11 +1,8 @@
|
||||
---
|
||||
name: optimize
|
||||
description: Improve interface performance across loading speed, rendering, animations, images, and bundle size. Makes experiences faster and smoother.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or area to optimize (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Diagnoses and fixes UI performance across loading speed, rendering, animations, images, and bundle size. Use when the user mentions slow, laggy, janky, performance, bundle size, load time, or wants a faster, smoother experience."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Identify and fix performance issues to create faster, smoother user experiences.
|
||||
|
||||
@@ -1,11 +1,8 @@
|
||||
---
|
||||
name: overdrive
|
||||
description: Push interfaces past conventional limits with technically ambitious implementations. Whether that's a shader, a 60fps virtual table, spring physics on a dialog, or scroll-driven reveals — make users ask "how did they do that?"
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or area to push into overdrive (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Pushes interfaces past conventional limits with technically ambitious implementations — shaders, spring physics, scroll-driven reveals, 60fps animations. Use when the user wants to wow, impress, go all-out, or make something that feels extraordinary."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Start your response with:
|
||||
@@ -19,7 +16,7 @@ Push an interface past conventional limits. This isn't just about visual effects
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
**EXTRA IMPORTANT FOR THIS SKILL**: Context determines what "extraordinary" means. A particle system on a creative portfolio is impressive. The same particle system on a settings page is embarrassing. But a settings page with instant optimistic saves and animated state transitions? That's extraordinary too. Understand the project's personality and goals before deciding what's appropriate.
|
||||
|
||||
|
||||
@@ -1,16 +1,13 @@
|
||||
---
|
||||
name: polish
|
||||
description: Final quality pass before shipping. Fixes alignment, spacing, consistency, and detail issues that separate good from great.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or area to polish (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Performs a final quality pass fixing alignment, spacing, consistency, and micro-detail issues before shipping. Use when the user mentions polish, finishing touches, pre-launch review, something looks off, or wants to go from good to great."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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. Additionally gather: quality bar (MVP vs flagship).
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first. Additionally gather: quality bar (MVP vs flagship).
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: quieter
|
||||
description: Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to make quieter (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
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."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
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.
|
||||
user-invokable: true
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Gather design context for this project, then persist it for all future sessions.
|
||||
|
||||
@@ -1,18 +1,15 @@
|
||||
---
|
||||
name: typeset
|
||||
description: Improve typography by fixing font choices, hierarchy, sizing, weight consistency, and readability. Makes text feel intentional and polished.
|
||||
args:
|
||||
- name: target
|
||||
description: The feature or component to improve typography for (optional)
|
||||
required: false
|
||||
user-invokable: true
|
||||
description: "Improves typography by fixing font choices, hierarchy, sizing, weight, and readability so text feels intentional. Use when the user mentions fonts, type, readability, text hierarchy, sizing looks off, or wants more polished, intentional typography."
|
||||
argument-hint: "[target]"
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
Assess and improve typography that feels generic, inconsistent, or poorly structured — turning default-looking text into intentional, well-crafted type.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
Use the frontend-design skill — 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.
|
||||
Invoke {{command_prefix}}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 {{command_prefix}}teach-impeccable first.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user