---
name: ticket-implementation
description: Execute systematic ticket implementation workflow with validation gates
---

# Ticket Implementation Skill

Execute a systematic ticket implementation workflow with validation gates.

## When to Use

Use this skill when:
- Implementing a ticket from the ticket database
- Starting work on a user story
- Need systematic guidance through feature development

## Workflow Steps

### Phase 1: Preparation

**Step 1 - Validate Clean State**
```bash
git status
```
Ensure no uncommitted changes that could conflict.

**Step 2 - Get Ticket Details**
```bash
ticket-manager.sh show <TICKET_ID>
```
Read the full ticket: title, description, acceptance criteria, and technical notes.

**Step 3 - Mark In Progress**
```bash
ticket-manager.sh update <TICKET_ID> IN_PROGRESS "Starting implementation"
```

**Step 4 - Create Feature Branch**
```bash
git checkout -b feature/<TICKET_ID>-short-description
```

### Phase 2: Analysis (BEFORE WRITING CODE)

**Step 5 - Read Requirements Fully**
- Parse ALL acceptance criteria as Gherkin scenarios
- Identify the happy path and edge cases
- Note any ambiguities to clarify with user

**Step 6 - Check API Schema**
For backend changes:
- Read the relevant Controller to understand the endpoint contract
- Read the Request/Response DTOs for required fields
- Check for: required fields, correct types, null handling

For mobile changes:
- Read the corresponding Repository and DTO classes
- Ensure mobile DTOs match backend expectations exactly
- Check kotlinx.serialization annotations for nullable fields

**Step 7 - List Assumptions**
Before implementing, explicitly state any assumptions:
```
ASSUMPTIONS:
1. [Assumption about requirement X]
2. [Assumption about edge case Y]
3. [Assumption about existing behavior Z]
```
Ask the user to confirm if any assumption is uncertain.

### Phase 3: Implementation

**Step 8 - Implement with Type Safety**
- For Kotlin: Use proper types, not `Any` or unchecked casts
- For Java: Use generics properly, avoid raw types
- For TypeScript: No `any` types without justification
- All nullable fields must have default values in DTOs

**Step 9 - Follow Existing Patterns**
- Check how similar features are implemented in the codebase
- Maintain consistency with existing code style
- Use existing utilities and helpers

**Step 10 - Handle Edge Cases**
Implement handling for:
- Null/empty inputs
- Network failures (for mobile)
- Permission denied scenarios
- Invalid state transitions

### Phase 4: Validation

**Step 11 - Compile Check**
Run compilation to catch type errors early:

For Kotlin Multiplatform:
```bash
cd mobile && ./gradlew compileDebugKotlinAndroid compileKotlinIosArm64 --quiet
```

For Java backend:
```bash
cd backend && ./gradlew compileJava --quiet
```

For TypeScript:
```bash
npx tsc --noEmit
```

**Step 12 - Run Tests**
```bash
# Backend
cd backend && ./gradlew test --quiet

# Mobile (if tests exist)
cd mobile && ./gradlew :shared:testDebugUnitTest --quiet
```

**Step 13 - Verify Acceptance Criteria**
Go through each acceptance criterion:
- [ ] Criterion 1: Verified by [how]
- [ ] Criterion 2: Verified by [how]
- [ ] Criterion N: Verified by [how]

### Phase 5: Completion

**Step 14 - Commit Changes**
```bash
git add -A
git commit -m "feat(<TICKET_ID>): <description>

- Implemented <summary of changes>
- <additional notes>

Co-Authored-By: Claude <noreply@anthropic.com>"
```

**Step 15 - Mark Done**
```bash
ticket-manager.sh done <TICKET_ID> "Implemented: <brief summary>"
```

**Step 16 - Report Completion**
Summarize to the user:
- What was implemented
- Files changed
- Any assumptions made
- Any follow-up items discovered

## Validation Gates

The workflow has mandatory gates - do NOT proceed if:

| Gate | Check | Action if Failed |
|------|-------|------------------|
| Clean git state | `git status` shows clean | Stash or commit existing changes |
| Compilation | Zero compile errors | Fix errors before proceeding |
| Tests pass | All tests green | Fix failing tests |
| Acceptance criteria | All criteria met | Complete missing requirements |

## Quality Checklist

Before marking a ticket done, verify:

- [ ] All acceptance criteria are met
- [ ] Code compiles without errors
- [ ] Existing tests still pass
- [ ] New code follows existing patterns
- [ ] No hardcoded values that should be configurable
- [ ] Error cases are handled gracefully
- [ ] Assumptions are documented

## Example Usage

User: "Implement ticket 19.1"

Claude will:
1. Check git status
2. Read ticket 19.1 details
3. Mark it IN_PROGRESS
4. Create branch `feature/19.1-healthkit-purpose-strings`
5. Analyze requirements and API contracts
6. List assumptions for user confirmation
7. Implement the feature
8. Run compile checks
9. Run tests
10. Verify acceptance criteria
11. Commit with descriptive message
12. Mark ticket DONE
13. Report summary to user