code-task — Skill de Claude
Implement a single PRD task end-to-end: TDD gate, layered implementation, architecture verification, status update. Use when a `prds/*/tasks/*.md` task is ready to be coded — typically after `/plan-tasks`. Reads the task file, refuses to start unless failing tests exist, then walks domain → application → infrastructure → delivery, runs `npm run test`/`lint`/`compile`/`build`, and marks the task complete in the PRD.
#Code Task
Implement a task from the PRD. Reads task file from prds/*/tasks/, writes code following BDD and pseudocode, runs verification. Use AFTER /plan-tasks.
“”IMPORTANT: This skill enforces TDD. Tests MUST exist before implementation.
#Workflow
#Step 1: Find and Select Task
Find task files:
Glob prds/*/tasks/*.md
If multiple tasks exist, show the user:
- Task number and name
- Status (⬜ Not Started, 🔄 In Progress, ✅ Complete)
- Dependencies
Ask which task to implement. Prefer tasks that are:
- Not Started (⬜)
- Have all dependencies completed (✅)
#Step 2: Read Task File
Read the selected task file thoroughly. Extract:
- Overview: What this task accomplishes
- BDD Scenarios: Given/When/Then acceptance criteria
- Implementation Checklist: Files to create/modify by layer
- Pseudocode: Detailed code structure for each file
- Architecture Gate: Verification requirements
- Dependencies: What must be done first
#Step 3: TDD Gate (MANDATORY)
Before ANY implementation, verify tests exist:
Glob src/features/<feature>/**/*.test.unit.ts
Glob src/features/<feature>/**/*.it.test.tsx
Glob e2e-tests/<feature>.test.e2e.ts
If tests don't exist or don't cover the BDD scenarios:
- STOP implementation
- Invoke
/tdd-bddto generate failing tests - Return here after tests are created and verified to FAIL
#Step 4: Read Project Context
Before implementing, understand the codebase:
Read CLAUDE.md
Pay special attention to:
- DDD Architecture Patterns section
- Layer Structure and dependency rules
- DI Container Registration pattern
- Mother Pattern for test data
- TDD Enforcement rules
#Step 5: Implement by Layer
Follow the Implementation Checklist from the task file. For complex layers, delegate to specialized skills:
| Layer | Simple | Complex (delegate) |
|-------|--------|-------------------|
| Domain | Implement directly | /create-domain-model |
| Repository | Implement directly | /create-repository-contract |
| Application | Implement directly | /create-use-case |
| Infrastructure | Implement directly | /create-infrastructure |
| Delivery | Implement directly | /create-delivery |
Key patterns from CLAUDE.md:
- All use cases need
static readonly ID = Symbol.for('ClassName') - All repositories need
static readonly ID = Symbol.for('ClassName') - Register in
src/core/di/app.container.ts - Mother pattern for test data in
domain/<entity>.mother.ts
#Step 6: Run Architecture Gate
After implementation, verify the task's Architecture Gate:
npm run test # All tests pass (should go from RED to GREEN) npm run lint # Lint passes npm run compile # Compilation passes npm run build # Build passes
If any check fails, fix the issues before proceeding.
#Step 7: Validate Architecture
Invoke /architecture-guardrails to verify:
- Layer boundaries respected
- DI registration complete
- No forbidden imports
Optionally invoke /refactor for final cleanup.
#Step 8: Update Task Status
After all checks pass, update the task status in the PRD:
- Read
prds/<prd-folder>/PRD.md - Find the task in the Tasks table
- Change status from ⬜ to ✅
Also update the task file header:
**Status**: ✅ Complete
#Step 9: Summary
Output a summary:
✅ Task X.Y Complete: [Task Name]
Files created/modified:
- src/features/<feature>/domain/<file>.ts
- src/features/<feature>/application/<file>.ts
- ...
Tests:
- X unit tests passing
- X integration tests passing
- X E2E tests passing
Next task: [X.Z - Task Name] or "All tasks complete!"
#Rules
- TDD Gate is mandatory — Never implement without failing tests first
- Follow the pseudocode — The task file contains detailed pseudocode; implement it faithfully
- Respect BDD scenarios — Every Given/When/Then must have a corresponding test
- One task at a time — Complete one task fully before starting another
- Green build always — Never leave the build broken
- Ask when unclear — If pseudocode is ambiguous, ask the user
- Minimal changes — Only implement what's in the task, no extras
#Skill Chain Order
When delegating to skills, they follow this order:
/tdd-bdd (ALWAYS FIRST)
→ /create-domain-model
→ /create-repository-contract
→ /create-use-case
→ /create-infrastructure
→ /create-delivery
→ /architecture-guardrails
→ /refactor