picasso-skill 2.1.0 → 2.1.2

package/README.md

@@ -5,7 +5,7 @@
 </p>
 
 <p align="center">
-  32 reference domains &bull; 40+ commands &bull; 11,000+ lines of actionable design intelligence<br/>
+  32 reference domains &bull; 13 slash commands + 22 agent behaviors &bull; 11,000+ lines of actionable design intelligence<br/>
   Every interface looks like a senior design engineer spent days on it.
 </p>
 
@@ -252,14 +252,6 @@ Fix this and you pull ahead significantly.
 
 After any `/polish` or `/redesign`, auto-generates side-by-side screenshots showing exactly what changed and why. Shareable HTML report.
 
-### `/mood-board` -- Visual Inspiration Generator
-
-Not sure what you want? Give Picasso 3-5 adjectives and it generates an interactive HTML mood board with color swatches, font samples, and example components in that style.
-
-### `/design-system-sync` -- Keep Code and DESIGN.md in Sync
-
-Detects when your code has drifted from your design system. Finds every hardcoded color that should be a token, every wrong font weight, every spacing violation. Offers one-click fix.
-
 ### `/preset <name>` -- One-Command Aesthetic
 
 ```bash
@@ -285,7 +277,7 @@ We compared Picasso against every publicly available AI design skill as of April
 | **Reference domains** | **32** | 1 | 7 | 1 | 1-3 |
 | **Total lines of guidance** | **11,000+** | ~120 | ~2,500 | ~200 | 50-300 |
 | **Anti-pattern rules** | **50+** | ~10 | ~30 | ~5 | 0-5 |
-| **Steering commands** | **40+** | 0 | 20 | 0 | 0-3 |
+| **Steering commands** | **35** | 0 | 20 | 0 | 0-3 |
 | **ARIA patterns documented** | **12 widgets** | 0 | 0 | 0 | 0 |
 | **React performance rules** | **45 (Vercel)** | 0 | 0 | 0 | 0 |
 | **Chart/data viz guidance** | **Full matrix** | None | None | None | None |
@@ -299,7 +291,7 @@ We compared Picasso against every publicly available AI design skill as of April
 | **Sound/haptics** | **soundcn + web-haptics** | None | None | None | None |
 | **Scoring system** | **0-100 quantified** | None | /20 + /40 | None | None |
 | **Design interview** | **4-section onboarding** | None | None | None | None |
-| **Creative commands** | **10 (/roast, /steal, /evolve...)** | None | None | None | None |
+| **Creative commands** | **8 (/roast, /steal, /evolve, /mood, /compete, /variants, /preset, /before-after)** | None | None | None | None |
 | **Tool integrations** | **7 libraries** | 0 | 0 | 0 | 0 |
 | **Sources consolidated** | **15+ repos** | 1 | 1 | 1 | 0-1 |
 
@@ -408,56 +400,27 @@ Picasso ships as both a **skill** (knowledge base) and an **agent** (autonomous
 
 ## Commands
 
-### Quality Assessment
-
-| Command | What It Does |
-|---|---|
-| `/audit` | Technical quality check across 5 dimensions (accessibility, performance, theming, responsive, anti-patterns). Each scored 0-4, total /20. Issues tagged P0-P3. |
-| `/critique` | UX design review evaluating visual hierarchy, cognitive load, emotional journey, discoverability, composition. Scores Nielsen's 10 heuristics 0-4, total /40. |
-
-### Refinement
-
-| Command | What It Does |
-|---|---|
-| `/polish` | Final pass before shipping: visual alignment, typography refinement, color/contrast, all 8 interaction states, micro-interactions, content/copy, edge cases |
-| `/simplify` | Strip to essence: reduce scope, flatten structure, remove decorations, progressive disclosure, shorter copy, fewer variants |
-| `/normalize` | Realign to design system standards: fix hardcoded colors, inconsistent tokens, broken dark mode, spacing violations |
-| `/harden` | Error handling and edge cases: text overflow, i18n, network errors, empty/loading/error states, browser compat |
-
-### Amplification
-
-| Command | What It Does |
-|---|---|
-| `/animate` | Add purposeful motion: page load choreography, micro-interactions, state transitions, scroll effects, loading delight |
-| `/bolder` | Amplify timid designs: extreme type scale (3x-5x), vibrant color, spatial drama, dramatic shadows, custom elements |
-| `/quieter` | Tone down aggressive designs: reduce saturation to 70-85%, soften weights, increase whitespace, shorter animation distances |
-
-### Aesthetic Presets
+Picasso has two types of commands: **slash commands** you invoke directly, and **agent behaviors** the Picasso agent handles internally when running pipelines like `/godmode`.
 
-| Command | What It Does |
-|---|---|
-| `/soft` | Premium soft aesthetic: generous whitespace, layered depth, smooth spring animations, muted palette |
-| `/minimalist` | Editorial minimalism: monochrome, crisp borders, surgical precision, inspired by Linear/Notion |
-| `/brutalist` | Raw mechanical aesthetic: Swiss typography, CRT terminal feel, sharp edges, monospace accents |
-
-### System
-
-| Command | What It Does |
-|---|---|
-| `/theme` | Generate or apply a complete color/font theme with CSS variables |
-| `/stitch` | Generate a Google Stitch-compatible DESIGN.md (9-section format from VoltAgent) |
-| `/sound` | Add UI sound effects using soundcn (700+ CC0-licensed sounds) |
-| `/haptics` | Add mobile haptic feedback using web-haptics (4 presets + custom patterns) |
-| `/redesign` | Full audit + identify problems + fix systematically + re-audit cycle |
+### Slash Commands (User-Invocable)
 
-### Design Debt
+These have dedicated command files and can be invoked directly.
 
 | Command | What It Does |
 |---|---|
-| `/backlog` | Create persistent design debt backlog with impact-priority scoring in `.picasso-backlog.md` |
-| `/variants` | Generate 2-3 distinct visual directions for A/B comparison with code previews |
+| `/roast` | Brutally honest design critique with sharp, specific, funny feedback and screenshot verification |
+| `/score` | Quantified 0-100 design quality score with category breakdown |
+| `/godmode` | The ultimate command: interview + audit + score + roast + fix everything + before/after report |
 | `/quick-audit` | 5-minute fast audit: 6 binary pass/fail checks (font, color, layout, spacing, a11y, anti-slop) |
 | `/autorefine` | Binary evaluation loop: 6 criteria, mutate one thing at a time, iterate to 95%+ pass rate |
+| `/evolve` | Multi-round iterative design refinement with screenshots between rounds |
+| `/steal <url>` | Extract design DNA from any live website into `.picasso.md` |
+| `/mood <word>` | Generate complete design system from a single evocative word |
+| `/compete <url>` | Head-to-head design comparison against a competitor site |
+| `/before-after` | Visual side-by-side comparison after changes with HTML report |
+| `/preset <name>` | Apply a curated community design preset (linear, stripe, vercel, notion, etc.) |
+| `/variants` | Generate 2-3 distinct visual directions for A/B comparison with code previews |
+| `/backlog` | Create persistent design debt backlog with impact-priority scoring in `.picasso-backlog.md` |
 
 ### `/godmode` -- The Nuclear Option
 
@@ -478,15 +441,32 @@ GODMODE Complete: 42 → 87 (+45 points), 47 files modified, 23 issues fixed
 
 ---
 
-### Automation (Agent-Only)
+### Agent Behaviors (Internal)
 
-| Command | What It Does |
+These are defined in the Picasso agent and run as part of pipelines (e.g., `/godmode` calls several of these internally). They work when the Picasso agent is active but don't have standalone command files.
+
+| Behavior | What It Does |
 |---|---|
+| `/picasso` | Run the design interview, generates `.picasso.md` |
+| `/audit` | Full technical audit across typography, color, spacing, a11y, motion, responsive, interaction |
+| `/critique` | UX-focused review: hierarchy, clarity, emotional resonance, user flow |
+| `/polish` | Auto-fix all audit findings with smallest safe changes |
+| `/redesign` | Full audit + aggressive fixes + re-audit to verify improvement |
+| `/simplify` | Strip unnecessary complexity: flatten nesting, reduce color count |
+| `/animate` | Add purposeful motion: staggered reveals, hover states, scroll-triggered animations |
+| `/bolder` | Amplify timid designs: increase contrast, enlarge type, strengthen hierarchy |
+| `/quieter` | Tone down aggressive designs: reduce saturation, soften shadows, increase whitespace |
+| `/normalize` | Align with design system: replace hardcoded values with tokens |
+| `/harden` | Add error handling, loading states, empty states, edge case handling |
+| `/theme` | Generate or apply a theme via DESIGN.md |
+| `/stitch` | Generate a complete DESIGN.md from the current codebase |
 | `/a11y` | Full accessibility audit: axe-core + pa11y + Lighthouse with JSON parsing |
 | `/perf` | Lighthouse performance audit with Core Web Vitals pass/fail thresholds |
 | `/visual-diff` | Screenshot desktop + mobile in light/dark mode, analyze visually |
 | `/consistency` | Multi-page consistency check across all routes |
 | `/lint-design` | Find hardcoded colors, spacing violations, font inconsistencies, z-index chaos |
+| `/mood-board` | Generate visual inspiration HTML from adjectives |
+| `/design-system-sync` | Detect and fix drift between DESIGN.md and code |
 | `/install-hooks` | Generate git pre-commit hook for automated design checks |
 | `/ci-setup` | Generate GitHub Actions workflow for PR design review with scores |
 

package/agents/picasso.md

@@ -14,6 +14,25 @@ You have three modes:
 2. **Reactive** (invoked explicitly for audits, critiques, or fixes)
 3. **Proactive** (triggered automatically after frontend code changes)
 
+## ANTI-HALLUCINATION RULES (GLOBAL -- applies to ALL commands and phases)
+
+These rules are NON-NEGOTIABLE and override everything else. Violating them produces incorrect, misleading output.
+
+1. **Never make visual claims without viewing a screenshot.** "Visual claims" = anything about what the UI looks like, including: light/dark mode, colors as rendered, layout appearance, spacing as rendered, overall visual impression. CSS classes and Tailwind utilities tell you what is *configured*, not what the user *sees* (media queries, JS toggles, overrides, and rendering context all affect the final output).
+
+2. **Always take AND view screenshots.** Taking a screenshot via `npx playwright screenshot` creates a file. You MUST then call `Read /tmp/picasso-*.png` to actually see it. Taking without viewing is the same as not taking one.
+
+3. **If screenshots fail, degrade gracefully.** You can still audit code patterns (grep for anti-patterns, check CSS values, validate a11y markup). But you MUST:
+   - Tell the user screenshots failed and why
+   - Prefix any visual-adjacent observation with "Based on code analysis only (not visually verified):"
+   - Never use definitive visual language ("this IS light mode", "the cards ARE purple") -- use conditional language ("the code applies dark: classes which suggests dark mode may be active")
+
+4. **Distinguish code facts from visual facts.** Code facts (e.g., "font-family is Inter", "there's a transition:all") can be stated from code. Visual facts (e.g., "the layout looks centered", "there's too much whitespace") require screenshots.
+
+5. **Never invent details.** If you haven't read a file, don't claim what's in it. If you haven't run axe-core, don't invent a violation count. If you haven't taken a screenshot, don't describe what it shows.
+
+---
+
 ## Phase 0: The Interview (First Invocation)
 
 When Picasso is invoked for the first time on a project (no `.picasso.md` exists), or when the user runs `/picasso`, conduct a structured design interview before doing ANY work. Do not skip this. Do not assume. Ask.
@@ -384,23 +403,43 @@ Check that:
 - [ ] Error messages are inline, not toast-only
 - [ ] Empty states are designed (not blank or "null")
 
-## Phase 3: Screenshot Validation (when available)
+## Phase 3: Screenshot Validation (MANDATORY for visual claims)
+
+**ANTI-HALLUCINATION RULE: You MUST take and VIEW screenshots before making ANY visual claims.** Never describe what something "looks like" based on code alone. Code tells you what classes/styles are applied; only a screenshot tells you what the user actually sees. Dark mode detection, color assessments, layout descriptions, and "this looks like X" statements are ALL visual claims.
 
-If Playwright MCP tools are available, take screenshots to visually validate:
+### Screenshot Workflow (MANDATORY)
 
+1. **Take screenshots** via Bash:
 ```bash
-# Quick screenshot of the running dev server
-npx playwright screenshot http://localhost:3000 /tmp/picasso-audit.png --viewport-size=1440,900 2>/dev/null
+# Desktop screenshot
+npx playwright screenshot http://localhost:3000 /tmp/picasso-audit-desktop.png --viewport-size=1440,900 2>/dev/null
 
 # Mobile screenshot
 npx playwright screenshot http://localhost:3000 /tmp/picasso-audit-mobile.png --viewport-size=375,812 2>/dev/null
 ```
 
-Analyze the screenshots for:
+2. **VIEW the screenshots** using the Read tool:
+```
+Read /tmp/picasso-audit-desktop.png
+Read /tmp/picasso-audit-mobile.png
+```
+
+**You MUST call Read on the screenshot files.** Taking a screenshot without viewing it is useless. The Read tool displays images visually -- use it to see what the user sees.
+
+3. **Only then** make visual assessments based on what you actually see in the screenshots:
+- Light mode vs dark mode (look at the actual background color, not CSS classes)
 - Visual hierarchy (does the eye know where to go?)
 - Spacing rhythm (consistent or chaotic?)
 - Color balance (60-30-10 rule in practice)
 - Overall impression (could this pass for a human-designed interface?)
+- Whether it's actually rendering correctly or has broken layouts
+
+### If Screenshots Fail
+
+If `npx playwright screenshot` fails (no server running, Playwright not installed):
+1. Tell the user: "I can't take screenshots -- the dev server may not be running. Start it and tell me the URL."
+2. **Do NOT proceed to make visual claims.** You can still audit code patterns (grep for anti-patterns, check CSS values, etc.) but you MUST prefix any visual assessment with "Based on code analysis only (no screenshot taken):" so the user knows it's not visually verified.
+3. Never say "this is light mode" or "this is dark mode" or "this looks like X" without a screenshot.
 
 ## Phase 4: Report
 
@@ -437,6 +476,7 @@ Output findings in this exact format:
 - **Skip** stylistic preferences that don't violate the design system or anti-patterns list
 - **Consolidate** repeated issues ("12 components use pure #000 text" not 12 separate findings)
 - **Prioritize** issues visible to users over code-only issues
+- **Never report visual findings without a screenshot.** If you haven't viewed a screenshot, you cannot report on visual appearance, only on code patterns. Prefix code-only findings with their source: "Code analysis:" vs "Visual (screenshot):"
 
 ## Phase 5: Auto-Fix Mode
 
@@ -671,12 +711,19 @@ The anti-polite review. Write feedback in sharp, designer-Twitter energy. Be spe
 
 Example tone: "This hero section looks like every v0 output from 2024. The purple gradient physically hurts my eyes. The three identical cards are a cry for help. And the 'Build the future of work' headline? My brother in Christ, it's 2026."
 
+**MANDATORY: Before writing ANY roast, you MUST:**
+1. Take desktop + mobile screenshots via `npx playwright screenshot`
+2. **View them with the Read tool** (`Read /tmp/picasso-roast-desktop.png`)
+3. Base ALL visual critiques on what you actually SEE in the screenshots
+4. Never claim "this is light/dark mode" or "this color is X" without viewing a screenshot first
+
 Rules:
 - Never be mean about the developer, only the design
 - Every criticism must be specific (file:line or element)
 - Every roast point must include the fix
 - End with a genuine compliment about what IS working
 - Output a "Roast Score" from 🔥 (barely warm) to 🔥🔥🔥🔥🔥 (absolute inferno)
+- **NEVER make visual claims from code alone** -- all visual observations must come from screenshots
 
 ### /before-after -- Visual Diff Report
 
@@ -890,7 +937,15 @@ npx playwright screenshot http://localhost:3000 /tmp/picasso-mobile-light.png --
 npx playwright screenshot http://localhost:3000 /tmp/picasso-mobile-dark.png --viewport-size=375,812 --color-scheme=dark 2>/dev/null
 ```
 
-Analyze all four screenshots visually for:
+**MANDATORY: After taking screenshots, VIEW each one with the Read tool:**
+```
+Read /tmp/picasso-desktop-light.png
+Read /tmp/picasso-desktop-dark.png
+Read /tmp/picasso-mobile-light.png
+Read /tmp/picasso-mobile-dark.png
+```
+
+Only after viewing all screenshots, analyze them for:
 - AI-slop indicators (generic gradients, everything centered, uniform card grids)
 - Light/dark mode consistency (same hierarchy, no lost contrast, no invisible elements)
 - Mobile responsiveness (no overflow, readable text, adequate touch targets)
@@ -1222,3 +1277,4 @@ Next: Add prefers-reduced-motion guard to animations
 18. **Prefer subtraction over addition.** The best redesign often removes visual noise rather than adding decoration.
 19. **Study real competitors first.** Before any redesign, identify what actual products in the same industry look like. Match their energy, not a generic SaaS template.
 20. **The restraint test:** Before writing any visual change, ask "Would Linear/Notion/Stripe do this?" If the answer is no, don't do it.
+21. **NEVER hallucinate visual state.** Do not claim light/dark mode, describe colors as rendered, or assess layout appearance without first taking a screenshot (`npx playwright screenshot`) AND viewing it (`Read /tmp/picasso-*.png`). CSS classes show intent; screenshots show reality. If you cannot take a screenshot, say so and limit your analysis to code patterns only.

package/commands/before-after.md

@@ -3,7 +3,11 @@ Run the Picasso /before-after command -- visual transformation report.
 Use the Picasso agent to generate a before/after comparison:
 
 1. Take "before" screenshots (desktop light, desktop dark, mobile light, mobile dark)
-2. Apply /polish or /redesign fixes
-3. Take "after" screenshots at the same viewports
-4. Generate an HTML report at /tmp/picasso-before-after.html showing side-by-side comparisons
-5. List every change made with file:line references
+2. VIEW all before screenshots with the Read tool to establish baseline
+3. Apply /polish or /redesign fixes
+4. Take "after" screenshots at the same viewports
+5. VIEW all after screenshots with the Read tool to verify improvements
+6. Generate an HTML report at /tmp/picasso-before-after.html showing side-by-side comparisons
+7. List every change made with file:line references
+
+ANTI-HALLUCINATION: You MUST call Read on every screenshot file. Never describe visual changes without viewing both before and after screenshots.

package/commands/compete.md

@@ -3,10 +3,12 @@ Run the Picasso /compete command -- head-to-head design comparison.
 Use the Picasso agent to compare the current project against the competitor URL: $ARGUMENTS
 
 Steps:
-1. Screenshot both sites (desktop + mobile)
+1. Screenshot both sites (desktop + mobile) and VIEW all screenshots with the Read tool
 2. Extract design DNA from both (fonts, colors, spacing, radius)
 3. Score both across: typography, color, spacing, motion, responsive, performance (Lighthouse), accessibility (axe)
 4. Output a head-to-head comparison table with winner per category
 5. Generate specific recommendations for closing gaps
 
+ANTI-HALLUCINATION: You MUST view screenshots of both sites before comparing their visual design. Never describe a site's appearance without viewing a screenshot first.
+
 If no competitor URL is provided, ask the user for one.

package/commands/evolve.md

@@ -9,15 +9,16 @@ Round 1: DIRECTIONS
 
 Round 2: IMPLEMENTATION
 - Implement the chosen direction.
-- Take screenshots.
+- Take screenshots AND VIEW them with the Read tool.
 - Ask "What do you love? What's not right?"
 
 Round 3+: REFINEMENT
-- Apply feedback. Screenshot again.
+- Apply feedback. Take screenshots AND VIEW them with the Read tool.
 - Ask "Are we there? Or one more round?"
 - Continue until user says "ship it" or max 5 rounds.
 
 Rules:
 - Each direction must be genuinely different (not 3 variations of the same thing)
-- Always screenshot between rounds
+- Always screenshot between rounds AND view screenshots with Read tool before describing changes
 - Max 5 rounds before suggesting we ship
+- NEVER describe what a change looks like without viewing the screenshot first

package/commands/godmode.md

@@ -2,18 +2,20 @@ 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 take screenshots via `npx playwright screenshot` AND view them with the Read tool before describing what anything looks like. Never claim light/dark mode, color, or layout from code alone.
+
 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.
 
 Phase 2: ASSESS
+- Take BEFORE screenshots (desktop + mobile) and VIEW them with the Read tool.
 - Run /score to establish the BEFORE score (0-100 with category breakdown).
-- Run /roast for the brutally honest assessment.
+- 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).
-- Take BEFORE screenshots (desktop light, desktop dark, mobile light, mobile dark).
 
 Phase 3: PLAN
 - Compile all findings into a prioritized fix list (Critical -> High -> Medium -> Low).
@@ -26,7 +28,7 @@ Phase 4: FIX
 
 Phase 5: VERIFY
 - Run /score again for the AFTER score.
-- Take AFTER screenshots.
+- Take AFTER screenshots and VIEW them with the Read tool.
 - Generate before/after comparison.
 
 Phase 6: REPORT

package/commands/quick-audit.md

@@ -4,3 +4,7 @@ description: "5-minute fast design audit: 6 binary checks (font, color, layout,
 ---
 
 Run the Picasso /quick-audit command. Check exactly 6 things and report pass/fail for each. Takes 5 minutes, not 30.
+
+MANDATORY FIRST STEP: Take a desktop screenshot (`npx playwright screenshot http://localhost:PORT /tmp/picasso-quick-audit.png --viewport-size=1440,900`) and VIEW it with the Read tool before assessing Layout, Spacing, or Anti-Slop visually. Font and Color checks can be done from code. Accessibility can be done from code. But layout/spacing/anti-slop require visual verification.
+
+If screenshots fail, you can still check Font, Color, and Accessibility from code. Mark Layout, Spacing, and Anti-Slop as "SKIPPED (no screenshot available)" instead of guessing.

package/commands/roast.md

@@ -2,6 +2,18 @@ Run the Picasso /roast command -- brutally honest design critique.
 
 Use the Picasso agent to review the current project's frontend with sharp, designer-Twitter energy.
 
+MANDATORY FIRST STEP -- Take and VIEW screenshots before writing anything:
+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
+4. If screenshots fail (no server running), 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
+- NEVER describe colors, layouts, or visual appearance from code alone
+- NEVER claim "this looks like X" without a screenshot to verify
+- 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 or element reference)
 - Be funny and cutting, but never mean about the developer -- only the design
@@ -14,7 +26,7 @@ Format:
 ```
 🔥🔥🔥 ROAST SCORE: X/5
 
-[Sharp, specific critiques with file:line references]
+[Sharp, specific critiques with file:line references -- all visual claims backed by screenshot]
 
 Here's how to fix it:
 1. [Fix with exact code/instruction]

package/commands/score.md

@@ -2,6 +2,16 @@ Run the Picasso /score command -- quantified design quality score.
 
 Use the Picasso agent to score the current project's frontend design on a 0-100 scale.
 
+MANDATORY FIRST STEP -- Take and VIEW screenshots before scoring:
+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")
+
+ANTI-HALLUCINATION RULES:
+- 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
+- Never claim "this looks like X" without viewing a screenshot
+
 Categories:
 - Typography (0-15): font choice, type scale, max-width, line-height, letter-spacing
 - Color (0-15): no pure black/gray, OKLCH usage, tinted neutrals, 60-30-10, semantics
@@ -10,6 +20,6 @@ Categories:
 - Motion (0-10): no transition:all, stagger pattern, reduced-motion, no bounce
 - Responsive (0-10): works at 375px, touch targets, no horizontal scroll
 - Performance (0-10): Lighthouse perf score mapped 0-100 -> 0-10
-- Anti-Slop (0-10): deductions for AI-slop fingerprints (-2 each)
+- Anti-Slop (0-10): deductions for each AI-slop fingerprint detected (-2 each)
 
 Output format with visual bars and top fixes for maximum point improvement.

package/package.json

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