picasso-skill 2.4.0 → 2.6.0

package/commands/godmode.md

@@ -2,49 +2,39 @@ Run the Picasso /godmode command -- the ultimate design transformation pipeline.
 
 Use the Picasso agent (subagent_type: "picasso") to execute the full godmode pipeline:
 
-ANTI-HALLUCINATION RULE: Every phase that makes visual claims MUST gather evidence first. For live sites, take screenshots via `npx playwright screenshot` AND view them with the Read tool. For Figma files, use MCP tools to fetch structural data AND export images. Never claim light/dark mode, color, or layout from code alone.
+ANTI-HALLUCINATION RULE: Every phase that makes visual claims MUST gather evidence first. Take screenshots via `npx playwright screenshot` AND view them with the Read tool. Never claim light/dark mode, color, or layout from code alone.
 
-VISUAL EVIDENCE SOURCES:
-- **Live site:** Playwright screenshots (take AND view with Read tool)
-- **Figma file:** MCP data (structural facts) + `mcp__figma__get_image` (visual verification)
-- **Both available:** Use Figma as design intent, Playwright as implementation reality. Flag gaps.
+If a Figma URL is provided, run /figma first to extract design tokens, then proceed with those as ground truth.
 
 Phase 1: UNDERSTAND
 - Check for .picasso.md config. If not found, run the design interview (ask what we're building, who it's for, aesthetic direction, priorities 1-5 for animations/mobile/a11y/dark mode/performance, constraints).
 - Gather context: read all frontend files, find design system, detect component library.
-- If a Figma URL is available or Figma MCP is configured, fetch the design file structure and styles as ground truth.
 
 Phase 2: ASSESS
 - Take BEFORE screenshots (desktop + mobile) and VIEW them with the Read tool.
-- If Figma source exists, fetch design tokens via MCP and compare against implementation.
 - Run /score to establish the BEFORE score (0-100 with category breakdown).
-- Run /roast for the brutally honest assessment (must be based on screenshots/Figma data, not code guessing).
+- Run /roast for the brutally honest assessment (must be based on screenshots, not code guessing).
 - Run /audit for full technical audit with severity-ranked findings.
 - Run /a11y (axe-core + pa11y + Lighthouse accessibility).
 - Run /perf (Lighthouse Core Web Vitals).
 - Run /lint-design (find hardcoded colors, spacing violations, font inconsistencies).
-- If Figma MCP available: Run /figma --audit for Figma-specific design system health check.
 
 Phase 3: PLAN
 - Compile all findings into a prioritized fix list (Critical -> High -> Medium -> Low).
-- If Figma source exists, prioritize design-implementation gaps as High severity.
 - Present the plan: "Found X issues. Fixing all = score ~Y. Proceed?"
 - WAIT for user confirmation before proceeding.
 
 Phase 4: FIX
 - Execute fixes in priority order: typography, color, spacing, layout, motion, accessibility, interaction, performance, copy.
-- When Figma tokens are available, use them as the source of truth for fixes.
 - Re-verify after each category.
 
 Phase 5: VERIFY
 - Run /score again for the AFTER score.
 - Take AFTER screenshots and VIEW them with the Read tool.
-- If Figma source exists, re-compare to check implementation now matches design intent.
 - Generate before/after comparison.
 
 Phase 6: REPORT
 - Show final score comparison with per-category breakdown.
 - Show files modified and issues fixed.
-- If Figma comparison was done, show design fidelity score (% match).
 
 If the before score is already 85+, say so and suggest the 3-4 things that would take it to 95+.

package/commands/roast.md

@@ -4,30 +4,19 @@ Use the Picasso agent to review the current project's frontend with sharp, desig
 
 MANDATORY FIRST STEP -- Gather visual evidence before writing anything:
 
-**Option A: Live site (localhost or URL)**
 1. Take screenshots: `npx playwright screenshot http://localhost:PORT /tmp/picasso-roast-desktop.png --viewport-size=1440,900` (and mobile at 375,812)
 2. Use the Read tool to VIEW the screenshot files: `Read /tmp/picasso-roast-desktop.png` and `Read /tmp/picasso-roast-mobile.png`
 3. Base ALL visual observations on what you actually see in the screenshots, NOT on code/CSS classes
 
-**Option B: Figma file (URL provided or MCP available)**
-1. Extract file_key from the Figma URL
-2. Fetch the target frame via `mcp__figma__get_node` for structural data (spacing, colors, typography, auto-layout)
-3. Export the frame as an image via `mcp__figma__get_image` for visual review
-4. Fetch styles via `mcp__figma__get_styles` to check design system usage
-5. Base structural observations on MCP data (exact values) and visual observations on the exported image
+If a Figma URL is provided, run /figma first to extract design tokens, then proceed with those as ground truth.
 
-**Option C: Both exist (Figma + live site)**
-1. Do both A and B
-2. Include a "Design vs Implementation" delta section in the roast — flag where the dev diverged from the design
-
-4. If NEITHER screenshots NOR Figma MCP work, tell the user and DO NOT make visual claims. You can still audit code patterns but must prefix findings with "Based on code analysis only (no screenshot):"
+If NEITHER screenshots NOR Figma MCP work, tell the user and DO NOT make visual claims. You can still audit code patterns but must prefix findings with "Based on code analysis only (no screenshot):"
 
 ANTI-HALLUCINATION RULES:
 - NEVER say "this is light mode" or "dark mode" without viewing a screenshot or Figma frame data
 - NEVER describe colors, layouts, or visual appearance from code alone
 - NEVER claim "this looks like X" without a screenshot or Figma export to verify
-- Code classes (e.g. `dark:bg-gray-900`) tell you what COULD render; only screenshots/Figma show what DOES render
-- When using Figma MCP data, you CAN state exact values (e.g., "spacing is 17px" or "fill is #808080") because these are structural facts, not visual guesses
+- Code classes (e.g. `dark:bg-gray-900`) tell you what COULD render; only screenshots show what DOES render
 
 Rules:
 - Be specific about every criticism (file:line, element reference, or Figma node name)

package/commands/score.md

@@ -4,27 +4,16 @@ Use the Picasso agent to score the current project's frontend design on a 0-100
 
 MANDATORY FIRST STEP -- Gather visual evidence before scoring:
 
-**Option A: Live site (localhost or URL)**
 1. Take screenshots: `npx playwright screenshot http://localhost:PORT /tmp/picasso-score-desktop.png --viewport-size=1440,900` (and mobile at 375,812)
 2. Use the Read tool to VIEW the screenshot files before scoring visual categories
 3. If screenshots fail, tell the user and score only code-auditable categories (mark visual categories as "N/A - no screenshot")
 
-**Option B: Figma file (URL provided or MCP available)**
-1. Fetch the target frame via `mcp__figma__get_node` for structural data
-2. Fetch styles via `mcp__figma__get_styles` for design system analysis
-3. Export frame as image via `mcp__figma__get_image` for visual review
-4. Score based on both structural data (exact values) and exported image
-5. Add bonus category: Design System Health (0-10)
-
-**Option C: Both (Figma + live site)**
-1. Do both A and B
-2. Add category: Design Fidelity (0-10) -- how closely implementation matches Figma intent
+If a Figma URL is provided, run /figma first to extract design tokens, then proceed with those as ground truth.
 
 ANTI-HALLUCINATION RULES:
-- Visual categories (Typography appearance, Color in practice, Spacing rhythm, Anti-Slop visual check) MUST be scored from screenshots or Figma exports, not code alone
+- Visual categories (Typography appearance, Color in practice, Spacing rhythm, Anti-Slop visual check) MUST be scored from screenshots, not code alone
 - Code-auditable categories (a11y violations via axe, transition:all grep, prefers-reduced-motion grep) can be scored from code
-- When using Figma MCP, structural data (exact spacing, color, typography values) IS factual and can be stated directly
-- Never claim "this looks like X" without viewing a screenshot or Figma export
+- Never claim "this looks like X" without viewing a screenshot
 
 Categories:
 - Typography (0-15): font choice, type scale, max-width, line-height, letter-spacing
@@ -36,8 +25,4 @@ Categories:
 - Performance (0-10): Lighthouse perf score mapped 0-100 -> 0-10
 - Anti-Slop (0-10): deductions for each AI-slop fingerprint detected (-2 each)
 
-Bonus categories (when Figma MCP is available):
-- Design System Health (0-10): style usage %, component coverage, naming consistency, auto-layout adoption
-- Design Fidelity (0-10, only when both Figma + live): token match, spacing accuracy, structural parity
-
 Output format with visual bars and top fixes for maximum point improvement.

package/commands/steal.md

@@ -2,30 +2,7 @@ Run the Picasso /steal command -- extract design DNA from a URL or Figma file.
 
 Use the Picasso agent to extract the design language from the provided source: $ARGUMENTS
 
-## Input Detection
-
-- **Figma URL** (contains `figma.com/design/` or `figma.com/file/`): Use Figma MCP for precise extraction
-- **Live URL** (any other http/https): Use Playwright screenshots + source scraping
-- **Both provided**: Use both sources, Figma as ground truth and live site for verification
-
-## Steps: Figma URL (Preferred)
-
-1. Extract `file_key` and optional `node_id` from the Figma URL
-2. Fetch styles via `mcp__figma__get_styles` — extract all color styles, text styles, effect styles
-3. Fetch target frame via `mcp__figma__get_node` — extract auto-layout spacing, fills, strokes, radii
-4. Fetch components via `mcp__figma__get_components` — understand component structure
-5. Export frame as image via `mcp__figma__get_image` for visual reference
-6. Analyze the extracted data:
-   - **Colors:** All fill/stroke colors → convert to OKLCH. Identify primary, secondary, accent, neutral.
-   - **Typography:** Font families, size scale, weight distribution, line-height ratios.
-   - **Spacing:** Auto-layout itemSpacing and padding → detect base unit (4px? 8px?) and scale.
-   - **Shadows:** Effect styles → map to elevation scale.
-   - **Radii:** Border radius values → detect pattern (uniform? progressive?).
-   - **Layout:** Auto-layout direction, alignment, wrapping → grid/flex patterns.
-7. Generate a `.picasso.md` config matching the extracted aesthetic
-8. Optionally generate a `DESIGN.md` with the full token set
-
-## Steps: Live URL
+## Steps
 
 1. Screenshot the URL at desktop (1440x900) and mobile (375x812)
 2. Fetch the page source and extract: font-family declarations, color values (#hex, rgb, oklch), border-radius values, box-shadow values
@@ -33,11 +10,6 @@ Use the Picasso agent to extract the design language from the provided source: $
 4. Generate a `.picasso.md` config that matches the extracted aesthetic
 5. Optionally generate a `DESIGN.md` with the full token set
 
-## Steps: Both (Figma + Live URL)
-
-1. Run Figma extraction (ground truth for intended design)
-2. Run live URL extraction (what actually shipped)
-3. Generate tokens from Figma source
-4. Note any divergences between design and implementation in the output
+If a Figma URL is provided, run /figma first to extract design tokens, then proceed with those as ground truth.
 
-If no URL is provided, ask the user for one. Accept both Figma URLs and live URLs.
+If no URL is provided, ask the user for one.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "picasso-skill",
-  "version": "2.4.0",
+  "version": "2.6.0",
   "description": "The ultimate AI design skill for producing distinctive, production-grade frontend interfaces",
   "bin": {
     "picasso-skill": "./bin/install.mjs"

package/references/accessibility-wcag.md

@@ -86,6 +86,9 @@ Move focus to `<h1>` of new view (add `tabindex="-1"`) or main content landmark.
 <main id="main" tabindex="-1">...</main>
 ```
 
+### Focus Indicator Rule
+Never remove focus outlines without replacement. Use `:focus-visible` (not `:focus`) to show focus rings only for keyboard navigation, not mouse clicks.
+
 ### Focus Trapping
 Contain Tab/Shift+Tab within overlays. Use `inert` attribute on background content (modern browsers) or manage via JS. On last focusable element, Tab wraps to first.
 

package/references/code-typography.md

@@ -1,16 +1,5 @@
 # Code Typography Reference
 
-## Table of Contents
-1. Monospace Font Selection
-2. Code Block Design
-3. Syntax Highlighting Accessibility
-4. Copy-to-Clipboard
-5. Responsive Code Blocks
-6. Inline Code Styling
-7. Diff Views
-8. Terminal Output
-9. Common Mistakes
-
 ---
 
 ## 1. Monospace Font Selection
@@ -19,204 +8,85 @@
 |---|---|---|---|
 | JetBrains Mono | Yes | Clean, geometric | General purpose, IDEs |
 | Fira Code | Yes | Slightly rounded | Tutorials, docs |
-| Source Code Pro | No | Adobe, professional | Enterprise, clean look |
+| Source Code Pro | No | Adobe, professional | Enterprise |
 | IBM Plex Mono | No | Corporate, legible | Documentation |
 | Geist Mono | No | Vercel, modern | Next.js projects |
 | Cascadia Code | Yes | Microsoft, playful | Terminals |
 
-```css
-code, pre, .mono {
-  font-family: 'JetBrains Mono', 'Fira Code', 'Cascadia Code', 'Consolas', monospace;
-  font-feature-settings: 'liga' 1, 'calt' 1; /* enable ligatures */
-  font-variant-ligatures: common-ligatures;
-}
-```
-
-Ligatures: `=>` becomes ⇒, `!==` becomes ≢, `>=` becomes ≥. Enable for display, disable for editing if users copy code.
+Always specify a modern monospace font first, then fallback to `monospace`. Enable ligatures with `font-feature-settings: 'liga' 1, 'calt' 1` for display; disable for editing if users copy code.
 
 ---
 
 ## 2. Code Block Design
 
-```css
-pre {
-  background: var(--surface-1);
-  border: 1px solid var(--border);
-  border-radius: 8px;
-  padding: 1rem 1.25rem;
-  font-size: 0.875rem;    /* 14px — slightly smaller than body */
-  line-height: 1.65;       /* Looser than body text for readability */
-  overflow-x: auto;
-  tab-size: 2;
-  -moz-tab-size: 2;
-}
-
-/* Dark mode code blocks on light sites */
-[data-theme="light"] pre {
-  background: oklch(0.14 0.02 230);
-  color: oklch(0.90 0.01 230);
-}
-```
-
-Line numbers (optional):
-```css
-pre.line-numbers {
-  counter-reset: line;
-  padding-left: 3.5rem;
-  position: relative;
-}
-pre.line-numbers .line::before {
-  counter-increment: line;
-  content: counter(line);
-  position: absolute;
-  left: 1rem;
-  color: var(--text-muted);
-  font-size: 0.75rem;
-  user-select: none; /* don't copy line numbers */
-}
-```
+- Background: `var(--surface-1)` with 1px border, 8px radius
+- Font size: 0.875rem (14px), line-height: 1.65 (looser than body for readability)
+- `overflow-x: auto; tab-size: 2`
+- Dark code blocks on light sites: `oklch(0.14 0.02 230)` background
+- Line numbers: use CSS counters with `user-select: none` so they don't get copied
 
 ---
 
 ## 3. Syntax Highlighting Accessibility
 
-Every token color must have **minimum 3:1 contrast** against the code block background. Don't rely on color alone — use font-weight or font-style for emphasis.
+Every token color must have **minimum 3:1 contrast** against the code block background. Don't rely on color alone; use font-weight or font-style for emphasis.
 
-| Token Type | Suggested OKLCH (dark bg) | Purpose |
+| Token Type | Suggested OKLCH (dark bg) | Style |
 |---|---|---|
-| Keywords | `oklch(0.75 0.15 300)` | purple-ish, bold |
-| Strings | `oklch(0.72 0.14 150)` | green |
-| Numbers | `oklch(0.75 0.12 60)` | amber |
-| Comments | `oklch(0.50 0.01 230)` | muted, italic |
-| Functions | `oklch(0.78 0.10 230)` | blue |
-| Variables | `oklch(0.85 0.01 230)` | near-white |
-
-```css
-.token-keyword { color: oklch(0.75 0.15 300); font-weight: 600; }
-.token-string { color: oklch(0.72 0.14 150); }
-.token-comment { color: oklch(0.50 0.01 230); font-style: italic; }
-```
+| Keywords | `oklch(0.75 0.15 300)` | bold |
+| Strings | `oklch(0.72 0.14 150)` | normal |
+| Numbers | `oklch(0.75 0.12 60)` | normal |
+| Comments | `oklch(0.50 0.01 230)` | italic |
+| Functions | `oklch(0.78 0.10 230)` | normal |
+| Variables | `oklch(0.85 0.01 230)` | normal |
 
 ---
 
 ## 4. Copy-to-Clipboard
 
-Position: top-right corner of the code block. Show on hover. Provide visual feedback.
-
-```jsx
-function CopyButton({ code }) {
-  const [copied, setCopied] = useState(false);
-
-  return (
-    <button
-      onClick={() => {
-        navigator.clipboard.writeText(code);
-        setCopied(true);
-        setTimeout(() => setCopied(false), 2000);
-      }}
-      className="absolute top-2 right-2 p-1.5 rounded-md bg-white/5 hover:bg-white/10 text-xs text-muted"
-      aria-label="Copy code"
-    >
-      {copied ? 'Copied' : 'Copy'}
-    </button>
-  );
-}
-```
+Position top-right, show on hover, visual feedback ("Copied" for 2s). Use `navigator.clipboard.writeText()`. Add `aria-label="Copy code"`.
 
 ---
 
 ## 5. Responsive Code Blocks
 
-Code blocks should **scroll horizontally** on mobile, never wrap. Terminal output CAN wrap.
-
-```css
-pre {
-  overflow-x: auto;
-  white-space: pre;         /* code: no wrap */
-  -webkit-overflow-scrolling: touch; /* smooth scroll on iOS */
-}
-
-pre.terminal {
-  white-space: pre-wrap;    /* terminal: wrap is OK */
-  word-break: break-all;
-}
-
-/* Hide scrollbar but keep functionality */
-pre::-webkit-scrollbar { height: 4px; }
-pre::-webkit-scrollbar-thumb { background: var(--border); border-radius: 4px; }
-```
-
-On very small screens (< 375px), consider reducing code font-size to 12px.
+- Code: `white-space: pre; overflow-x: auto` (never wrap)
+- Terminal output: `white-space: pre-wrap` (wrapping OK)
+- Thin scrollbar: 4px height, subtle thumb color
+- Below 375px, consider reducing to 12px font size
 
 ---
 
 ## 6. Inline Code Styling
 
-Inline code needs subtle visual distinction from body text:
-
-```css
-code:not(pre code) {
-  background: var(--surface-2);
-  padding: 0.15em 0.4em;
-  border-radius: 4px;
-  font-size: 0.9em;        /* slightly smaller than surrounding text */
-  font-weight: 500;
-  border: 1px solid var(--border);
-}
-```
-
-Never use inline code for emphasis. It's for code references (`useState`, `border-radius`, `GET /api/users`), not for highlighting words.
+Subtle distinction from body text: light background, 0.15em/0.4em padding, 4px radius, 0.9em font-size, 1px border. Never use inline code for emphasis; it's for code references (`useState`, `GET /api/users`).
 
 ---
 
 ## 7. Diff Views
 
-Use color + icon, not color alone (colorblind users):
-
-```css
-.diff-add {
-  background: oklch(0.62 0.19 150 / 0.1);
-  border-left: 3px solid oklch(0.62 0.19 150);
-}
-.diff-add::before { content: '+'; color: oklch(0.62 0.19 150); }
-
-.diff-remove {
-  background: oklch(0.55 0.22 25 / 0.1);
-  border-left: 3px solid oklch(0.55 0.22 25);
-  text-decoration: line-through;
-  opacity: 0.7;
-}
-.diff-remove::before { content: '-'; color: oklch(0.55 0.22 25); }
-```
+Use color + icon (not color alone, for colorblind users):
+- Added: green-tinted background + left border + `+` prefix
+- Removed: red-tinted background + left border + `-` prefix + `line-through` + reduced opacity
 
 ---
 
 ## 8. Terminal Output
 
-Terminal/console styling should feel distinct from code:
-
-```css
-.terminal {
-  background: oklch(0.08 0.01 230);
-  color: oklch(0.80 0.01 150); /* slight green tint for terminal feel */
-  font-family: 'JetBrains Mono', monospace;
-  padding: 1rem;
-  border-radius: 8px;
-}
-.terminal .prompt { color: oklch(0.65 0.10 230); } /* blue prompt */
-.terminal .output { color: oklch(0.75 0.01 230); } /* neutral output */
-.terminal .error { color: oklch(0.65 0.22 25); }   /* red errors */
-```
+Terminal styling should feel distinct from code blocks:
+- Darker background: `oklch(0.08 0.01 230)`
+- Slight green tint for text: `oklch(0.80 0.01 150)`
+- Blue prompt, neutral output, red errors
 
 ---
 
 ## 9. Common Mistakes
 
-- **Code font too large.** 14px for blocks, 0.9em for inline. Larger fights with body text.
-- **No horizontal scroll on code blocks.** Wrapping code breaks readability. Always `overflow-x: auto`.
-- **Syntax colors with < 3:1 contrast.** Comments especially — they tend to be too faint.
-- **Color-only diff indication.** Always add + / - markers or icons alongside color.
-- **Copying includes line numbers.** Use `user-select: none` on line number elements.
-- **Same styling for code blocks and terminal.** They serve different purposes. Terminal gets darker bg, green tint.
-- **`font-family: monospace` without named fonts.** Browsers default to Courier New which looks dated. Always specify a modern monospace font first.
-- **No copy button.** Users shouldn't have to triple-click and drag to copy code.
+- Code font too large (14px for blocks, 0.9em for inline)
+- No horizontal scroll on code blocks
+- Syntax colors with < 3:1 contrast (especially comments)
+- Color-only diff indication (add +/- markers)
+- Copying includes line numbers (use `user-select: none`)
+- Same styling for code blocks and terminal (different purposes)
+- `font-family: monospace` without named fonts (defaults to Courier New)
+- No copy button