@dedesfr/prompter 0.8.11 → 0.8.12

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # CHANGELOG
 
+## [0.8.12] - 2026-04-22
+
+### 🔄 Changed
+- **ui-ux-pro-v2 Skill**: Refactored and streamlined workflow for better clarity
+  - Simplified multi-step process into concise, actionable implementation stages
+  - Improved guidance for "Mock vs. Edit" decisions and browser verification
+  - Condensed design principles and iteration rules for faster execution
+
+### 🗑️ Removed
+- **Redundant Skill Directory**: Deleted accidental `mcp-builder copy/` folder and its contents
+
 ## [0.8.11] - 2026-04-22
 
 ### ✨ Added

package/dist/cli/index.js

@@ -16,7 +16,7 @@ const program = new Command();
 program
     .name('prompter')
     .description('Enhance prompts directly in your AI coding workflow')
-    .version('0.8.11');
+    .version('0.8.12');
 program
     .command('init')
     .description('Initialize Prompter in your project')

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@dedesfr/prompter",
-    "version": "0.8.11",
+    "version": "0.8.12",
     "description": "Enhance prompts directly in your AI coding workflow",
     "type": "module",
     "main": "dist/index.js",
@@ -51,4 +51,4 @@
         "typescript": "^5.7.3",
         "vitest": "^2.1.8"
     }
-}
+}

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

@@ -5,335 +5,189 @@ description: Design and revise UI/UX like a senior designer. Analyzes project co
 
 # UI UX Pro v2
 
-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. 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. Let the user react to something concrete.
-2. **Preview before you build** — Every proposal is a real, openable HTML file. No abstract descriptions, no code dumped into the real codebase until direction is approved.
-3. **Low-fi, then high-fi** — Two-pass rule. Confirm layout in grayscale first, then polish with real tokens. This prevents users fixating on color before structure is right.
-4. **Recommend, don't menu** — Variations are fine (up to 3), but always mark one as recommended with a clear reason.
-5. **Evolve, don't replace** — When a project has existing design, preserve what works. Introduce changes incrementally.
-6. **The mock is disposable** — Previews live in `.preview/` and are not the implementation. Always tell the user this.
+These are the most commonly violated rules — internalize before proceeding:
 
----
-
-## Step 0: Read Project Context
-
-Before designing, silently gather context (do not ask the user for this):
-
-1. Read `AGENTS.md` and `CLAUDE.md` at the project root for tech stack and conventions
-2. Detect the CSS system:
-   - **Tailwind** (look for `tailwind.config.*`, `@tailwind` directives)
-   - **Component library** (shadcn, Radix, Material, Chakra, Mantine, etc.)
-   - **Vanilla CSS / CSS modules / CSS-in-JS**
-3. Scan for design tokens: CSS variables, theme files, color palettes, font stacks
-4. Note the frontend framework (React, Vue, Svelte, Next, Laravel Blade, etc.)
-
-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?" Analyze the page, surface 3–4 findings, then build the low-fi. Users can't answer design questions in design vocabulary.
+2. **Low-fi before high-fi, always** — get layout approval in grayscale before applying color, type, or polish. Never skip to high-fi.
+3. **Preview before real code** — never write to the actual codebase until the user approves the preview direction.
+4. **Tailwind CDN in previews, always** — even if the project uses shadcn/Material/etc. Previews are disposable; don't entangle them with the build system.
+5. **Section comments required** — every major HTML block needs `<!-- Section: Name -->` so users can give spatial feedback without knowing HTML.
+6. **Default one variant** — build one recommended design, then offer: *"I can show 1–2 alternatives if you want to compare."* Don't push a menu upfront.
+7. **Always include a recommendation** — every choice you present must name a preferred option with a one-line reason.
+8. **Don't delete `.preview/`** — user keeps these as reference. Never auto-clean.
+9. **Tell user to verify in browser** — do not attempt to run the dev server yourself.
 
 ---
 
-## Step 1: Quick Discovery (3 Questions Max)
+## Workflow
 
-Ask only what you cannot determine from the codebase.
+`Step 0: Read context → Step 1: Discovery → Step 2: Low-fi preview → [approval] → Step 3: High-fi → [approval] → Step 4: Implement → Step 5: Iterate`
 
-### For new designs:
-1. **What is this for?** — Page/feature, audience, goal
-2. **Any references?** — Sites or apps they like the feel of (optional)
+---
 
-### For redesigns:
-1. **What feels wrong?** — Specific pain points
-2. **What should stay?** — Elements to preserve
+## Step 0: Read Project Context (Silent)
 
-### For audits:
-1. **Which pages/components?** — Scope of review
+Before designing, silently gather — do not ask the user:
 
-### Do NOT ask:
-- "Which design direction resonates?" — You pick based on context
-- "What color scheme do you prefer?" — Derive from brand or propose one
-- Multiple-choice aesthetic menus — These overwhelm non-designers
+- 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.
 
 ---
 
-## Step 2: Build the Preview (REQUIRED)
+## Step 1: Discovery
+
+### New designs
+1. Ask: *"What is this for?"* — page/feature, audience, goal
+2. Ask one optional: *"Any vibe or reference in mind? (totally optional)"* — proceed regardless
+
+### 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 before I start:
+   - 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 one soft optional: *"Anything to keep, or a vibe/reference in mind? (I'll proceed either way)"*
+4. Build the low-fi immediately — with or without their answer
+
+### 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
 
-Every design proposal MUST be a real HTML file the user can open in a browser.
-
-### Preview Directory
+---
 
-Create previews in `.preview/` at the project root:
+## Step 2: Preview (REQUIRED Before Any Real Code)
 
+### File structure
 ```
 .preview/
-├── index.html              # Main preview (or variations hub)
-├── hero-lowfi.html         # Low-fi pass
-├── hero-v1.html            # High-fi variation 1 (recommended)
-├── hero-v2.html            # High-fi variation 2
-└── hero-v3.html            # High-fi variation 3 (optional)
-```
-
-**Rules for `.preview/`:**
-- Do NOT auto-delete. The user keeps these as reference.
-- Add `.preview/` to `.gitignore` if not already ignored (ask first if repo tracks it).
-- Each file must be standalone and openable with `file://` or a simple static server.
-
-### Stack Decision — Which CSS to Use in the Mock
-
-**Always use plain Tailwind via CDN in the preview, even if the project uses shadcn/Radix/Material.**
-
-Reasoning:
-- **Efficiency** — no build step, no dependency wiring, instant preview
-- **Isolation** — the mock stays disposable; not entangled with the real design system
-- **Portability** — user can open the file without running their dev server
-
-Exceptions:
-- If the project uses **custom CSS variables or brand tokens**, inline them in a `<style>` block in the mock so colors/fonts match
-- If the project has **no CSS system at all**, still use Tailwind CDN — it's the fastest way to produce a quality mock
-
-The real implementation (Step 4) uses the project's actual design system (shadcn components, Material, etc.). The mock uses plain Tailwind. Keep this separation clear.
-
-### Preview HTML Template
-
-```html
-<!doctype html>
-<html lang="en">
-<head>
-  <meta charset="utf-8" />
-  <meta name="viewport" content="width=device-width, initial-scale=1" />
-  <title>Preview — [Feature Name]</title>
-  <script src="https://cdn.tailwindcss.com"></script>
-  <style>
-    /* Inline project brand tokens here if they exist */
-    :root {
-      --brand: #0ea5e9;
-      --brand-fg: #ffffff;
-    }
-    body { font-family: ui-sans-serif, system-ui, sans-serif; }
-  </style>
-</head>
-<body class="bg-gray-50 text-gray-900">
-  <!-- Section: Header -->
-  <header class="...">...</header>
-
-  <!-- Section: Hero -->
-  <section class="...">...</section>
-
-  <!-- Section: Features -->
-  <section class="...">...</section>
-
-  <!-- Section: Footer -->
-  <footer class="...">...</footer>
-</body>
-</html>
+├── <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
 ```
 
-### Section Comments Are Required
-
-Every major block gets an HTML comment: `<!-- Section: Hero -->`. This preserves the "point and move" feedback pattern — users can say "move the Hero below Features" without knowing HTML.
+- Files must be standalone, openable with `file://`
+- Add `.preview/` to `.gitignore` if not ignored (ask first if repo tracks it)
 
-### Two-Pass Rule (Low-fi → High-fi)
+### 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.
 
-**Pass 1: Low-fi** (grayscale, structural)
-- No brand colors, only grays and neutrals
-- System font only
+### 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
 - File: `<feature>-lowfi.html`
 
-Present this first. Confirm the bones are right.
+Present, wait for layout approval before proceeding.
 
-**Pass 2: High-fi** (polish)
+### Pass 2: High-fi (after low-fi is approved)
 - Apply brand colors, typography, shadows, borders
-- Add interaction states (hover, focus)
-- Add responsive breakpoints
-- File: `<feature>-v1.html` (+ optional `-v2.html`, `-v3.html` for variations)
-
-Move to Pass 2 only after the user confirms the low-fi structure.
-
-### Variations (Optional, Max 3)
-
-When the design direction is genuinely ambiguous, produce up to **3 variations** in the high-fi pass. Each in its own file. Create a `variations.html` hub that iframes or links to all three side-by-side for comparison:
-
-```html
-<!-- variations.html -->
-<div class="grid grid-cols-1 lg:grid-cols-3 gap-4 p-4">
-  <div>
-    <h3 class="font-semibold mb-2">V1 — Minimal ⭐ Recommended</h3>
-    <iframe src="./hero-v1.html" class="w-full h-[600px] border rounded"></iframe>
-    <p class="text-sm text-gray-600 mt-2">Best because [reason].</p>
-  </div>
-  <div>
-    <h3 class="font-semibold mb-2">V2 — Bold</h3>
-    <iframe src="./hero-v2.html" class="w-full h-[600px] border rounded"></iframe>
-    <p class="text-sm text-gray-600 mt-2">Better if [scenario].</p>
-  </div>
-  <div>
-    <h3 class="font-semibold mb-2">V3 — Editorial</h3>
-    <iframe src="./hero-v3.html" class="w-full h-[600px] border rounded"></iframe>
-    <p class="text-sm text-gray-600 mt-2">Better if [scenario].</p>
-  </div>
-</div>
-```
+- Add hover/focus states, responsive breakpoints
+- File: `<feature>-v1.html`
 
-Always mark one as **Recommended** with a one-line reason.
-
-### Delegating to `frontend-design` Skill
-
-If a `frontend-design` skill (or similar HTML/Tailwind generation skill) is available in the current session, delegate the actual mock construction to it — pass your layout decisions and content, let it produce the markup. If not available, build the markup inline. Either way, you own the layout decisions, the stack rules above, and the section-comment convention.
-
-### Presenting the Proposal
-
-Structure your message 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 Name]
 
 **Approach:** [1-2 sentences on direction and why]
-
 **Preview:** `.preview/<feature>-lowfi.html` (open in browser)
 
 ### Key Decisions
 - [Decision]: [rationale]
-- [Decision]: [rationale]
-
-This is a throwaway mock — once you approve the direction I'll build
-it properly in your codebase using [shadcn / Material / your design system].
 
+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: Mock vs. Edit — Decision Tree
-
-Not every request needs a standalone mock. Decide up front:
+## Step 3: Mock vs. Edit
 
-### Mock first (build in `.preview/`)
-- New page or feature from scratch
-- Major redesign of an existing page
-- Multiple directions are plausible and you want the user to see them
-- User is non-technical and needs to see before they can react
+### Build a preview when:
+- New page or feature
+- Major redesign
+- Multiple directions are plausible
+- User is non-technical and needs to see before reacting
 
-### Edit real code directly
-- Small tweaks to an existing component (color, spacing, copy)
-- Fixing a specific usability bug the user pointed at
-- Adding a single element to an already-approved layout
+### Edit real code directly when:
+- Small tweak (color, spacing, copy)
+- Fixing a specific bug the user pointed at
+- Adding one element to an already-approved layout
 - User is a developer who asked for a specific change
 
-### When in doubt — mock it
-The cost of a disposable HTML file is low. The cost of the user rejecting a real-code change and you having to undo it is higher.
-
----
-
-## Step 4: Design Analysis (For Existing Projects)
-
-When auditing existing code, analyze yourself and present findings organized by impact.
-
-### What to Evaluate
-1. **Visual hierarchy** — Is important content visually dominant?
-2. **Consistency** — Are spacing, colors, components systematic?
-3. **Usability** — Contrast (WCAG AA minimum), touch targets (44px+), form labels, affordances
-4. **Responsiveness** — Does it work across breakpoints?
-5. **Interaction quality** — Transitions, loading/error/empty states
-6. **Dark mode** — If the project supports it, does this feature work in both themes?
-
-### Present Findings with Before/After Previews
-
-For each high-impact issue, produce a **before/after preview** in `.preview/audit/`:
-
-```
-.preview/audit/
-├── nav-before.html
-├── nav-after.html
-└── index.html    # Side-by-side comparison
-```
-
-Don't just list problems — show the fix in HTML the user can open.
+**When in doubt — mock it.** A disposable HTML file costs little; undoing rejected real-code changes costs more.
 
 ---
 
-## Step 5: Implementation (Real Codebase)
-
-Once the preview is approved, implement in the project's actual stack.
-
-### 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 (use the project's design system — shadcn, Material, etc.)
-4. **Interaction states** — Hover, focus, loading, error, empty
-5. **Responsive adaptations** — Mobile/tablet breakpoints
-6. **Dark mode** — If the project supports theming, verify both modes
-
-After each chunk, check in: "Layout is done — moving to typography next, or want to adjust anything?"
-
-### Browser Verification
+## Step 4: Implementation (After Preview Approved)
 
-For UI changes, start the dev server and verify in a browser before reporting the task complete. Test the golden path and at least one edge case. If you cannot run the dev server, say so explicitly — do not claim the work is done based on a successful build or passing type check.
+### 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
 
-### Implementation Rules
+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.
 
-Follow the anti-pattern catalog in [design-principles.md](references/design-principles.md):
+### Rules (see [design-principles.md](references/design-principles.md) for full catalog)
 - No gratuitous gradients, glassmorphism, or trend effects without purpose
-- Intentional border-radius (not 9999px on everything)
+- Intentional border-radius — not `rounded-full` on everything
 - Typography does 80% of the work
-- Color used sparingly: 1-2 primaries, 1 accent, rest neutrals
-- Faster transitions (150-200ms) for small elements, slower (300-400ms) for layout
+- Color: 1–2 primaries, 1 accent, rest neutrals
+- Transitions: 150–200ms for small elements, 300–400ms for layout shifts
 - Whitespace creates hierarchy
 
-### Adapting Existing Design
+### Adapting existing design
 - Preserve brand colors, fonts, recognizable patterns
 - Use existing CSS variables and design tokens
-- Introduce changes gradually
-- Flag when a user request conflicts with their design system; recommend the best path
+- Flag conflicts between the user's request and their design system; recommend the best path
 
 ---
 
-## Step 6: Iteration
-
-### Responding to Feedback
-- **"I like it but..."** — Targeted adjustment in the preview, preserve what works
-- **"It's not what I imagined"** — Revise the preview before recoding
-- **"Can you try..."** — Update the preview, re-open
-- **"Perfect!"** — Move from preview to real implementation
-
-### When the User is Unsure
-1. Make the decision yourself based on best practices
-2. Explain your reasoning in plain language
-3. Build the preview
-4. Say: "This is what I'd recommend. If something feels off once you see it, tell me and I'll adjust."
-
----
-
-## Handling Options — The Recommendation Rule
-
-**Every time you present a choice, you MUST include a recommendation.**
-
-For HTML previews with variations, render all variations but mark one as recommended in the hub file and in your message. Never present more than 3 variations at once.
-
----
-
-## Skill Level Adaptation
-
-Infer from how the user communicates. Never ask.
+## Step 5: Iteration
 
-- **Non-designer**: Make all decisions, explain plainly, previews are essential, give complete code. Skip jargon.
-- **Some design sense**: Focus on trade-offs, provide code with brief rationale.
-- **Designer/developer**: Be concise, engage as a peer, previews can be lighter.
+| 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 from project type and stack. Propose a cohesive starting point.
-- **Screenshot input**: Analyze visually, recreate as an 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 would fail accessibility, explain plainly and offer an accessible alternative.
-- **Performance**: Flag heavy animations, large images, complex CSS; suggest alternatives.
-- **Dark mode**: If the project supports theming, every preview should include a dark-mode variant (toggle or separate file).
-- **No browser access**: If you can't run the dev server to verify, say so — don't claim success from a passing build alone.
+- **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.11');
+  .version('0.8.12');
 
 program
   .command('init')