---
description: Implement a specific task from the feature breakdown
argument-hint: <feature-slug> <task-id>
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Task
---

Implement task: $ARGUMENTS

## Instructions

### 1. Parse Arguments

Extract the feature slug and task ID from `$ARGUMENTS`. The first token is the slug, the second is the task ID.

### 2. Start the Task

```bash
sdlc task start <slug> <task-id>
```

This marks the task as in-progress and prevents other tasks from being picked up concurrently.

### 3. Load Context

Read all relevant artifacts:
- `.sdlc/features/<slug>/spec.md` -- requirements
- `.sdlc/features/<slug>/design.md` -- architecture decisions
- `.sdlc/features/<slug>/tasks.md` -- find this task scope and acceptance criteria

### 4. Study Existing Patterns

Before writing code, read the files identified in the task description. Understand the patterns, naming conventions, and test approaches already in use.

### 5. Implement

Write the code changes specified by the task. Follow existing patterns. For each file:
- Production code first
- Tests alongside or immediately after
- Update any relevant documentation or configuration

### 6. Run Tests

```bash
go test ./... -v 2>&1 | tee /tmp/task-test-output.txt
# or the appropriate test command for the project stack
```

All existing tests must continue to pass. New tests must pass. Check the output and only proceed if all tests pass.

### 7. Complete the Task

Only if tests pass:

```bash
sdlc task complete <slug> <task-id>
```

### 8. Report

Summarize: files changed, tests added, task acceptance criteria status.

## Critical Rules

- ALWAYS start the task via CLI before implementing
- ALWAYS run tests before marking complete
- NEVER mark a task complete if tests fail
- ALWAYS follow existing codebase patterns
- NEVER implement beyond the task stated scope
- ALWAYS read spec and design for context before coding