Execute Task

---
description: "Execute tasks from task list using Test-Driven Development (TDD) methodology"
argument-hint: "<task-list-file-path via stdin> [task-id|phase-name]"
allowed-tools: "TodoWrite, Read, Write, MultiEdit, Edit, Bash(npm:*), Bash(npx:*), Bash(node:*), Bash(git status:*), Bash(git diff:*), Grep, Glob, Task"
---

# TDD Task Executor Agent

The task list file path is $ARGUMENTS.

---

## 🚨 IMMEDIATE ACTION REQUIRED: CODE GENERATION

**YOU MUST NOW GENERATE CODE** for all tasks in the task list. This is NOT an analysis or planning phase - this is the EXECUTION phase where you write tests and implementation code.

**Your mission**:
1. ✅ **Write actual test files** using Write/Edit tools
2. ✅ **Write actual implementation files** (components, hooks, stores, utilities)
3. ✅ **Run tests** using Bash to verify they pass
4. ✅ **Continue until ALL tasks are completed** or you hit a blocker

**DO NOT STOP after reading the task list.** Reading and planning are just the first steps - you must proceed to actual code generation.

---

## 🎯 CRITICAL SUCCESS CRITERIA

**YOU MUST COMPLETE ALL TASKS** - There is NO time limit, NO token budget concern, NO complexity excuse to stop early.

**COMPLETION REQUIREMENTS**:
- ✅ **Execute ALL tasks** in the task list sequentially
- ✅ **Complete ALL phases** (Phase 1, 2, 3, 4, 5, etc.)
- ✅ **Implement ALL components** mentioned in the task list
- ✅ **Run ALL tests** and ensure they pass
- ❌ **DO NOT STOP** after completing only some phases

**VALID REASONS TO STOP** (only these):
- ✅ Actual technical blocker (missing external API, user input required for ambiguous requirement)
- ✅ External dependency doesn't exist and cannot be created
- ✅ Explicit user request to stop

**INVALID REASONS TO STOP** (keep working):
- ❌ "Time constraints" - **there is NO time limit**
- ❌ "Token budget concerns" - you have 200k tokens available, use them
- ❌ "Complexity" - break complex tasks into smaller steps
- ❌ "Remaining work is UI only" - UI implementation is REQUIRED
- ❌ "Core functionality complete" - ALL tasks must be complete, not just core

**If you find yourself wanting to stop early, ask**:
1. Have I completed ALL tasks in the task list? If NO → CONTINUE
2. Is there an actual technical blocker? If NO → CONTINUE
3. Has the user explicitly asked me to stop? If NO → CONTINUE

**TASK LIST FILE TRACKING (MANDATORY)**:

The task list file contains a "📋 TASK COMPLETION TRACKING" section that you MUST keep updated:

1. **When starting a task**: Use Edit tool to check `[x]` the "🔄 In Progress" box
2. **When completing a task**: Use Edit tool to check `[x]` the "✅ Completed" box
3. **After each completion**: Update the progress counter (e.g., "Progress: 5/23 tasks completed (22%)")

**This serves as**:
- Visual progress indicator for user
- Audit trail of what was actually completed
- State persistence if execution is interrupted
- Forcing function to prevent skipping tasks

**Example Task List Tracking Update**:
```markdown
### Phase 1: Data Layer
- [x] 🔄 Task 1.1: Create type definitions - [x] ✅ Completed
- [x] 🔄 Task 1.2: Create upgrade catalog - [ ] ✅ Completed  ← Currently working on this
- [ ] 🔄 Task 1.3: Create persistence layer - [ ] ✅ Completed

**Progress**: 1/23 tasks completed (4%)

---

Initial Validation Process

Before beginning code generation:

1. Read the file to get the task list file path
2. Validate the file path is not empty
3. Check if file exists
4. Load task list contents using Read tool

Step 2: Load and Validate Task List Contents

ONLY proceed if validation passes:

1. Use Read tool to load task list file contents
2. Verify task list contains valid tasks
3. Parse tasks and phases

CRITICAL: Never start task execution if ANY validation step fails. Report errors clearly and exit.

Step 3: Codebase Exploration & Integration Planning

CRITICAL: Before writing ANY code, understand the existing codebase and plan integration.

1. Explore Existing Code:

   • Use Glob/Grep to find components/screens mentioned in task
   • Example: Task mentions "TodoListScreen" → Search: Glob **/*TodoList*.tsx
   • Read existing files to understand current implementation
   • Identify integration points (App.tsx, navigation, existing screens)

2. Architectural Decision: For EACH component/feature in the task, decide:

   Decision Tree:

   Does component with this name/purpose already exist?
   ├─ YES → Should I update existing or create new?
   │   ├─ Same purpose → UPDATE existing component
   │   │   └─ Document: "UPDATING: modules/todo/TodoListScreen.tsx (adding filtering functionality)"
   │   └─ Different purpose → CREATE new with distinct name
   │       └─ Document: "CREATING: modules/todo/TodoManagementScreen.tsx (distinct from list)"
   │
   └─ NO → Where should new component live?
       ├─ Task spec location (modules/todo/) if it's primary owner
       ├─ Related module (modules/filters/) if it extends existing feature
       └─ Shared location if used across features
   

3. Integration Plan Document: Before writing code, create mental model:

   INTEGRATION PLAN:
   ✓ Explored: modules/todo/TodoListScreen.tsx exists (currently shows empty state)
   ✓ Analyzed: App.tsx imports from modules/todo/TodoListScreen.tsx
   ✓ Decision: UPDATE existing TodoListScreen to show items
   ✓ Location: modules/todo/TodoListScreen.tsx (owns list UI)
   ✓ New files: modules/todo/components/TodoCard.tsx (reusable component)
   ✓ Rationale: Todo list screen is the integration point, todo items are feature components
   

   Integration Simplicity Check:

   • Does the original feature request mention navigation/multiple screens?
   • NO → Use MINIMAL integration (direct mount in App.tsx, no new screens)
   • YES → Plan full navigation integration

   Example:

   • Request: "button and counter" → Mount SingularityPet directly in App.tsx
   • Request: "todo list screen with filters" → Create screen + navig