/co-design

name: co-design
description: >
  Only to be triggered by explicit /co-design commands. Parallel task executor that routes frontend/design tasks to Claude CLI print mode for superior design output.

Co-Design: Parallel Task Executor with Design-Mode Routing

You are an Orchestrator for subagents. Use orchestration mode to parse plan files and delegate tasks to parallel subagents using task dependencies, in a loop, until all tasks are completed.

**Key difference from standard parallel-task**: When a task involves **frontend design, styling, UI, or visual work**, you launch it via `claude -p` (print mode) in a background shell instead of using the Task tool. This gives the design agent full CLI capabilities and tool access. All other tasks use normal Task tool subagents.

Task Classification

Before launching each task, classify it as **design** or **standard**:

Design Tasks (route to `claude -p`)

A task is a **design task** if it primarily involves ANY of:

• CSS, SCSS, Tailwind, or any styling
• HTML structure/templates for UI
• React/Vue/Svelte/Angular component **markup and styling**
• Layout, responsive design, grid, flexbox
• Design tokens, theme files, color schemes
• UI component creation (buttons, cards, modals, navbars, etc.)
• Animation, transitions, visual effects
• Accessibility (a11y) related to visual presentation
• Asset management (icons, images, fonts)
• Design system implementation

Standard Tasks (route to Task tool subagent)

Everything else:

• Backend logic, API endpoints, database
• Business logic, services, utilities
• Configuration, tooling, CI/CD
• Testing (unless it's visual/snapshot testing)
• State management, data fetching
• Authentication, authorization

**When in doubt**: If a task mixes both (e.g., "create a form with validation"), route it as a **design task** since it has a UI component.

Process

Step 1: Parse Request

Extract from user request: 1. **Plan file**: The markdown plan to read 2. **Task subset** (optional): Specific task IDs to run

If no subset provided, run the full plan.

Step 2: Read & Parse Plan

1. Find task subsections (e.g., `### T1:` or `### Task 1.1:`) 2. For each task, extract:

• Task ID and name
• **depends_on** list (from `- **depends_on**: [...]`)
• Full content (description, location, acceptance criteria, validation)

3. Build task list 4. **Classify each task** as `design` or `standard` based on the rules above 5. If a task subset was requested, filter the task list to only those IDs and their required dependencies.

Step 3: Launch Tasks

For each **unblocked** task, launch it based on its classification:

For STANDARD tasks → Use Task tool subagent

Launch with:

• **description**: "Implement task [ID]: [name]"
• **prompt**: Use the Task Prompt Template below
• **subagent_type**: "parallel"

For DESIGN tasks → Use `claude -p` in background shell

Construct the exact same prompt you would give a subagent, then launch via Bash:

claude -p "YOUR_PROMPT_HERE" \
  --allowedTools "Bash,Read,Edit,Write,Glob,Grep,WebFetch,WebSearch" \
  --max-turns 50 \
  --output-format text \
  > /tmp/co-design-[TASK_ID]-output.log 2>&1 &

**CRITICAL rules for design task launch:** 1. The prompt content must be IDENTICAL to what you'd give a Task tool subagent (use the same Task Prompt Template) 2. Escape the prompt properly for shell execution - use a heredoc approach:

   claude -p "$(cat <<'PROMPT_EOF'
   [full prompt content here]
   PROMPT_EOF
   )" \
     --allowedTools "Bash,Read,Edit,Write,Glob,Grep,WebFetch,WebSearch" \
     --max-turns 50 \
     --output-format text \
     > /tmp/co-design-[TASK_ID]-output.log 2>&1 &

3. Log output to `/tmp/co-design-[TASK_ID]-output.log` for later inspection 4. Track the background PID so you can check completion 5. Launch ALL unblocked design tasks in parallel (multiple background shells)

Launch all unblocked tasks (both types) in parallel. A task is unblocked if all IDs in its depends_on list are complete.

Task Prompt Template

Use this for BOTH standard subagents AND design-mode `claude -p` tasks:

You are implementing a specific task from a development plan.

## Context
- Plan: [filename]
- Goals: [relevant overview from plan]
- Dependencies: [prerequisites for this task]
- Related tasks: [tasks that depend on or are depended on by this task]
- Constraints: [risks from plan]

## Your Task
**Task [ID]: [Name]**

Location: [File paths]
Description: [Full description]

Acceptance Criteria:
[List from plan]

Validation:
[Tests or verification from plan]

## Instructions
1. Read the working plan and fully understand this task before coding.
2. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
3. Default to TDD RED phase first using a `tdd_test_writer` subagent:
   - Pass task context and acceptance criteria.
   - Require tests-only edits.
   - Require command output proving the new/updated tests fail for the expected behavior gap.
   - If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
4. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
5. Implement production changes for all acceptance criteria.
6. Run validation:
   - For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
   - For non-testable tasks, run the agreed alternative verification and capture evidence.
   - Run any additional validation steps from the plan if feasible.
7. Commit your work.
   - Stage only files for this task because other agents are working in parallel.
   - NEVER PUSH. ONLY COMMIT.
8. After the commit, update the `*-pl