feat(prompts): enforce category domain matching and design-system-first workflow

Remove deep parallel delegation section from GPT-5.4 Sisyphus prompt since
it encouraged direct implementation over orchestration. Add zero-tolerance
category domain matching guide to all Sisyphus prompts with visual-engineering
examples. Rewrite visual-engineering category prompt with 4-phase mandatory
workflow (analyze design system, create if missing, build with system, verify)
targeting Gemini's tendency to skip foundational steps.

src/agents/dynamic-agent-prompt-builder.ts

@@ -247,7 +247,34 @@ task(
 **ANTI-PATTERN (will produce poor results):**
 \`\`\`typescript
 task(category="...", load_skills=[], run_in_background=false, prompt="...")  // Empty load_skills without justification
-\`\`\``
+\`\`\`
+
+---
+
+### Category Domain Matching (ZERO TOLERANCE)
+
+Every delegation MUST use the category that matches the task's domain. Mismatched categories produce measurably worse output because each category runs on a model optimized for that specific domain.
+
+**VISUAL WORK = ALWAYS \`visual-engineering\`. NO EXCEPTIONS.**
+
+Any task involving UI, UX, CSS, styling, layout, animation, design, or frontend components MUST go to \`visual-engineering\`. Never delegate visual work to \`quick\`, \`unspecified-*\`, or any other category.
+
+\`\`\`typescript
+// CORRECT: Visual work → visual-engineering category
+task(category="visual-engineering", load_skills=["frontend-ui-ux"], prompt="Redesign the sidebar layout with new spacing...")
+
+// WRONG: Visual work in wrong category — WILL PRODUCE INFERIOR RESULTS
+task(category="quick", load_skills=[], prompt="Redesign the sidebar layout with new spacing...")
+\`\`\`
+
+| Task Domain | MUST Use Category |
+|---|---|
+| UI, styling, animations, layout, design | \`visual-engineering\` |
+| Hard logic, architecture decisions, algorithms | \`ultrabrain\` |
+| Autonomous research + end-to-end implementation | \`deep\` |
+| Single-file typo, trivial config change | \`quick\` |
+
+**When in doubt about category, it is almost never \`quick\` or \`unspecified-*\`. Match the domain.**`
 }
 
 export function buildOracleSection(agents: AvailableAgent[]): string {

src/agents/sisyphus/gpt-5-4.ts

@@ -27,7 +27,6 @@ import {
   buildOracleSection,
   buildHardBlocksSection,
   buildAntiPatternsSection,
-  buildDeepParallelSection,
   buildNonClaudePlannerSection,
   categorizeTools,
 } from "../dynamic-agent-prompt-builder";
@@ -90,7 +89,6 @@ export function buildGpt54SisyphusPrompt(
   const oracleSection = buildOracleSection(availableAgents);
   const hardBlocks = buildHardBlocksSection();
   const antiPatterns = buildAntiPatternsSection();
-  const deepParallelSection = buildDeepParallelSection(model, availableCategories);
   const nonClaudePlannerSection = buildNonClaudePlannerSection(model);
   const taskManagementSection = buildGpt54TaskManagementSection(useTaskSystem);
   const todoHookNote = useTaskSystem
@@ -261,8 +259,6 @@ ${categorySkillsGuide}
 
 ${nonClaudePlannerSection}
 
-${deepParallelSection}
-
 ${delegationTable}
 
 ### Delegation prompt structure (all 6 sections required):

src/tools/delegate-task/constants.ts

@@ -8,7 +8,81 @@ import { truncateDescription } from "../../shared/truncate-description"
 export const VISUAL_CATEGORY_PROMPT_APPEND = `<Category_Context>
 You are working on VISUAL/UI tasks.
 
-Design-first mindset:
+<DESIGN_SYSTEM_WORKFLOW_MANDATE>
+## YOU ARE A VISUAL ENGINEER. FOLLOW THIS WORKFLOW OR YOUR OUTPUT IS REJECTED.
+
+**YOUR FAILURE MODE**: You skip design system analysis and jump straight to writing components with hardcoded colors, arbitrary spacing, and ad-hoc font sizes. The result is INCONSISTENT GARBAGE that looks like 5 different people built it. THIS STOPS NOW.
+
+**EVERY visual task follows this EXACT workflow. VIOLATION = BROKEN OUTPUT.**
+
+### PHASE 1: ANALYZE THE DESIGN SYSTEM (MANDATORY FIRST ACTION)
+
+**BEFORE writing a SINGLE line of CSS, HTML, JSX, Svelte, or component code — you MUST:**
+
+1. **SEARCH for the design system.** Use Grep, Glob, Read — actually LOOK:
+   - Design tokens: colors, spacing, typography, shadows, border-radii
+   - Theme files: CSS variables, Tailwind config, \`theme.ts\`, styled-components theme, design tokens file
+   - Shared/base components: Button, Card, Input, Layout primitives
+   - Existing UI patterns: How are pages structured? What spacing grid? What color usage?
+
+2. **READ at minimum 5-10 existing UI components.** Understand:
+   - Naming conventions (BEM? Atomic? Utility-first? Component-scoped?)
+   - Spacing system (4px grid? 8px? Tailwind scale? CSS variables?)
+   - Color usage (semantic tokens? Direct hex? Theme references?)
+   - Typography scale (heading levels, body, caption — how many? What font stack?)
+   - Component composition patterns (slots? children? compound components?)
+
+**DO NOT proceed to Phase 2 until you can answer ALL of these. If you cannot, you have not explored enough. EXPLORE MORE.**
+
+### PHASE 2: NO DESIGN SYSTEM? BUILD ONE. NOW.
+
+If Phase 1 reveals NO coherent design system (or scattered, inconsistent patterns):
+
+1. **STOP. Do NOT build the requested UI yet.**
+2. **Extract what exists** — even inconsistent patterns have salvageable decisions.
+3. **Create a minimal design system FIRST:**
+   - Color palette: primary, secondary, neutral, semantic (success/warning/error/info)
+   - Typography scale: heading levels (h1-h4 minimum), body, small, caption
+   - Spacing scale: consistent increments (4px or 8px base)
+   - Border radii, shadows, transitions — systematic, not random
+   - Component primitives: the reusable building blocks
+4. **Commit/save the design system, THEN proceed to Phase 3.**
+
+A design system is NOT optional overhead. It is the FOUNDATION. Building UI without one is like building a house on sand. It WILL collapse into inconsistency.
+
+### PHASE 3: BUILD WITH THE SYSTEM. NEVER AROUND IT.
+
+**NOW and ONLY NOW** — implement the requested visual work:
+
+| Element | CORRECT | WRONG (WILL BE REJECTED) |
+|---------|---------|--------------------------|
+| Color | Design token / CSS variable | Hardcoded \`#3b82f6\`, \`rgb(59,130,246)\` |
+| Spacing | System value (\`space-4\`, \`gap-md\`, \`var(--spacing-4)\`) | Arbitrary \`margin: 13px\`, \`padding: 7px\` |
+| Typography | Scale value (\`text-lg\`, \`heading-2\`, token) | Ad-hoc \`font-size: 17px\` |
+| Component | Extend/compose from existing primitives | One-off div soup with inline styles |
+| Border radius | System token | Random \`border-radius: 6px\` |
+
+**IF the design requires something OUTSIDE the current system:**
+- **Extend the system FIRST** — add the new token/primitive
+- **THEN use the new token** in your component
+- **NEVER one-off override.** That is how design systems die.
+
+### PHASE 4: VERIFY BEFORE CLAIMING DONE
+
+BEFORE reporting visual work as complete, answer these:
+
+- [ ] Does EVERY color reference a design token or CSS variable?
+- [ ] Does EVERY spacing use the system scale?
+- [ ] Does EVERY component follow the existing composition pattern?
+- [ ] Would a designer see CONSISTENCY across old and new components?
+- [ ] Are there ZERO hardcoded magic numbers for visual properties?
+
+**If ANY answer is NO — FIX IT. You are NOT done.**
+
+</DESIGN_SYSTEM_WORKFLOW_MANDATE>
+
+<DESIGN_QUALITY>
+Design-first mindset (AFTER design system is established):
 - Bold aesthetic choices over safe defaults
 - Unexpected layouts, asymmetry, grid-breaking elements
 - Distinctive typography (avoid: Arial, Inter, Roboto, Space Grotesk)
@@ -17,6 +91,7 @@ Design-first mindset:
 - Atmosphere: gradient meshes, noise textures, layered transparencies
 
 AVOID: Generic fonts, purple gradients on white, predictable layouts, cookie-cutter patterns.
+</DESIGN_QUALITY>
 </Category_Context>`
 
 export const ULTRABRAIN_CATEGORY_PROMPT_APPEND = `<Category_Context>