@dedesfr/prompter 0.8.11 → 0.8.13

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.13');
 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.13",
     "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

@@ -1,339 +1,194 @@
 ---
 name: ui-ux-pro-v2
-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. 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 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.
+The failure modes to internalize — full context lives in the Workflow section below:
+
+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 0: Read Project Context
+## Workflow
 
-Before designing, silently gather context (do not ask the user for this):
+`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. 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.
+## Step 0: Read Project Context (Silent)
 
----
+Before designing, silently gather — do not ask the user:
 
-## Step 1: Quick Discovery (3 Questions Max)
+- 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.
 
-Ask only what you cannot determine from the codebase.
+---
 
-### For new designs:
-1. **What is this for?** — Page/feature, audience, goal
-2. **Any references?** — Sites or apps they like the feel of (optional)
+## Step 1: Decide Mock vs. Edit
 
-### For redesigns:
-1. **What feels wrong?** — Specific pain points
-2. **What should stay?** — Elements to preserve
+Before discovery, decide the path. **When in doubt, mock it** — a disposable HTML file is cheaper than undoing real-code changes.
 
-### For audits:
-1. **Which pages/components?** — Scope of review
+### 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
 
-### 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
+### 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: Build the Preview (REQUIRED)
+## 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
 
-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 3: 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)
+├── <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
 ```
 
-**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>
-```
+- 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`.
 
-### Section Comments Are Required
+### 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.
 
-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.
-
-### Two-Pass Rule (Low-fi → High-fi)
-
-**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
+- **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`
 
-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>
-```
-
-Always mark one as **Recommended** with a one-line reason.
+- Add hover/focus states, responsive breakpoints
+- File: `<feature>-v1.html`
 
 ### 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.
 
-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:
-
-### 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
-
-### 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
-- 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?
+## Step 5: Implementation (After Preview Approved)
 
-### Present Findings with Before/After Previews
+### 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
 
-For each high-impact issue, produce a **before/after preview** in `.preview/audit/`:
+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.
 
-```
-.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.
-
----
-
-## 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
-
-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.
-
-### Implementation Rules
-
-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.
-
-- **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.13');
 
 program
   .command('init')