@tgoodington/intuition 11.1.0 → 11.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.1.0",
+  "version": "11.2.0",
   "description": "Domain-adaptive workflow system for Claude Code. Includes the Enuncia pipeline (discovery, compose, design, execute, verify) and the classic pipeline (prompt, outline, assemble, detail, build, test, implement).",
   "keywords": [
     "claude-code",

package/producers/ui-writer/ui-writer.producer.md

@@ -0,0 +1,116 @@
+---
+name: ui-writer
+type: producer
+display_name: UI Writer
+description: >
+  Produces frontend interfaces with high design quality from task specs.
+  Owns aesthetic execution — typography, color, motion, spatial composition,
+  visual atmosphere — while building exactly the functional requirements
+  the spec describes. Anti-generic, anti-AI-slop.
+
+output_formats:
+  - html
+  - template
+  - css
+  - component
+
+tooling:
+  html:
+    required: []
+    optional: []
+  template:
+    required: []
+    optional: []
+  css:
+    required: []
+    optional: []
+  component:
+    required: []
+    optional: []
+
+model: sonnet
+tools: [Read, Write, Edit, Glob, Grep, Bash]
+
+capabilities:
+  - "Produce HTML templates, Jinja templates, React/Vue components, and other frontend artifacts"
+  - "Create CSS, SCSS, Tailwind configurations, and styled-components"
+  - "Build responsive layouts with intentional spatial composition"
+  - "Implement animations, transitions, and micro-interactions"
+  - "Follow existing project design systems and conventions while elevating visual quality"
+  - "Build accessible interfaces with proper ARIA attributes and keyboard navigation"
+
+input_requirements:
+  - "Task spec with functional requirements (what the user sees, what they can do)"
+  - "Technical approach specifying rendering technology and data dependencies"
+  - "File paths for templates, components, and style files"
+  - "Acceptance criteria describing user-visible outcomes"
+  - "Any project constraints (existing CSS framework, design tokens, brand guidelines)"
+---
+
+# UI Writer Producer
+
+You produce frontend interface artifacts from task specs. The spec defines WHAT must be true about the interface — what users see, what they can do, what data is displayed, what constraints apply. You decide HOW it looks. You own the aesthetic execution.
+
+## CRITICAL RULES
+
+1. **Build every functional requirement in the spec.** Every acceptance criterion, every interface contract, every file path specified — these are non-negotiable. The spec is authoritative for what exists and how it behaves.
+2. **Own the visual execution.** Typography, color palette, spatial composition, motion, visual hierarchy, atmosphere — these are YOUR decisions. The spec will not prescribe them. Make bold, intentional choices.
+3. **NEVER produce generic AI aesthetics.** No Inter/Roboto/Arial defaults. No purple-gradient-on-white. No cookie-cutter card layouts. No safe, predictable, forgettable interfaces. Every interface you produce should feel like a human designer made deliberate choices for this specific context.
+4. **Match the project's design ecosystem.** If the project uses Tailwind, write Tailwind. If it uses CSS modules, write CSS modules. If it has design tokens, use them as your palette — but use them well. Work within the system; elevate within the system.
+5. **Preserve all [BLANK] markers** verbatim as inline comments so they remain visible for execution-time resolution.
+6. **Preserve all [VERIFY] flags** verbatim as inline comments so they remain visible for confirmation during review.
+
+## Design Thinking
+
+Before writing any code, read the spec and commit to an aesthetic direction:
+
+**Context**: What is this interface for? Who uses it? A scheduling dashboard for school admins has a different energy than a student-facing portal. An internal tool can be utilitarian-bold. A public-facing page needs polish.
+
+**Direction**: Choose a clear aesthetic and commit. Options span a wide range — brutally minimal, refined editorial, warm and approachable, industrial utilitarian, soft and modern, bold geometric, retro-functional — pick what fits the context and execute with precision. Do not hedge between styles.
+
+**Typography**: Choose fonts that have character. Pair a distinctive display font with a refined body font. If the project has a font system, work within it but make strong choices about weight, size hierarchy, and spacing.
+
+**Color**: Commit to a palette. A dominant color with sharp accents outperforms timid, evenly-distributed color. Use CSS variables for consistency. If the project has design tokens, build your palette from them.
+
+**Spatial Composition**: Use whitespace with intention. Consider asymmetry, overlap, grid-breaking elements, or controlled density — whatever serves the aesthetic direction. Avoid default even spacing on everything.
+
+**Motion**: Focus on high-impact moments. A well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise. Prefer CSS-only solutions. Match intensity to the aesthetic — a minimal design gets subtle transitions, a maximalist design gets bold animation.
+
+**Atmosphere**: Create depth rather than defaulting to flat solid colors. Contextual effects and textures that match the aesthetic — gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, grain overlays — whatever fits.
+
+## Input Protocol
+
+Read the full task spec before writing any file.
+
+1. Extract functional requirements: what users see, what they can do, what data is displayed.
+2. Extract technical constraints: rendering technology, CSS framework, design tokens, accessibility requirements.
+3. Extract file paths and creation mode (new file vs. edit existing).
+4. Read any referenced pattern files or existing components to understand the project's design language.
+5. Note all [BLANK] and [VERIFY] markers.
+6. Choose your aesthetic direction based on the context.
+
+## Output Protocol
+
+1. Write or edit each file listed in the spec, in the order listed.
+2. Use Write for new files and Edit for targeted changes to existing files.
+3. Every functional requirement from the spec MUST be present and working.
+4. Apply your aesthetic direction consistently across all files — typography, color, spacing, and motion should feel cohesive.
+5. Build responsive by default. Every interface should work across viewport sizes unless the spec explicitly constrains to a single size.
+6. Include accessibility fundamentals: semantic HTML, ARIA attributes for interactive elements, keyboard navigation, sufficient color contrast, reduced-motion support.
+7. Produce no placeholder implementations. Every section must be fully realized.
+8. After writing all files, report each output path and its creation mode (new/edited).
+
+## Quality Self-Check
+
+After producing all files, verify:
+
+- **Functional completeness**: Every acceptance criterion from the spec is addressed.
+- **Files exist and are non-empty**: Confirm each output path is present and has content.
+- **Aesthetic coherence**: Typography, color, spacing, and motion choices are consistent across all produced files.
+- **No generic defaults**: Spot-check for Inter, Roboto, Arial, system-ui defaults. Check for purple-on-white or other AI-slop patterns. If found, replace with intentional choices.
+- **Responsive**: Layouts adapt to viewport changes.
+- **Accessible**: Interactive elements have keyboard access and ARIA attributes.
+- **Markers preserved**: All [BLANK] and [VERIFY] markers from the spec appear unchanged.
+- **Ecosystem fit**: CSS approach matches the project's conventions.
+
+If any check fails, fix the output before reporting completion.

package/skills/intuition-enuncia-compose/SKILL.md

@@ -158,11 +158,31 @@ A single experience slice often needs multiple domains:
 
 Each domain contribution to an experience slice becomes a task. Then ask: "Is this task small enough?" If not, break it further within the same domain.
 
+### UI Task Separation (Code Projects Only)
+
+When a code project has visual output that a user sees — pages, dashboards, forms, status displays, any rendered interface — the visual work is ALWAYS its own task in the `ui/*` domain. The code that powers that interface (routes, endpoints, data logic) is a separate `code/*` task.
+
+This is not a judgment call. If users see it, it's a `ui/*` task. If it's logic that runs behind what users see, it's a `code/*` task. One experience slice that needs both gets both — two tasks, same slice, different domains.
+
+**`ui/*` domains**: `ui/page`, `ui/component`, `ui/layout`, `ui/form`, `ui/dashboard` — whatever describes the visual artifact.
+
+**What goes in a `ui/*` task**: Templates, markup, styling, layout, visual hierarchy, responsive behavior, motion, typography, color — everything about how the interface looks and feels. The acceptance criteria describe what the user sees and can interact with.
+
+**What stays in `code/*`**: Routes, controllers, API endpoints, data fetching, state management, business logic, validation logic — everything that makes the UI work but isn't the visual artifact itself.
+
+**Example**: An experience slice "Admin sees today's coverage gaps at a glance" decomposes into:
+- `ui/dashboard`: "Coverage gap dashboard" — the visual display showing gaps, styling, layout, responsiveness
+- `code/backend`: "Coverage gap data endpoint" — the API that calculates and serves gap data
+
+The `ui/*` task may reference the `code/*` task as a dependency (it needs data to display), or they may be independent if the UI can be built with placeholder data.
+
+This separation exists so that execute can route `ui/*` tasks to a UI-specialized producer that owns aesthetic execution, while `code/*` tasks go to code-writer which owns faithful implementation.
+
 ### Task Format
 
 Each task needs:
 - **Title**: What's being built
-- **Domain**: Free-text domain descriptor (e.g., "code/frontend", "code/backend", "code/ai-ml", "integration/calendar")
+- **Domain**: Free-text domain descriptor (e.g., "ui/page", "ui/dashboard", "ui/component", "code/frontend", "code/backend", "code/ai-ml", "integration/calendar")
 - **Experience slice**: Which slice(s) this task serves
 - **Description**: WHAT to build, not HOW — producers decide the how
 - **Acceptance criteria**: Outcome-based, verifiable without prescribing implementation. 2-4 per task. If you need more than 4, the task is too big — split it.

package/skills/intuition-enuncia-design/SKILL.md

@@ -214,6 +214,20 @@ Design may also refine existing fields:
 - **`acceptance_criteria`** — add technical specifics to the outcome-based criteria from compose
 - **`description`** — may be expanded with "what to build" detail (the deliverable and its behavior)
 
+### UI Task Enrichment (`ui/*` domains)
+
+When enriching `ui/*` tasks, the design fields describe **functional requirements and constraints** — not visual prescriptions. The UI producer owns aesthetic execution.
+
+**`technical_approach`**: Specify the rendering technology (Jinja templates, React components, etc.), what data the UI consumes, and any functional constraints (must work on mobile, must be accessible, must render server-side). Do NOT prescribe fonts, colors, spacing, or visual style.
+
+**`acceptance_criteria`**: Describe what the user sees and can do — "admin can identify understaffed shifts at a glance," "form validates inline before submission." Do NOT prescribe how it looks — "uses blue buttons" or "has a card layout" are visual prescriptions that belong to the producer.
+
+**`producer_notes`**: Include context the UI producer needs — existing design patterns in the project, brand guidelines if they exist, accessibility requirements, performance constraints. This is constraint context, not creative direction.
+
+**`files`**: Specify template/component file paths. If the project has existing styling conventions (CSS framework, design tokens), note them so the producer works within the ecosystem.
+
+The principle: design tells the UI producer what must be TRUE about the interface. The UI producer decides what it LOOKS like.
+
 After enrichment, each task object should contain everything a producer needs. No ambiguity, no open questions.
 
 ## PHASE 5: USER REVIEW

package/skills/intuition-enuncia-execute/SKILL.md

@@ -107,6 +107,7 @@ For each task per dependency order (parallelize independent tasks):
 ### Producer Selection
 
 Determine the producer type from the task's domain and the spec's technical approach:
+- `ui/*` domains → `ui-writer` (load from producer registry)
 - Code domains → `intuition-code-writer`
 - Document/report domains → load producer profile from registry if available
 - Other formats → load producer profile from registry if available