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.
This commit is contained in:
YeonGyu-Kim
@@ -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 {
|
||||
|
||||
@@ -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):
|
||||
|
||||
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user