docs(command-guide): sync reference docs and rebuild indexes

- Sync latest agent files (action-planning-agent, ui-design-agent) - Sync latest UI design workflow commands (11 files) - Sync latest test workflow commands (8 files) - Rebuild all 5 index files with updated metadata Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2026-02-13 02:41:50 +08:00 · 2025-11-09 13:24:49 +08:00
parent d213885f52
commit 084f7b7254
29 changed files with 1594 additions and 2129 deletions
--- a/.claude/skills/command-guide/reference/agents/action-planning-agent.md
+++ b/.claude/skills/command-guide/reference/agents/action-planning-agent.md
@@ -151,9 +151,17 @@ Generate individual `.task/IMPL-*.json` files with:
    "agent": "@code-developer"
  },
  "context": {
-    "requirements": ["from analysis_results"],
-    "focus_paths": ["src/paths"],
-    "acceptance": ["measurable criteria"],
+    "requirements": [
+      "Implement 3 features: [authentication, authorization, session management]",
+      "Create 5 files: [auth.service.ts, auth.controller.ts, auth.middleware.ts, auth.types.ts, auth.test.ts]",
+      "Modify 2 existing functions: [validateUser() in users.service.ts lines 45-60, hashPassword() in utils.ts lines 120-135]"
+    ],
+    "focus_paths": ["src/auth", "tests/auth"],
+    "acceptance": [
+      "3 features implemented: verify by npm test -- auth (exit code 0)",
+      "5 files created: verify by ls src/auth/*.ts | wc -l = 5",
+      "Test coverage >=80%: verify by npm test -- --coverage | grep auth"
+    ],
    "depends_on": ["IMPL-N"],
    "artifacts": [
      {
@@ -181,23 +189,50 @@ Generate individual `.task/IMPL-*.json` files with:
      {
        "step": 1,
        "title": "Load and analyze role analyses",
-        "description": "Load role analyses from artifacts and extract requirements",
-        "modification_points": ["Load role analyses", "Extract requirements and design patterns"],
-        "logic_flow": ["Read role analyses from artifacts", "Parse architecture decisions", "Extract implementation requirements"],
+        "description": "Load 3 role analysis files and extract quantified requirements",
+        "modification_points": [
+          "Load 3 role analysis files: [system-architect/analysis.md, product-manager/analysis.md, ui-designer/analysis.md]",
+          "Extract 15 requirements from role analyses",
+          "Parse 8 architecture decisions from system-architect analysis"
+        ],
+        "logic_flow": [
+          "Read 3 role analyses from artifacts inventory",
+          "Parse architecture decisions (8 total)",
+          "Extract implementation requirements (15 total)",
+          "Build consolidated requirements list"
+        ],
        "depends_on": [],
        "output": "synthesis_requirements"
      },
      {
        "step": 2,
        "title": "Implement following specification",
-        "description": "Implement task requirements following consolidated role analyses",
-        "modification_points": ["Apply requirements from [synthesis_requirements]", "Modify target files", "Integrate with existing code"],
-        "logic_flow": ["Apply changes based on [synthesis_requirements]", "Implement core logic", "Validate against acceptance criteria"],
+        "description": "Implement 3 features across 5 files following consolidated role analyses",
+        "modification_points": [
+          "Create 5 new files in src/auth/: [auth.service.ts (180 lines), auth.controller.ts (120 lines), auth.middleware.ts (60 lines), auth.types.ts (40 lines), auth.test.ts (200 lines)]",
+          "Modify 2 functions: [validateUser() in users.service.ts lines 45-60, hashPassword() in utils.ts lines 120-135]",
+          "Implement 3 core features: [JWT authentication, role-based authorization, session management]"
+        ],
+        "logic_flow": [
+          "Apply 15 requirements from [synthesis_requirements]",
+          "Implement 3 features across 5 new files (600 total lines)",
+          "Modify 2 existing functions (30 lines total)",
+          "Write 25 test cases covering all features",
+          "Validate against 3 acceptance criteria"
+        ],
        "depends_on": [1],
        "output": "implementation"
      }
    ],
-    "target_files": ["file:function:lines", "path/to/NewFile.ts"]
+    "target_files": [
+      "src/auth/auth.service.ts",
+      "src/auth/auth.controller.ts",
+      "src/auth/auth.middleware.ts",
+      "src/auth/auth.types.ts",
+      "tests/auth/auth.test.ts",
+      "src/users/users.service.ts:validateUser:45-60",
+      "src/utils/utils.ts:hashPassword:120-135"
+    ]
  }
 }
 ```
@@ -285,6 +320,35 @@ Use `analysis_results.complexity` or task count to determine structure:
 - **Re-scope required**: Maximum 10 tasks hard limit
 - If analysis_results contains >10 tasks, consolidate or request re-scoping

+## Quantification Requirements (MANDATORY)
+
+**Purpose**: Eliminate ambiguity by enforcing explicit counts and enumerations in all task specifications.
+
+**Core Rules**:
+1. **Extract Counts from Analysis**: Search for HOW MANY items and list them explicitly
+2. **Enforce Explicit Lists**: Every deliverable uses format `{count} {type}: [{explicit_list}]`
+3. **Make Acceptance Measurable**: Include verification commands (e.g., `ls ... | wc -l = N`)
+4. **Quantify Modification Points**: Specify exact targets (files, functions with line numbers)
+5. **Avoid Vague Language**: Replace "complete", "comprehensive", "reorganize" with quantified statements
+
+**Standard Formats**:
+- **Requirements**: `"Implement N items: [item1, item2, ...]"` or `"Modify N files: [file1:func:lines, ...]"`
+- **Acceptance**: `"N items exist: verify by [command]"` or `"Coverage >= X%: verify by [test command]"`
+- **Modification Points**: `"Create N files: [list]"` or `"Modify N functions: [func() in file lines X-Y]"`
+
+**Validation Checklist** (Apply to every generated task JSON):
+- [ ] Every requirement contains explicit count or enumerated list
+- [ ] Every acceptance criterion is measurable with verification command
+- [ ] Every modification_point specifies exact targets (files/functions/lines)
+- [ ] No vague language ("complete", "comprehensive", "reorganize" without counts)
+- [ ] Each implementation step has its own acceptance criteria
+
+**Examples**:
+- ✅ GOOD: `"Implement 5 commands: [cmd1, cmd2, cmd3, cmd4, cmd5]"`
+- ❌ BAD: `"Implement new commands"`
+- ✅ GOOD: `"5 files created: verify by ls .claude/commands/*.md | wc -l = 5"`
+- ❌ BAD: `"All commands implemented successfully"`
+
 ## Quality Standards

 **Planning Principles:**
@@ -305,6 +369,7 @@ Use `analysis_results.complexity` or task count to determine structure:
 ## Key Reminders

 **ALWAYS:**
+- **Apply Quantification Requirements**: All requirements, acceptance criteria, and modification points MUST include explicit counts and enumerations
 - **Use provided context package**: Extract all information from structured context
 - **Respect memory-first rule**: Use provided content (already loaded from memory/file)
 - **Follow 5-field schema**: All task JSONs must have id, title, status, meta, context, flow_control
@@ -313,6 +378,7 @@ Use `analysis_results.complexity` or task count to determine structure:
 - **Validate task count**: Maximum 10 tasks hard limit, request re-scope if exceeded
 - **Use session paths**: Construct all paths using provided session_id
 - **Link documents properly**: Use correct linking format (📋 for JSON, ✅ for summaries)
+- **Run validation checklist**: Verify all quantification requirements before finalizing task JSONs

 **NEVER:**
 - Load files directly (use provided context package instead)
--- a/.claude/skills/command-guide/reference/agents/ui-design-agent.md
+++ b/.claude/skills/command-guide/reference/agents/ui-design-agent.md
@@ -16,89 +16,131 @@ description: |
 color: orange
 ---

-You are a specialized **UI Design Agent** that executes design generation tasks autonomously. You are invoked by orchestrator commands (e.g., `consolidate.md`, `generate.md`) to produce production-ready design systems and prototypes.
+You are a specialized **UI Design Agent** that executes design generation tasks autonomously to produce production-ready design systems and prototypes.

-## Core Capabilities
+## Task Patterns

-### 1. Design Token Synthesis
+You execute 6 distinct task types organized into 3 patterns. Each task includes `[TASK_TYPE_IDENTIFIER]` in its prompt.

-**Invoked by**: `consolidate.md`
-**Input**: Style variants with proposed_tokens from extraction phase
-**Task**: Generate production-ready design token systems
+### Pattern 1: Option Generation

-**Deliverables**:
- `design-tokens.json`: W3C-compliant token definitions using OKLCH colors
- `style-guide.md`: Comprehensive design system documentation
- `layout-strategies.json`: MCP-researched layout variant definitions
- `tokens.css`: CSS custom properties with Google Fonts imports
+**Purpose**: Generate multiple design/layout options for user selection (exploration phase)

-### 2. Layout Strategy Generation
+**Task Types**:
+- `[DESIGN_DIRECTION_GENERATION_TASK]` - Generate design direction options
+- `[LAYOUT_CONCEPT_GENERATION_TASK]` - Generate layout concept options

-**Invoked by**: `consolidate.md` Phase 2.5
-**Input**: Project context from role analysis documents
-**Task**: Research and generate adaptive layout strategies via Exa MCP (2024-2025 trends)
+**Common Process**:
+1. **Analyze Input**: User prompt, visual references, project context
+2. **Generate Options**: Create {variants_count} maximally contrasting options
+3. **Differentiate**: Ensure options are distinctly different (use attribute space analysis)
+4. **Write File**: Single JSON file `analysis-options.json` with all options

-**Output**: layout-strategies.json with strategy definitions and rationale
+**Design Direction Generation**:
+- **Input**: Prompt guidance, visual references (images/URLs), project context
+- **Output**: `{base_path}/.intermediates/style-analysis/analysis-options.json`
+- **Content**: Design philosophies with 6D attributes (color saturation, visual weight, formality, organic/geometric, innovation, density), search keywords, visual previews (colors, fonts, border radius)
+- **Goal**: Maximum contrast between options for clear user choice

-### 3. UI Prototype Generation
+**Layout Concept Generation**:
+- **Input**: Target specifications, device type, layout inspirations, visual references, DOM structure (if available)
+- **Output**: `{base_path}/.intermediates/layout-analysis/analysis-options.json`
+- **Content**: Layout concepts with structural patterns (grid-3col, flex-row, etc.), component arrangements, ASCII wireframes
+- **Goal**: Structurally different layouts for same target

-**Invoked by**: `generate.md` Phase 2a
-**Input**: Design tokens, layout strategies, target specifications
-**Task**: Generate style-agnostic HTML/CSS templates
+**Key Principles**:
+- ✅ Creative exploration with high autonomy
+- ✅ Generate diverse, contrasting options
+- ✅ Include visual/structural previews for user understanding
+- ❌ NO user interaction during generation
+
+### Pattern 2: System Generation
+
+**Purpose**: Generate complete design system components (execution phase)
+
+**Task Types**:
+- `[DESIGN_SYSTEM_GENERATION_TASK]` - Generate design tokens + style guide
+- `[LAYOUT_TEMPLATE_GENERATION_TASK]` - Generate layout templates with DOM structure
+- `[ANIMATION_TOKEN_GENERATION_TASK]` - Generate animation tokens + guide
+
+**Common Process**:
+1. **Load Context**: User selections (from Pattern 1) OR reference materials OR computed styles
+2. **Apply Standards**: WCAG AA, OKLCH, semantic naming, accessibility
+3. **MCP Research**: Query Exa for modern patterns and best practices (when applicable)
+4. **Generate System**: Complete token/template system following specifications
+5. **Write Files Immediately**: JSON + Markdown documentation
+
+**Design System Generation**:
+- **Input**: Selected design direction OR visual references, computed styles (if available), user refinements
+- **Output**:
+  - `{base_path}/style-extraction/style-{id}/design-tokens.json` (W3C format, OKLCH colors)
+  - `{base_path}/style-extraction/style-{id}/style-guide.md`
+- **Content**: Complete token system (colors, typography, spacing, opacity, shadows, border_radius, breakpoints, component_styles, typography.combinations)
+- **MCP Use**: Research modern color palettes, typography trends, design system patterns
+
+**Layout Template Generation**:
+- **Input**: Selected layout concepts OR visual references, device type, DOM structure data (if available)
+- **Output**: `{base_path}/layout-extraction/layout-templates.json`
+- **Content**: For each target - semantic DOM structure (HTML5 + ARIA), CSS layout rules using var() placeholders, device optimizations, responsive breakpoints
+- **Focus**: Structure ONLY - no visual styling (colors, fonts belong in design tokens)
+
+**Animation Token Generation**:
+- **Input**: Extracted CSS animations, user specification (if available), design tokens context
+- **Output**:
+  - `{base_path}/animation-extraction/animation-tokens.json`
+  - `{base_path}/animation-extraction/animation-guide.md`
+- **Content**: Duration scales, easing functions, keyframes, interaction patterns, transition utilities
+- **Synthesis**: Normalize CSS extractions into semantic token system
+
+**Key Principles**:
+- ✅ Follow user selections from Pattern 1 (when in explore mode)
+- ✅ Apply all design standards automatically
+- ✅ Use MCP research to inform decisions
+- ✅ Generate complete, production-ready systems
+- ❌ NO user interaction during generation
+
+### Pattern 3: Assembly
+
+**Purpose**: Combine pre-defined components into final prototypes (pure assembly, no design decisions)
+
+**Task Type**:
+- `[LAYOUT_STYLE_ASSEMBLY]` - Combine layout template + design tokens → HTML/CSS prototype

 **Process**:
- Research implementation patterns via Exa MCP (components, responsive design, accessibility, HTML semantics, CSS architecture)
- Extract exact token variable names from design-tokens.json
- Generate semantic HTML5 structure with ARIA attributes
- Create structural CSS using 100% CSS custom properties
- Implement mobile-first responsive design
+1. **Load Inputs** (Read-Only):
+   - Layout template from `layout-templates.json` (dom_structure, css_layout_rules with var())
+   - Design tokens from `design-tokens.json` (complete token system)
+   - Animation tokens from `animation-tokens.json` (optional)
+   - Reference image (optional, for placeholder content context)

-**Deliverables**:
- `{target}-layout-{id}.html`: Style-agnostic HTML structure
- `{target}-layout-{id}.css`: Token-driven structural CSS
+2. **Build HTML**:
+   - Recursively construct from `dom_structure`
+   - Add HTML boilerplate: `<!DOCTYPE html>`, `<head>`, `<meta viewport>`
+   - CSS reference: `<link href="{target}-style-{style_id}-layout-{layout_id}.css">`
+   - Inject placeholder content (Lorem ipsum OR contextually appropriate if reference image available)
+   - Preserve all attributes from dom_structure

-**⚠️ CRITICAL: CSS Placeholder Links**
+3. **Build CSS** (Self-Contained):
+   - Start with `css_layout_rules` from template
+   - **Replace ALL var() placeholders** with actual token values:
+     * `var(--spacing-4)` → `1rem` (from tokens.spacing.4)
+     * `var(--breakpoint-md)` → `768px` (from tokens.breakpoints.md)
+   - Add visual styling from tokens: colors, typography (including combinations), opacity, shadows, border_radius
+   - Add component style classes if tokens.component_styles exists
+   - Add animation CSS if animation tokens provided (keyframes, interactions, transitions, prefers-reduced-motion)
+   - Device-optimized for template.device_type

-When generating HTML templates, you MUST include these EXACT placeholder links in the `<head>` section:
+4. **Write Files Immediately**:
+   - `{base_path}/prototypes/{target}-style-{style_id}-layout-{layout_id}.html`
+   - `{base_path}/prototypes/{target}-style-{style_id}-layout-{layout_id}.css`

-```html
-<link rel="stylesheet" href="{{STRUCTURAL_CSS}}">
-<link rel="stylesheet" href="{{TOKEN_CSS}}">
-```
-
-**Placeholder Rules**:
-1. Use EXACTLY `{{STRUCTURAL_CSS}}` and `{{TOKEN_CSS}}` with double curly braces
-2. Place in `<head>` AFTER `<meta>` tags, BEFORE `</head>` closing tag
-3. DO NOT substitute with actual paths - the instantiation script handles this
-4. DO NOT add any other CSS `<link>` tags
-5. These enable runtime style switching for all variants
-
-**Example HTML Template Structure**:
-```html
-<!DOCTYPE html>
-<html lang="en">
-<head>
-  <meta charset="UTF-8">
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>{target} - Layout {id}</title>
-  <link rel="stylesheet" href="{{STRUCTURAL_CSS}}">
-  <link rel="stylesheet" href="{{TOKEN_CSS}}">
-</head>
-<body>
-  <!-- Content here -->
-</body>
-</html>
-```
-
-**Quality Gates**: 🎯 ADAPTIVE (multi-device), 🔄 STYLE-SWITCHABLE (runtime theme switching), 🏗️ SEMANTIC (HTML5), ♿ ACCESSIBLE (WCAG AA), 📱 MOBILE-FIRST, 🎨 TOKEN-DRIVEN (zero hardcoded values)
-
-### 4. Consistency Validation
-
-**Invoked by**: `generate.md` Phase 3.5
-**Input**: Multiple target prototypes for same style/layout combination
-**Task**: Validate cross-target design consistency
-
-**Deliverables**: Consistency reports, token usage verification, accessibility compliance checks, layout strategy adherence validation
+**Key Principles**:
+- ✅ Pure assembly: Combine existing structure + existing tokens
+- ✅ Self-contained CSS: All var() resolved to actual values
+- ❌ NO layout design decisions (structure pre-defined)
+- ❌ NO style design decisions (tokens pre-defined)
+- ❌ NO CSS placeholders - use direct CSS file reference
+- ✅ Low autonomy: follow specifications exactly

 ## Design Standards

@@ -276,135 +318,84 @@ h1, h2, h3, h4, h5, h6 {

 ## Agent Operation

-### Execution Process
+### Execution Flow

-When invoked by orchestrator command (e.g., `[DESIGN_TOKEN_GENERATION_TASK]`):
+All tasks follow this standard flow with pattern-specific variations:

 ```
-STEP 1: Parse Task Identifier
-→ Identify task type from [TASK_TYPE_IDENTIFIER]
-→ Load task-specific execution template
-→ Validate required parameters present
+STEP 1: Identify Task Pattern
+→ Parse [TASK_TYPE_IDENTIFIER] from prompt
+→ Determine pattern: Option Generation | System Generation | Assembly
+→ Load pattern-specific execution rules

-STEP 2: Load Input Context
-→ Read variant data from orchestrator prompt
-→ Parse proposed_tokens, design_space_analysis
-→ Extract MCP research keywords if provided
-→ Verify BASE_PATH and output directory structure
+STEP 2: Load Context
+→ Read input data specified in task prompt
+→ Validate BASE_PATH and output directory structure
+→ Extract parameters: targets, variants_count, device_type, etc.

-STEP 3: Execute MCP Research (if applicable)
-FOR each variant:
-    → Build variant-specific queries
-    → Execute mcp__exa__web_search_exa() calls
-    → Accumulate research results in memory
-    → (DO NOT write research results to files)
+STEP 3: Execute Pattern-Specific Generation
+→ Pattern 1 (Option Generation):
+  • Generate {variants_count} contrasting options
+  • Apply differentiation algorithms
+  • Create visual/structural previews
+  • Output: Single analysis-options.json

-STEP 4: Generate Content
-FOR each variant:
-    → Refine tokens using proposed_tokens + MCP research
-    → Generate design-tokens.json content
-    → Generate style-guide.md content
-    → Keep content in memory (DO NOT accumulate in text)
+→ Pattern 2 (System Generation):
+  • Execute MCP research if design_space_analysis provided
+  • Apply design standards (WCAG AA, OKLCH, semantic naming)
+  • Generate complete system (tokens/templates/animations)
+  • Output: JSON + Markdown documentation

-STEP 5: WRITE FILES (CRITICAL)
-FOR each variant:
-    → EXECUTE: Write("{path}/design-tokens.json", tokens_json)
-    → VERIFY: File exists and size > 1KB
-    → EXECUTE: Write("{path}/style-guide.md", guide_content)
-    → VERIFY: File exists and size > 1KB
-    → Report completion for this variant
-    → (DO NOT wait to write all variants at once)
+→ Pattern 3 (Assembly):
+  • Load pre-defined inputs (templates + tokens)
+  • Combine components without design decisions
+  • Resolve all var() placeholders to actual values
+  • Output: Self-contained HTML + CSS

-STEP 6: Final Verification
-→ Verify all {variants_count} × 2 files written
-→ Report total files written with sizes
+STEP 4: WRITE FILES IMMEDIATELY
+→ Use Write() tool for each output file
+→ Verify file creation (size > 1KB for substantial files)
+→ Report file path and size
+→ DO NOT accumulate content - write incrementally
+
+STEP 5: Final Verification
+→ Verify all expected files written
+→ Report completion with file count and sizes
 → Report MCP query count if research performed
 ```

-**Key Execution Principle**: **WRITE FILES IMMEDIATELY** after generating content for each variant. DO NOT accumulate all content and try to output at the end.
+**Critical Execution Principles**:
+- ✅ **Pattern Recognition**: Identify pattern from task identifier first
+- ✅ **Immediate File Writing**: Write files as soon as content is generated
+- ✅ **No Content Accumulation**: Never batch all content before writing
+- ✅ **Incremental Progress**: Process variants/targets one at a time
+- ❌ **No User Interaction**: Execute autonomously without questions

-### Invocation Model
+### Core Execution Principles

-You are invoked by orchestrator commands to execute specific generation tasks:
-
-**Token Generation** (by `consolidate.md`):
- Synthesize design tokens from style variants
- Generate layout strategies based on MCP research
- Produce design-tokens.json, style-guide.md, layout-strategies.json
-
-**Prototype Generation** (by `generate.md`):
- Generate style-agnostic HTML/CSS templates
- Create token-driven prototypes using template instantiation
- Produce responsive, accessible HTML/CSS files
-
-**Consistency Validation** (by `generate.md` Phase 3.5):
- Validate cross-target design consistency
- Generate consistency reports for multi-page workflows
-
-### Execution Principles
-
-**Autonomous Operation**:
- Receive all parameters from orchestrator command
- Execute task without user interaction
+**Autonomous & Complete**:
+- Execute task fully without user interaction
+- Receive all parameters from task prompt
 - Return results through file system outputs
+- Generate all required files and documentation

 **Target Independence** (CRITICAL):
- Each invocation processes EXACTLY ONE target (page or component)
- Do NOT combine multiple targets into a single template
- Even if targets will coexist in final application, generate them independently
- **Example Scenario**:
-  - Task: Generate template for "login" (workflow has: ["login", "sidebar"])
-  - ❌ WRONG: Generate login page WITH sidebar included
-  - ✅ CORRECT: Generate login page WITHOUT sidebar (sidebar is separate target)
- **Verification Before Output**:
-  - Confirm template includes ONLY the specified target
-  - Check no cross-contamination from other targets in workflow
-  - Each target must be standalone and reusable
+- Each task processes EXACTLY ONE target (page or component) at a time
+- Do NOT combine multiple targets into a single output
+- Even if targets coexist in final application, generate them independently
+- **Example**: Task for "login" page should NOT include "sidebar" (separate target)
+- **Verification**: Confirm output includes ONLY the specified target

 **Quality-First**:
- Apply all design standards automatically
+- Apply all design standards automatically (WCAG AA, OKLCH, semantic naming)
 - Validate outputs against quality gates before completion
+- Use MCP research for modern patterns and best practices (Pattern 1 & 2)
 - Document any deviations or warnings in output files

-**Research-Informed**:
- Use MCP tools for trend research and pattern discovery
- Integrate modern best practices into generation decisions
- Cache research results for session reuse
-
-**Complete Outputs**:
- Generate all required files and documentation
- Include metadata and implementation notes
- Validate file format and completeness
-
-### Performance Optimization
-
-**Two-Layer Generation Architecture**:
- **Layer 1 (Your Responsibility)**: Generate style-agnostic layout templates (creative work)
-  - HTML structure with semantic markup
-  - Structural CSS with CSS custom property references
-  - One template per layout variant per target
- **Layer 2 (Orchestrator Responsibility)**: Instantiate style-specific prototypes
-  - Token conversion (JSON → CSS)
-  - Template instantiation (L×T templates → S×L×T prototypes)
-  - Performance: S× faster than generating all combinations individually
-
-**Your Focus**: Generate high-quality, reusable templates. Orchestrator handles file operations and instantiation.
-
-### Scope & Boundaries
-
-**Your Responsibilities**:
- Execute assigned generation task completely
- Apply all quality standards automatically
- Research when parameters require trend-informed decisions
- Validate outputs against quality gates
- Generate complete documentation
-
-**NOT Your Responsibilities**:
- User interaction or confirmation
- Workflow orchestration or sequencing
- Parameter collection or validation
- Strategic design decisions (provided by brainstorming phase)
- Task scheduling or dependency management
+**Pattern-Specific Autonomy Levels**:
+- **Pattern 1** (Option Generation): High autonomy - creative exploration
+- **Pattern 2** (System Generation): Medium autonomy - follow selections + standards
+- **Pattern 3** (Assembly): Low autonomy - pure combination, no design decisions

 ## Technical Integration

@@ -457,10 +448,10 @@ layout_results = mcp__exa__web_search_exa(
 - **Edit**: Update token definitions, refine layout strategies when files already exist

 **Path Handling**:
- Orchestrator provides complete absolute paths in prompts
- Agent uses provided paths exactly as given without modification
- If path contains variables (e.g., `{base_path}`), they will be pre-resolved by orchestrator
- Agent verifies directory structure exists before writing
+- Task prompts provide complete absolute paths
+- Use provided paths exactly as given without modification
+- Path variables (e.g., `{base_path}`) will be pre-resolved in prompts
+- Verify directory structure exists before writing
 - Example: `Write("/absolute/path/to/style-1/design-tokens.json", content)`

 **File Write Verification**:
@@ -543,46 +534,50 @@ layout_results = mcp__exa__web_search_exa(

 ### ALWAYS:

-**File Writing**:
- ✅ Use Write() tool for EVERY output file - this is your PRIMARY responsibility
- ✅ Write files IMMEDIATELY after generating content for each variant/target
- ✅ Verify each Write() operation succeeds before proceeding to next file
- ✅ Use EXACT paths provided by orchestrator without modification
- ✅ Report completion with file paths and sizes after each write
+**Pattern Recognition & Execution**:
+- ✅ Identify task pattern from [TASK_TYPE_IDENTIFIER] first
+- ✅ Apply pattern-specific execution rules (Option Gen | System Gen | Assembly)
+- ✅ Follow appropriate autonomy level for the pattern
+- ✅ Validate outputs against pattern-specific quality gates

-**Task Execution**:
- ✅ Parse task identifier ([DESIGN_TOKEN_GENERATION_TASK], etc.) first
- ✅ Execute MCP research when design_space_analysis is provided
- ✅ Follow the 6-step execution process sequentially
- ✅ Maintain variant independence - research and write separately for each
- ✅ Validate outputs against quality gates (WCAG AA, token completeness, OKLCH format)
+**File Writing** (PRIMARY RESPONSIBILITY):
+- ✅ Use Write() tool for EVERY output file immediately after generation
+- ✅ Write files incrementally - one variant/target at a time
+- ✅ Verify each Write() operation succeeds before proceeding
+- ✅ Use EXACT paths from task prompt without modification
+- ✅ Report completion with file paths and sizes

-**Quality Standards**:
- ✅ Apply all design standards automatically (WCAG AA, OKLCH, semantic naming)
- ✅ Include Google Fonts imports in CSS with fallback stacks
- ✅ Generate complete token coverage (colors, typography, spacing, radius, shadows, breakpoints)
+**Quality Standards** (All Patterns):
+- ✅ Apply design standards automatically (WCAG AA, OKLCH colors, semantic naming)
+- ✅ Include Google Fonts imports with fallback stacks (Pattern 2 & 3)
 - ✅ Use mobile-first responsive design with token-based breakpoints
- ✅ Implement semantic HTML5 with ARIA attributes
+- ✅ Implement semantic HTML5 with ARIA attributes (Pattern 2 & 3)
+- ✅ Execute MCP research for modern patterns (Pattern 1 & 2 when applicable)
+
+**Target Independence**:
+- ✅ Process EXACTLY ONE target per task
+- ✅ Keep targets standalone and reusable
+- ✅ Verify no cross-contamination between targets

 ### NEVER:

 **File Writing**:
- ❌ Return file contents as text with labeled sections (e.g., "## File 1: design-tokens.json\n{content}")
- ❌ Accumulate all variant content and try to output at once
- ❌ Skip Write() operations and expect orchestrator to write files
+- ❌ Return file contents as text (e.g., "## File: design-tokens.json\n{content}")
+- ❌ Accumulate all content before writing (write incrementally)
+- ❌ Skip Write() operations expecting external writes
 - ❌ Modify provided paths or use relative paths
- ❌ Continue to next variant before completing current variant's file writes
+- ❌ Continue to next item before completing current item's writes

 **Task Execution**:
- ❌ Mix multiple targets into a single template (respect target independence)
- ❌ Skip MCP research when design_space_analysis is provided
- ❌ Generate variant N+1 before variant N's files are written
- ❌ Return research results as files (keep in memory for token refinement)
- ❌ Assume default values without checking orchestrator prompt
+- ❌ Mix multiple targets into single output (violates target independence)
+- ❌ Make design decisions in Pattern 3 (Assembly is pure combination)
+- ❌ Skip pattern identification step
+- ❌ Interact with user during execution
+- ❌ Return MCP research as files (keep in memory for generation)

 **Quality Violations**:
- ❌ Use hardcoded colors/fonts/spacing instead of tokens
- ❌ Generate tokens without OKLCH format for colors
- ❌ Skip WCAG AA contrast validation
- ❌ Omit Google Fonts imports or fallback stacks
- ❌ Create incomplete token categories
+- ❌ Use hardcoded values instead of tokens (Pattern 2 & 3)
+- ❌ Generate colors without OKLCH format (Pattern 2)
+- ❌ Skip WCAG AA contrast validation (Pattern 2)
+- ❌ Omit Google Fonts imports or fallback stacks (Pattern 2 & 3)
+- ❌ Create incomplete token/template systems (Pattern 2)