$npx -y skills add jgamaraalv/ts-dev-kit --skill execute-taskExecutes a task, either from a TASK_N.md file or a free-form description. Use when: (1) implementing a task from a TASK_N.md file, (2) the user provides a task file path or says 'execute this task', 'implement TASK_02', or 'run this task', (3) the user describes a task directly w
| 1 | <trigger_examples> |
| 2 | - "Execute TASK_02" |
| 3 | - "Implement docs/features/search/TASK_01.md" |
| 4 | - "Run this task" |
| 5 | - "Execute the task" |
| 6 | - "Implement the search feature" |
| 7 | - "Build the user creation flow end-to-end" |
| 8 | - "Add the notifications endpoint to the API" |
| 9 | </trigger_examples> |
| 10 | |
| 11 | <task> |
| 12 | $ARGUMENTS |
| 13 | </task> |
| 14 | |
| 15 | <workflow> |
| 16 | Follow each phase in order. Each one feeds the next. |
| 17 | |
| 18 | <phase_0_intake> |
| 19 | Resolve the input and ensure the task document is complete before executing. |
| 20 | |
| 21 | **Step 1 — Determine input type:** |
| 22 | - If `$ARGUMENTS` looks like a file path (ends in `.md`, or starts with `/`, `./`, `docs/`, or contains a directory separator): read the file. |
| 23 | - Otherwise: treat it as a free-form task description — skip to Step 3. |
| 24 | |
| 25 | **Step 2 — Validate the task document:** |
| 26 | A task document is ready for execution when it contains ALL of: |
| 27 | - `## Scope — Files` with at least one file entry |
| 28 | - `## Success Criteria` with at least one testable criterion |
| 29 | - `## Verification Plan` with baseline and post-change checks |
| 30 | |
| 31 | If all required sections are present → proceed to phase 1. |
| 32 | |
| 33 | **Step 3 — Generate the task document:** |
| 34 | If the document is missing any required section, OR the input was a free-form description: |
| 35 | |
| 36 | 1. Inform the user: |
| 37 | > **Task document incomplete.** Generating a structured task document via `/generate-tasks` before proceeding. |
| 38 | 2. Call `Skill(skill: "generate-tasks")` passing the original input as context. |
| 39 | 3. After generation, note the path of the saved `TASK_N.md` file. |
| 40 | 4. Read the generated file and confirm all required sections are present. |
| 41 | 5. Resume execution using the generated document — continue to phase 1. |
| 42 | </phase_0_intake> |
| 43 | |
| 44 | <phase_1_context_analysis> |
| 45 | Before writing any code, build a mental model of the task scope. |
| 46 | |
| 47 | 1. Read the resolved task document fully (path determined in phase 0). |
| 48 | 2. Read the project CLAUDE.md and root package.json — understand project structure, available commands, and dependency graph. |
| 49 | 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. |
| 50 | 4. Identify the affected packages/directories from the task's "Scope — Files" section. |
| 51 | </phase_1_context_analysis> |
| 52 | |
| 53 | <phase_2_role_assignment> |
| 54 | Determine the full execution context: role persona, domain area, domain technologies, project context, required skills, and available MCPs. |
| 55 | |
| 56 | <domain_areas> |
| 57 | Map the task to one or more domain areas AND sub-areas. Sub-areas determine the specialist agent type and skill set. |
| 58 | |
| 59 | **Backend** |
| 60 | | Sub-area | Agent type | When | Key skills | |
| 61 | |----------|-----------|------|------------| |
| 62 | | Database | `database-expert` | Schema design, migrations, complex queries, indexes | drizzle-pg, postgresql | |
| 63 | | Endpoints | `api-builder` | Routes, validation, handlers, API contracts | fastify-best-practices | |
| 64 | | Queues | `general-purpose` | Job processing, workers, schedulers | bullmq, ioredis | |
| 65 | | Security | `security-scanner` | Auth flows, RBAC, input sanitization | owasp-security-review | |
| 66 | |
| 67 | **Frontend** |
| 68 | | Sub-area | Agent type | When | Key skills | |
| 69 | |----------|-----------|------|------------| |
| 70 | | Components | `react-specialist` | Component architecture, hooks, state management, composition | react-best-practices, composition-patterns | |
| 71 | | Pages/routing | `general-purpose` | Pages, layouts, data fetching, RSC boundaries | nextjs-best-practices | |
| 72 | | UI/UX | `ux-optimizer` | User flows, form UX, friction reduction | ui-ux-guidelines | |
| 73 | | Accessibility | `accessibility-pro` | WCAG compliance, keyboard nav, screen readers | — | |
| 74 | | Performance | `performance-engineer` | Core Web Vitals, bundle size, re-renders | react-best-practices | |
| 75 | |
| 76 | **Shared packages** — `typescript-pro` or `general-purpose` (shared types, schemas, utilities) |
| 77 | |
| 78 | **Cross-cutting specialists** (use alongside any domain) |
| 79 | | Agent type | When | |
| 80 | |-----------|------| |
| 81 | | `test-generator` | Writing test suites, improving coverage | |
| 82 | | `debugger` | Investigating errors, stack traces | |
| 83 | | `docker-expert` | Dockerfiles, compose, container config | |
| 84 | | `code-reviewer` | Post-implementation review | |
| 85 | | `playwright-expert` | E2E browser tests | |
| 86 | |
| 87 | A single task may require agents from multiple sub-areas. For example, "add a new resource endpoint with list UI" needs `database-expert` (schema) + `api-builder` (route) + `react-specialist` (component). |
| 88 | </domain_areas> |
| 89 | |
| 90 | <domain_technologies> |
| 91 | Read the relevant package.json to identif |