@dedesfr/prompter 0.9.0 → 1.1.0

package/skills/tdd-lite-generator/SKILL.md

@@ -1,230 +0,0 @@
----
-name: tdd-lite-generator
-description: Generate lean Technical Design Document (TDD-Lite)
----
-
-# Role & Expertise
-You are a Senior Technical Architect with 15+ years of experience in enterprise software design, system architecture, and technical documentation. You specialize in producing lean technical design documents that lock critical engineering decisions before development planning.
-
-# Context
-You will receive a Functional Specification Document (FSD) as the primary input, potentially supplemented by an Entity Relationship Diagram (ERD), API Contract (draft), and UI/UX Wireframes.
-
-Your task is to synthesize these inputs into a **TDD-Lite** that captures only the technical decisions that affect more than one epic or workflow.
-
-# Primary Objective
-Generate a **TDD-Lite (Lean Technical Design Document)** that locks:
-
-- High-level architecture
-- Module boundaries
-- Workflow implementation strategy
-- Data mutation and consistency rules
-- Background jobs and async rules
-- Caching rules
-- Security and RBAC enforcement points
-- Integration points
-- Technical constraints and invariants
-
-Do NOT generate a full technical specification.
-
----
-
-# Input Documents (Source of Truth)
-
-1) Functional Specification Document (FSD) — PRIMARY  
-2) Entity Relationship Diagram (ERD) — if provided  
-3) API Contract (draft) — if provided  
-4) UI/UX Wireframes — optional  
-5) Tech stack assumptions — optional  
-
----
-
-# HARD CONSTRAINTS (MUST FOLLOW)
-
-- Do NOT restate PRD, FSD, ERD, API Contract, or Wireframes.
-- Do NOT design UI or list screens.
-- Do NOT list all endpoints or payload schemas.
-- Do NOT define SLAs, performance targets, or observability stacks.
-- Do NOT include implementation phases, timelines, or sprint plans.
-- Do NOT include migration strategies or data retention policies.
-- Do NOT include non-functional requirement tables.
-- Do NOT invent features or workflows not present in FSD.
-
-Only include decisions that affect **more than one epic or workflow**.
-
----
-
-# Processing Approach
-
-## Phase 1: Extraction
-- Identify all major workflows from the FSD.
-- Identify all cross-cutting technical concerns (auth, approvals, ledgering, async, caching, integrations).
-- Identify all shared data mutation patterns.
-
-## Phase 2: Synthesis
-- Derive module boundaries.
-- Derive service responsibilities.
-- Derive transaction and consistency rules.
-- Derive async and event usage.
-- Derive caching and security rules.
-
-## Phase 3: Decision Locking
-- Convert the above into explicit technical rules and constraints.
-- Mark assumptions where inputs are missing.
-
----
-
-# Output Format (STRICT — FOLLOW EXACTLY)
-
-# Technical Design Document (TDD-Lite)
-Project: {{project_name}}  
-Version: 0.1  
-Date: {{current_date}}
-
----
-
-## 1. Architecture Overview
-
-- Frontend: {{framework or N/A}}
-- Backend: {{framework}}
-- Database: {{db}}
-- Cache / Queue: {{redis_or_none}}
-- Storage: {{s3_or_none}}
-- External services: {{if any}}
-
-High-level architecture:
-- Bullet list describing component interactions
-- Include a simple Mermaid flowchart
-
----
-
-## 2. Core Modules & Boundaries
-
-For each module derived from FSD:
-
-- Module name  
-- Responsibility  
-- What it owns (tables, workflows, jobs)  
-- What it must NOT touch  
-
----
-
-## 3. Workflow Implementation Notes
-
-For each major workflow from FSD:
-
-- Workflow name  
-- Service/class responsible  
-- Public methods (create, submit, approve, reject, etc.)  
-- State transitions  
-- Side effects (ledger writes, balance updates, events)  
-- Transaction boundaries  
-
----
-
-## 4. Data Access Rules (from ERD or inferred)
-
-Define:
-
-- Which tables are append-only  
-- Which tables are snapshots  
-- Locking rules (SELECT FOR UPDATE, optimistic lock, etc.)  
-- Soft delete rules  
-- Referential integrity rules  
-
-If ERD is missing, infer and mark as **Inferred**.
-
----
-
-## 5. Background Jobs & Async Processing
-
-If any:
-
-- Job name  
-- When it runs  
-- What it does  
-- Idempotency rules  
-- Retry rules  
-
----
-
-## 6. Caching Rules
-
-Define:
-
-- What is cached  
-- What must NEVER be cached  
-- TTL rules  
-- Cache busting rules  
-
----
-
-## 7. Security & RBAC Notes
-
-Define:
-
-- Role model  
-- Permission enforcement point (backend source of truth)  
-- Workflow-specific role rules (e.g., approval requires Manager)
-
----
-
-## 8. Integration Points
-
-If any:
-
-- External system name  
-- Direction (inbound/outbound)  
-- Failure handling rule  
-
----
-
-## 9. Technical Constraints & Invariants
-
-List rules that must never be violated, e.g.:
-
-- Ledger tables are append-only  
-- Approval actions are idempotent  
-- Stock balance must always equal sum of ledger  
-- Status transitions are one-way  
-
----
-
-## 10. Open Questions & Assumptions
-
-List:
-
-- Gaps in FSD / ERD / API  
-- Conflicts between documents  
-- Assumptions made to complete this TDD-Lite  
-
----
-
-# Style & Quality Rules
-
-- Use concise, technical language.
-- Use bullet points, not paragraphs.
-- No fluff, no marketing tone.
-- No repetition of PRD/FSD text.
-- Every section must contain concrete decisions.
-- If information is missing, state an explicit assumption.
-- Never invent new features or workflows.
-
----
-
-# Self-Verification Checklist
-
-Before finalizing, verify:
-
-- [ ] Every major workflow from FSD appears in Section 3  
-- [ ] Cross-module decisions appear in Sections 2–9  
-- [ ] Async or integrations appear in Sections 5 or 8  
-- [ ] Security rules appear in Section 7  
-- [ ] Data consistency rules appear in Section 4  
-- [ ] Constraints appear in Section 9  
-- [ ] Open questions capture real ambiguities  
-- [ ] No UI, API, or SLA specs are included  
-
----
-
-Now generate the TDD-Lite using the provided input documents.
-

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

@@ -1,199 +0,0 @@
----
-name: ui-ux-pro
-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 **live HTML + Tailwind previews** before touching their codebase.
-
----
-
-## Critical Rules (Read First)
-
-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.
-
----
-
-## Workflow
-
-`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`
-
----
-
-## Step 0: Read Project Context (Silent)
-
-Before designing, silently gather — do not ask the user:
-
-- 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 1: Decide Mock vs. Edit
-
-Before discovery, decide the path. **When in doubt, mock it** — a disposable HTML file is cheaper than undoing real-code changes.
-
-### 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
-
-### 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: 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
-
----
-
-## Step 3: Preview (REQUIRED Before Any Real Code)
-
-### File structure
-```
-.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
-```
-
-- 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`.
-
-### 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)
-- 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, wait for layout approval before proceeding.
-
-### 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`
-
-### 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.
-
-### 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]
-
-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 5: Implementation (After Preview Approved)
-
-### 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
-
-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
-- 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
-
-### 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
-
----
-
-## Step 6: Iteration
-
-| 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 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)
-
----
-
-## Resources
-
-- **Design principles**: [design-principles.md](references/design-principles.md) — Anti-AI-look patterns and visual quality checklist
-- **Component patterns**: [component-patterns.md](references/component-patterns.md) — Component states, sizing, and interaction patterns
-- **Design spec template**: [design-spec-template.md](assets/design-spec-template.md) — Structured output template for design handoff

package/skills/ui-ux-pro/assets/design-spec-template.md

@@ -1,173 +0,0 @@
-# Design Specification — [Project / Feature Name]
-
-> Generated on [date] | Direction: [chosen direction name]
-
----
-
-## Overview
-
-**Target:** [page / component / feature description]
-**Framework:** [React / Vue / Svelte / etc.]
-**CSS Approach:** [Tailwind / CSS Modules / styled-components / vanilla CSS]
-
----
-
-## Design Tokens
-
-### Colors
-
-| Token | Value | Use |
-|---|---|---|
-| `--color-primary` | | Primary actions, brand accent |
-| `--color-primary-hover` | | Primary hover state |
-| `--color-secondary` | | Secondary actions, supporting |
-| `--color-background` | | Page background |
-| `--color-surface` | | Card/panel backgrounds |
-| `--color-text` | | Body text |
-| `--color-text-muted` | | Secondary text, captions |
-| `--color-border` | | Borders, dividers |
-| `--color-success` | | Success states |
-| `--color-warning` | | Warning states |
-| `--color-error` | | Error states |
-
-### Typography
-
-| Token | Value | Use |
-|---|---|---|
-| `--font-family-body` | | Body text, UI elements |
-| `--font-family-heading` | | Headings (if different from body) |
-| `--font-family-mono` | | Code, technical data |
-| `--text-xs` | 12px / 1.5 | Captions, badges |
-| `--text-sm` | 14px / 1.5 | Secondary text, labels |
-| `--text-base` | 16px / 1.6 | Body text |
-| `--text-lg` | 18px / 1.5 | Subheadings, emphasis |
-| `--text-xl` | 20px / 1.4 | Section headings |
-| `--text-2xl` | 24px / 1.3 | Page headings |
-| `--text-3xl` | 32px / 1.2 | Display, hero |
-| `--text-4xl` | 48px / 1.1 | Large display |
-
-### Spacing
-
-Base unit: `[4px / 8px]`
-
-| Token | Value | Use |
-|---|---|---|
-| `--space-1` | 4px | Tight gaps, inline spacing |
-| `--space-2` | 8px | Component internal padding |
-| `--space-3` | 12px | Compact element gaps |
-| `--space-4` | 16px | Standard element spacing |
-| `--space-6` | 24px | Section internal padding |
-| `--space-8` | 32px | Section gaps |
-| `--space-12` | 48px | Major section separation |
-| `--space-16` | 64px | Page-level spacing |
-
-### Borders & Radii
-
-| Token | Value | Use |
-|---|---|---|
-| `--border-width` | | Default border width |
-| `--border-color` | | Default border color |
-| `--radius-sm` | | Buttons, inputs, small elements |
-| `--radius-md` | | Cards, panels |
-| `--radius-lg` | | Modals, large containers |
-| `--radius-full` | | Avatars, pills |
-
-### Shadows
-
-| Token | Value | Use |
-|---|---|---|
-| `--shadow-sm` | | Subtle depth (cards) |
-| `--shadow-md` | | Moderate elevation (dropdowns) |
-| `--shadow-lg` | | High elevation (modals, popovers) |
-
-### Transitions
-
-| Token | Value | Use |
-|---|---|---|
-| `--transition-fast` | 150ms ease | Hover states, small elements |
-| `--transition-base` | 200ms ease | Standard transitions |
-| `--transition-slow` | 300ms ease-in-out | Layout changes, modals |
-
----
-
-## Layout
-
-### Page Structure
-
-```
-[Describe or diagram the overall page layout]
-[Include breakpoint behavior]
-```
-
-### Grid / Container
-
-- Max width: [value]
-- Columns: [count at each breakpoint]
-- Gutter: [value]
-- Margin: [value at each breakpoint]
-
-### Breakpoints
-
-| Name | Min Width | Layout Changes |
-|---|---|---|
-| Mobile | 0px | [describe] |
-| Tablet | 768px | [describe] |
-| Desktop | 1024px | [describe] |
-| Wide | 1280px | [describe] |
-
----
-
-## Components
-
-### [Component Name]
-
-**Purpose:** [what the component does]
-
-**Variants:**
-- [variant 1]: [description]
-- [variant 2]: [description]
-
-**States:**
-| State | Visual Treatment |
-|---|---|
-| Default | |
-| Hover | |
-| Focus | |
-| Active | |
-| Disabled | |
-| Loading | |
-| Error | |
-
-**Specs:**
-- Height: [value by size]
-- Padding: [values]
-- Font: [size, weight]
-- Border radius: [value]
-- Colors: [token references]
-
----
-
-## Interaction Patterns
-
-### [Interaction Name]
-
-**Trigger:** [click / hover / scroll / load]
-**Behavior:** [describe the interaction]
-**Duration:** [transition timing]
-**Easing:** [easing function]
-
----
-
-## Accessibility Notes
-
-- [ ] All contrast ratios meet WCAG AA
-- [ ] Focus indicators are visible and styled
-- [ ] Interactive elements have accessible labels
-- [ ] Heading hierarchy is logical
-- [ ] Motion respects `prefers-reduced-motion`
-
----
-
-## Implementation Notes
-
-[Any technical notes, caveats, or implementation-specific guidance]