execute-task

<trigger_examples>

• "Execute TASK_02"
• "Implement docs/features/search/TASK_01.md"
• "Run this task"
• "Execute the task"
• "Implement the search feature"
• "Build the user creation flow end-to-end"
• "Add the notifications endpoint to the API" </trigger_examples>

<phase_0_intake> Resolve the input and ensure the task document is complete before executing.

Step 1 — Determine input type:

• If $ARGUMENTS looks like a file path (ends in .md, or starts with /, ./, docs/, or contains a directory separator): read the file.
• Otherwise: treat it as a free-form task description — skip to Step 3.

Step 2 — Validate the task document: A task document is ready for execution when it contains ALL of:

• ## Scope — Files with at least one file entry
• ## Success Criteria with at least one testable criterion
• ## Verification Plan with baseline and post-change checks

If all required sections are present → proceed to phase 1.

Step 3 — Generate the task document: If the document is missing any required section, OR the input was a free-form description:

1. Inform the user:

   Task document incomplete. Generating a structured task document via /generate-tasks before proceeding.

2. Call Skill(skill: "generate-tasks") passing the original input as context.
3. After generation, note the path of the saved TASK_N.md file.
4. Read the generated file and confirm all required sections are present.
5. Resume execution using the generated document — continue to phase 1. </phase_0_intake>

<phase_1_context_analysis> Before writing any code, build a mental model of the task scope.

1. Read the resolved task document fully (path determined in phase 0).
2. Read the project CLAUDE.md and root package.json — understand project structure, available commands, and dependency graph.
3. Search the codebase for existing patterns — use Grep/Glob to find related files, similar implementations, and reusable code relevant to the task's file scope.
4. Identify the affected packages/directories from the task's "Scope — Files" section. </phase_1_context_analysis>

<phase_2_role_assignment> Determine the full execution context: role persona, domain area, domain technologies, project context, required skills, and available MCPs.

<domain_areas> Map the task to one or more domain areas AND sub-areas. Sub-areas determine the specialist agent type and skill set.

Backend

Sub-area	Agent type	When	Key skills
Database	database-expert	Schema design, migrations, complex queries, indexes	drizzle-pg, postgresql
Endpoints	api-builder	Routes, validation, handlers, API contracts	fastify-best-practices
Queues	general-purpose	Job processing, workers, schedulers	bullmq, ioredis
Security	security-scanner	Auth flows, RBAC, input sanitization	owasp-security-review

Frontend

Sub-area	Agent type	When	Key skills
Components	react-specialist	Component architecture, hooks, state management, composition	react-best-practices, composition-patterns
Pages/routing	general-purpose	Pages, layouts, data fetching, RSC boundaries	nextjs-best-practices
UI/UX	ux-optimizer	User flows, form UX, friction reduction	ui-ux-guidelines
Accessibility	accessibility-pro	WCAG compliance, keyboard nav, screen readers	—
Performance	performance-engineer	Core Web Vitals, bundle size, re-renders	react-best-practices

Shared packages — typescript-pro or general-purpose (shared types, schemas, utilities)

Cross-cutting specialists (use alongside any domain)

Agent type	When
test-generator	Writing test suites, improving coverage
debugger	Investigating errors, stack traces
docker-expert	Dockerfiles, compose, container config
code-reviewer	Post-implementation review
playwright-expert	E2E browser tests