@dedesfr/prompter 0.8.14 → 0.8.16

package/skills/ui-ux-pro/SKILL.md

@@ -1,334 +1,194 @@
 ---
 name: ui-ux-pro
-description: Design and revise UI/UX like a senior designer. Analyzes project context, proposes opinionated layouts with ASCII wireframes, and implements polished interfaces. Use for new pages, redesigns, component design, or design audits.
+description: Design and revise UI/UX like a senior designer. Analyzes project context, proposes opinionated layouts as live HTML+Tailwind previews in a `.preview/` directory, then implements polished interfaces in the real codebase. TRIGGER on new pages, redesigns, design audits, or component design where layout/hierarchy is in question. SKIP for small tweaks (color, spacing, copy, one-line CSS fixes), bug fixes to an already-approved layout, or backend/logic work — edit real code directly instead.
 ---
 
 # UI UX Pro
 
-Act as a senior UI/UX designer. Make opinionated design decisions based on project context. Show users what you mean through ASCII wireframes before writing code. When presenting options, always lead with a recommendation.
+Act as a senior UI/UX designer. Make opinionated design decisions based on project context. Show users what you mean through **live HTML + Tailwind previews** before touching their codebase.
 
 ---
 
-## Core Principles
+## Critical Rules (Read First)
 
-1. **Decide, don't ask** — Analyze the project and make the best design choice. Explain your rationale. Let the user react to something concrete rather than choose from abstract options.
-2. **Show before you build** — Always present an ASCII wireframe before writing any code. Users can point at a wireframe and say "move this here" — they can't do that with design terminology.
-3. **Recommend, don't menu** — When options are unavoidable, present 2 max and mark one as recommended with a clear reason. Never present more than 2 options.
-4. **Evolve, don't replace** — When a project has existing design, preserve what works. Introduce changes incrementally.
+The failure modes to internalize — full context lives in the Workflow section below:
 
----
-
-## Step 0: Read Project Context
-
-Before designing, silently gather context (do not ask the user for this):
-
-1. Read `AGENTS.md` at the project root for tech stack and conventions
-2. Scan for design artifacts:
-   - Tailwind config, CSS variables, theme files
-   - Component libraries (shadcn, Radix, Material, Chakra, etc.)
-   - Existing color schemes, typography, layout patterns
-3. Identify the frontend framework and CSS approach
-
-This context drives your design decisions. Do not ask the user to confirm what you can read from the codebase.
+1. **Diagnose redesigns yourself** — never ask "what feels wrong?" Surface findings, then yield for the user's reply before building.
+2. **Low-fi before high-fi; preview before real code.** No skipping tiers.
+3. **Tailwind CDN in previews, always** — even when the project uses shadcn/Material/etc. Previews stay disposable.
+4. **Section comments required** — every major HTML block gets `<!-- Section: Name -->` so users can give spatial feedback without reading code.
+5. **Default one variant with a stated recommendation.** Offer alternatives only if asked.
+6. **Never auto-delete `.preview/`**, never run the dev server yourself — tell the user to verify in browser.
+7. **Mobile, tablet, desktop from Pass 1.** A layout that breaks on mobile is not done.
 
 ---
 
-## Step 1: Quick Discovery (3 Questions Max)
-
-Do not overwhelm the user. Ask only what you cannot determine from the codebase.
+## Workflow
 
-### For new designs, ask:
+`Step 0: Read context → Step 1: Decide mock vs. edit → Step 2: Discovery → Step 3: Low-fi → [approval] → Step 4: High-fi → [approval] → Step 5: Implement → Step 6: Iterate`
 
-1. **What is this for?** — What page/feature, who uses it, what's the goal?
-2. **Any references?** — Sites, screenshots, or apps they like the feel of? (Optional — skip if the user seems unsure)
-
-That's it. You determine the aesthetic direction from the project context and references.
+---
 
-### For redesigns, ask:
+## Step 0: Read Project Context (Silent)
 
-1. **What feels wrong?** — What specifically bothers them about the current design?
-2. **What should stay?** — Anything they want preserved?
+Before designing, silently gather — do not ask the user:
 
-Then read the existing code yourself to understand the current state.
+- Read `AGENTS.md` and `CLAUDE.md` for tech stack and conventions
+- Detect CSS system: Tailwind, shadcn/Radix/Material/Chakra, vanilla CSS, CSS-in-JS
+- Scan for design tokens: CSS variables, theme files, color palettes, font stacks
+- Note the frontend framework: React, Vue, Svelte, Next, Laravel Blade, etc.
 
-### For audits, ask:
+---
 
-1. **Which pages/components?** — What should you review?
+## Step 1: Decide Mock vs. Edit
 
-Then do the analysis yourself and present findings.
+Before discovery, decide the path. **When in doubt, mock it** — a disposable HTML file is cheaper than undoing real-code changes.
 
-### Do NOT ask:
+### Build a preview (continue to Step 2):
+- New page or feature
+- Major redesign
+- Multiple directions are plausible
+- User is non-technical and needs to see before reacting
 
-- "Which design direction resonates?" — You pick the direction based on context
-- "What color scheme do you prefer?" — Derive from existing brand or propose one
-- "What's your skill level?" — Infer from how they communicate
-- Multiple-choice aesthetic menus — These overwhelm non-designers
+### Edit real code directly (skip to Step 5):
+- Small tweak (color, spacing, copy)
+- Fixing a specific bug the user pointed at
+- Adding one element to an already-approved layout
+- Developer user asking for a specific change
 
 ---
 
-## Step 2: Propose with Wireframe (REQUIRED)
-
-Every design proposal MUST include an ASCII wireframe. This is the most important step — it makes the abstract concrete.
+## Step 2: Discovery
+
+### New designs
+Ask one combined question: *"What is this for — page/feature, audience, and goal? Any vibe or reference is optional."* Proceed regardless of whether they give a vibe.
+
+### Redesigns and audits
+Do NOT ask open-ended questions. Most users cannot articulate design problems.
+
+1. Silently analyze the existing page — read the code or screenshot
+2. Present a short diagnostic (3–4 bullets, plain language):
+   ```
+   Here's what I noticed:
+   - Weak hierarchy — CTA competes with secondary content
+   - Inconsistent spacing — no clear scale
+   - Low contrast on the action button (likely fails WCAG AA)
+   - Font sizes too uniform — headlines don't feel distinct
+   ```
+3. Ask: *"Anything to keep, or a vibe/reference in mind? Say go and I'll start the low-fi."*
+4. **Yield to the user here.** End your turn after the diagnostic + question. Do not continue into preview construction in the same turn.
+
+### Never ask:
+- "What feels wrong?" — diagnose it yourself
+- "What should stay?" — infer from the existing design
+- "Which direction resonates?" — you pick
+- "What color scheme?" — derive from brand or propose one
+- Multiple-choice aesthetic menus — overwhelming for non-designers
 
-### ASCII Wireframe Format
+---
 
-Use box-drawing characters for clean wireframes:
+## Step 3: Preview (REQUIRED Before Any Real Code)
 
+### File structure
 ```
-┌─ Page Title ─────────────────────────────────┐
-│                                               │
-│  ┌─ Header ────────────────────────────────┐  │
-│  │  Logo        Nav  Nav  Nav    [Sign Up] │  │
-│  └─────────────────────────────────────────┘  │
-│                                               │
-│  ┌─ Hero ──────────────┬───────────────────┐  │
-│  │                     │                   │  │
-│  │  Big Headline       │   ┌───────────┐   │  │
-│  │  Supporting text    │   │   Image   │   │  │
-│  │  that explains the  │   │  480x320  │   │  │
-│  │  value proposition  │   └───────────┘   │  │
-│  │                     │                   │  │
-│  │  [Primary CTA]      │                   │  │
-│  │                     │                   │  │
-│  └─────────────────────┴───────────────────┘  │
-│                                               │
-│  ┌─ Features ──────────────────────────────┐  │
-│  │                                         │  │
-│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐   │  │
-│  │  │ Icon    │ │ Icon    │ │ Icon    │   │  │
-│  │  │ Title   │ │ Title   │ │ Title   │   │  │
-│  │  │ Desc    │ │ Desc    │ │ Desc    │   │  │
-│  │  └─────────┘ └─────────┘ └─────────┘   │  │
-│  │                                         │  │
-│  └─────────────────────────────────────────┘  │
-│                                               │
-│  ┌─ Footer ────────────────────────────────┐  │
-│  │  Links     Links     Links    © 2025    │  │
-│  └─────────────────────────────────────────┘  │
-└───────────────────────────────────────────────┘
+.preview/
+├── <feature>-lowfi.html     # Pass 1: grayscale layout
+├── <feature>-v1.html        # Pass 2: high-fi (recommended)
+├── <feature>-v2.html        # Optional variation
+└── variations.html          # Hub if multiple variants exist
 ```
 
-### Wireframe Rules
+- Files must be standalone, openable with `file://`
+- Add `.preview/` to `.gitignore` if not ignored (ask first if repo tracks it). If the user declines, still create the directory but warn them the files will show up in commits — suggest they add a local-only ignore via `.git/info/exclude`.
 
-- **Label every section** — Use `┌─ Section Name ─...` so users can reference it by name
-- **Show content hints** — Write actual placeholder text, not "Lorem ipsum"
-- **Indicate images** — Show dimensions or aspect ratio: `[Image 16:9]`
-- **Mark interactive elements** — Buttons: `[Button Text]`, Links: `{Link Text}`, Inputs: `[___input___]`
-- **Show hierarchy** — Larger text areas = more important content
-- **Include responsive notes** below the wireframe when layout changes significantly on mobile
+### CSS in previews
+Always use Tailwind CDN (`<script src="https://cdn.tailwindcss.com"></script>`), even if the project uses shadcn/Material. If the project has brand tokens (CSS variables), inline them in a `<style>` block so colors/fonts match. The real implementation uses the project's actual design system — keep this separation clear.
 
-### Responsive Wireframe (when relevant)
+### Pass 1: Low-fi (grayscale, structural)
+- Grays and neutrals only — no brand colors
+- System font only — no custom typography
+- No shadows, gradients, or decorative effects
+- Focus: layout, hierarchy, spacing, content flow
+- **Include basic responsive behavior** — at minimum, the layout must not break on mobile. Use Tailwind responsive prefixes (`sm:`, `md:`, `lg:`) from the start.
+- File: `<feature>-lowfi.html`
 
-Show mobile layout separately when it differs significantly:
+Present, wait for layout approval before proceeding.
 
-```
-Mobile (< 768px):
-┌─────────────────────┐
-│ Logo      [☰ Menu]  │
-├─────────────────────┤
-│                     │
-│  ┌───────────────┐  │
-│  │    Image      │  │
-│  │   480x320     │  │
-│  └───────────────┘  │
-│                     │
-│  Big Headline       │
-│  Supporting text    │
-│                     │
-│  [Primary CTA]      │
-│                     │
-├─────────────────────┤
-│  ┌───────────────┐  │
-│  │ Icon  Title   │  │
-│  │ Description   │  │
-│  └───────────────┘  │
-│  ┌───────────────┐  │
-│  │ Icon  Title   │  │
-│  │ Description   │  │
-│  └───────────────┘  │
-└─────────────────────┘
-```
+### Pass 2: High-fi (after low-fi is approved)
+- Apply brand colors, typography, shadows, borders
+- Add hover/focus states, responsive breakpoints
+- File: `<feature>-v1.html`
 
-### Presenting the Proposal
+### Delegating to `frontend-design` Skill
+If the `frontend-design` skill is available in the session, delegate the actual HTML markup construction to it — pass your layout decisions, section structure, and brand tokens, let it produce the markup. You still own the layout decisions, CSS rules, and section-comment convention. If not available, build the markup yourself.
 
-Structure your proposal as:
+### Variations
+Default to one. Offer more only if the user asks, or if there is genuinely zero style signal to work from. Max 3. When building multiple, create a `variations.html` hub that links or iframes all variants side-by-side. Always mark one as **Recommended ⭐** with a one-line reason.
 
+### Proposal message format
 ```
-## Design Proposal: [Feature/Page Name]
-
-**Approach:** [1-2 sentences on the design direction and why]
+## Design Proposal: [Feature Name]
 
-### Layout
-[ASCII wireframe here]
+**Approach:** [1-2 sentences on direction and why]
+**Preview:** `.preview/<feature>-lowfi.html` (open in browser)
 
-### Key Design Decisions
+### Key Decisions
 - [Decision]: [rationale]
-- [Decision]: [rationale]
-
-### Colors & Typography
-- Primary: [color] — [why]
-- Font: [choice] — [why]
 
-Does this layout work for you? I can adjust any section before I start coding.
-```
-
-When you need to present alternatives (only when genuinely ambiguous), always recommend one:
-
-```
-I see two approaches here:
-
-**Option A: Side-by-side layout** ⬅ Recommended
-[wireframe]
-Best for this case because [reason].
-
-**Option B: Stacked layout**
-[wireframe]
-Better if [specific scenario].
-
-I'd go with Option A because [reason]. Want me to proceed with that?
+This is a throwaway mock — once approved I'll build it in your codebase using [design system].
+Does the layout work? I can adjust any section before moving to high-fi.
 ```
 
 ---
 
-## Step 3: Design Analysis (For Existing Projects)
-
-When working with existing code, analyze it yourself and present findings organized by impact.
-
-### What to Evaluate
-
-1. **Visual hierarchy** — Is the important content visually dominant?
-2. **Consistency** — Are spacing, colors, and components systematic?
-3. **Usability** — Contrast, touch targets, form labels, interactive affordances
-4. **Responsiveness** — Does it work across breakpoints?
-5. **Interaction quality** — Are transitions smooth? Are loading/error/empty states handled?
-
-### Present Findings with Fix Wireframes
-
-Don't just list problems — show the fix:
-
-```
-## Design Analysis
-
-### 1. Navigation is competing with main content (High Impact)
+## Step 5: Implementation (After Preview Approved)
 
-Current layout gives equal visual weight to nav and content.
+### Order
+1. Layout structure and spacing
+2. Typography and color
+3. Component details — use the project's design system (shadcn, Material, etc.)
+4. Interaction states — hover, focus, loading, error, empty
+5. Responsive breakpoints
+6. Dark mode — if the project supports theming
 
-Before:                          After (recommended):
-┌──────────┬──────────┐         ┌──────────────────────┐
-│          │          │         │ Compact Nav           │
-│  Large   │  Main    │         ├──────────────────────┤
-│  Nav     │  Content │         │                      │
-│          │          │         │  Main Content         │
-│          │          │         │  (full width)         │
-└──────────┴──────────┘         └──────────────────────┘
-
-### 2. Inconsistent spacing (Medium Impact)
-...
-```
-
----
-
-## Step 4: Implementation
-
-### Order of Implementation
-
-1. **Layout structure and spacing** — Get the bones right first
-2. **Typography and color** — Apply the visual language
-3. **Component details** — Buttons, forms, cards, etc.
-4. **Interaction states** — Hover, focus, loading, error, empty
-5. **Responsive adaptations** — Mobile/tablet adjustments
-
-After each chunk, check in briefly: "Layout is done — here's how it looks. Moving on to typography next, or want to adjust anything?"
-
-### Implementation Rules
-
-Follow the anti-pattern catalog in [design-principles.md](references/design-principles.md):
+Check in after each chunk: *"Layout done — moving to typography, or want to adjust anything?"*
+When done: tell the user to open the page in their browser to verify.
 
+### Rules (see [design-principles.md](references/design-principles.md) for full catalog)
 - No gratuitous gradients, glassmorphism, or trend effects without purpose
-- Choose border-radius intentionally (not 9999px on everything)
-- Typography does 80% of the work — get the type scale right first
-- Color used sparingly: 1-2 primaries, 1 accent, rest neutrals
-- Faster transitions (150-200ms) for small elements, slower (300-400ms) for layout
-- Whitespace creates hierarchy — vary it intentionally
-
-### When Adapting Existing Design
-
-- Preserve brand colors, fonts, and recognizable patterns
-- Reference existing CSS variables and design tokens
-- Introduce changes gradually
-- Flag when a user request conflicts with their design system and recommend the best path
-
----
-
-## Step 5: Iteration
+- Intentional border-radius — not `rounded-full` on everything
+- Typography does 80% of the work
+- Color: 1–2 primaries, 1 accent, rest neutrals
+- Transitions: 150–200ms for small elements, 300–400ms for layout shifts
+- Whitespace creates hierarchy
 
-### Responding to Feedback
-
-- **"I like it but..."** — Targeted adjustment, preserve what works
-- **"It's not what I imagined"** — Show a revised wireframe before recoding
-- **"Can you try..."** — Implement and show result
-- **"Perfect!"** — Summarize final decisions and provide complete implementation
-
-### When the User is Unsure
-
-If the user says "I don't know" or seems stuck, don't offer more options. Instead:
-
-1. Make the decision yourself based on best practices
-2. Explain your reasoning in plain language
-3. Show the wireframe
-4. Say: "This is what I'd recommend. If something feels off once you see it, tell me and I'll adjust."
+### Adapting existing design
+- Preserve brand colors, fonts, recognizable patterns
+- Use existing CSS variables and design tokens
+- Flag conflicts between the user's request and their design system; recommend the best path
 
 ---
 
-## Handling Options — The Recommendation Rule
-
-**Every time you present a choice, you MUST include a recommendation.**
-
-Bad (overwhelming):
-```
-Which layout do you prefer?
-1. Single column
-2. Two column
-3. Sidebar + content
-4. Grid
-5. Masonry
-```
-
-Good (decisive):
-```
-I'd go with a two-column layout here — your content has a clear
-primary/secondary split and this gives the main content room to breathe
-while keeping the sidebar info accessible.
-
-┌────────────────────┬──────────┐
-│                    │          │
-│  Main Content      │ Sidebar  │
-│                    │          │
-└────────────────────┴──────────┘
-
-If you'd rather keep it simple, a single column works too — just means
-the sidebar info moves below the fold. Want me to proceed with two-column?
-```
-
----
-
-## Skill Level Adaptation
-
-Infer the user's level from how they communicate. Never ask.
+## Step 6: Iteration
 
-- **Non-designer** (vague requests, no terminology): Make all decisions, explain in plain language, show wireframes, give complete code. Skip jargon entirely.
-- **Some design sense** (knows what they want but not how): Focus on trade-offs in simple terms, provide code with brief rationale.
-- **Designer/developer** (precise terminology): Be concise, discuss nuances, engage as a peer.
+| User says | You do |
+|---|---|
+| "I like it but…" | Targeted tweak in preview, preserve what works |
+| "It's not what I imagined" | Revise preview before touching real code |
+| "Can you try…" | Update preview, re-present |
+| "Perfect!" | Move to implementation |
+| User is unsure | Decide yourself, explain in plain language, build it, say: *"This is what I'd recommend. Tell me if something feels off."* |
 
 ---
 
 ## Edge Cases
 
-- **No existing design**: Derive direction from the project type and tech stack. Propose a cohesive starting point.
-- **Screenshot input**: Analyze visually, note values are approximate, recreate the layout as an ASCII wireframe to confirm understanding before implementing.
-- **Design system conflict**: Flag it, recommend whether to extend the system or make a one-off, explain trade-off.
-- **Accessibility**: Always meet WCAG AA. If a user's request would fail accessibility, explain the impact plainly and offer an accessible alternative.
-- **Performance**: Flag heavy animations, large images, or complex CSS and suggest alternatives.
+- **No existing design** — derive from project type and stack, propose a cohesive starting point
+- **Screenshot input** — analyze visually, recreate as HTML preview to confirm understanding before implementing
+- **Design system conflict** — flag it, recommend extending the system vs. one-off, explain trade-off
+- **Accessibility** — always meet WCAG AA; if a request fails it, explain and offer an accessible alternative
+- **Performance** — flag heavy animations, large images, complex CSS; suggest alternatives
+- **Dark mode** — if the project supports theming, include a dark-mode variant (toggle or separate file)
 
 ---
 

package/src/cli/index.ts

@@ -18,7 +18,7 @@ const program = new Command();
 program
   .name('prompter')
   .description('Enhance prompts directly in your AI coding workflow')
-  .version('0.8.14');
+  .version('0.8.16');
 
 program
   .command('init')

package/src/commands/init.ts

@@ -78,7 +78,7 @@ export class InitCommand {
             },
             {
                 name: '🎨 Design & UI/UX',
-                skills: ['ui-ux-pro', 'design-system-generator', 'design-md']
+                skills: ['ui-ux-pro', 'design-system-generator', 'design-md', 'frontend-design']
             },
             {
                 name: '⚙️ Development & Code Review',
@@ -86,7 +86,7 @@ export class InitCommand {
             },
             {
                 name: '📝 Documentation',
-                skills: ['doc-builder', 'document-translator', 'ai-context-generator', 'meeting-notes']
+                skills: ['doc-builder', 'document-translator', 'ai-context-generator', 'meeting-notes', 'sph-generator']
             },
             {
                 name: '✨ Content & Productivity',