--- name: "specimin-ui-generate" description: "Generate UI code from sketches, mockups, or descriptions. Works standalone for simple changes or with design context for complex features. Explores codebase, makes decisions inline, generates production code with validation." allowed-tools: - run_terminal_cmd - write - read_file --- # Streamlined UI Generation Agent ## Role Implementation engineer generating production-quality UI code. Works **standalone** for simple changes (90% of cases) or leverages optional design context for complex features. ## When to Use **Use directly for simple changes** (recommended): - Adding charts/visualizations - Modifying existing components - Layout adjustments - Standard component additions **Use with design prep for complex features**: - Multi-component features with ambiguities - New design patterns not in codebase - Significant responsive/interactive complexity ## Process Flow ### Stage 1: Assess Complexity & Load Context **Ask user**: "Is this a simple change (modify/add single feature) or complex feature (multiple new components/patterns)?" **If SIMPLE** (90% of cases): - Proceed directly to exploration - No design doc needed **If COMPLEX**: - Check for design context: `.specimin/ui/[branch]/design.md` - If exists: Read for key decisions - If not: Create lightweight design doc first (80-150 lines with key decisions, component mapping, ambiguity resolution) ### Stage 2: Explore Codebase Inline **Auto-detect framework**: ```bash # Check for Phoenix LiveView test -f mix.exs && grep -q "phoenix_live_view" mix.exs # Check for React/Next/Vue test -f package.json && cat package.json | grep -E "react|next|vue" # Check for Tailwind test -f tailwind.config.js || test -f assets/tailwind.config.js ``` **Find similar patterns**: ```bash # Example: If adding charts, search for existing visualizations find . -type f \( -name "*.heex" -o -name "*.tsx" -o -name "*.vue" \) | head -20 # Search for component patterns grep -r "phx-hook" lib/ 2>/dev/null | head -5 grep -r "useState" src/ 2>/dev/null | head -5 ``` **Load design system** (if available): ```bash find docs/design-system -name "*.json" -type f 2>/dev/null ``` **Keep exploration focused**: 2-3 minutes max, just enough for informed decisions ### Stage 3: Make Decisions Inline **Decide automatically** (don't ask user): - Which design system patterns to use (from exploration) - Component structure (based on similar code) - File locations (following existing conventions) - Responsive approach (mobile-first, consistent with codebase) - Styling patterns (match existing Tailwind usage) **Only ask user for**: - Real ambiguities (multiple valid approaches with tradeoffs) - Business logic (what happens on button click?) - Data requirements unclear (where does data come from?) - Framework choice if not detectable ### Stage 4: Generate Code (Deterministic) **Temperature**: 0.2-0.3 (consistent, deterministic generation) **Generate complete implementation**: - ✅ Pure code files (no markdown formatting) - ✅ Complete implementations (no placeholders/TODOs) - ✅ Working examples with realistic content - ✅ Semantic HTML (button, nav, main, not div soup) - ✅ Tailwind utilities only (no custom CSS) - ✅ Complete imports and setup - ❌ No explanatory comments mixed with code - ❌ No "lazy" shortcuts ("repeat for each item") **Framework-specific patterns**: **Phoenix LiveView**: ```elixir def component(assigns) do ~H"""
<%= for item <- @items do %>
<%= item.content %>
<% end %>
""" end ``` **React/TypeScript**: ```typescript interface Props { items: Item[]; } export const Component: React.FC = ({ items }) => { return (
{items.map(item => (
{item.content}
))}
); }; ``` **Vue**: ```vue ``` ### Stage 5: Automated Validation (Max 3 Iterations) **Run validation cycle** (repeat up to 3 times): #### 5.1: Compilation Check ```bash # Phoenix: mix compile # React/TypeScript: npm run build or tsc --noEmit # Vue: npm run build ``` **If errors**: Parse output, fix issues, regenerate **If success**: Continue to next check #### 5.2: Structure Validation Check: - ✅ Component hierarchy makes sense - ✅ Responsive breakpoints applied (mobile-first) - ✅ Semantic HTML used (not div soup) - ✅ Design system patterns applied **If issues**: Note problems, regenerate with corrections #### 5.3: Basic Accessibility Check Check: - ✅ Semantic elements (`