Code Implementer Skill

Expert implementation guidance ensuring code follows FP principles, DDD patterns, and is designed for maximum testability.

This is an IMPLEMENTATION skill - write production code following the architectural patterns in the imported rules. For design decisions and architectural review, use /architecture-tech-lead instead.

Pre-Implementation Checklist

Before writing code, verify:

• • Boundaries clear: Where does I/O happen vs pure logic?
• • Invariants identified: What must always be true?
• • Types designed: Records/sealed types for domain? Discriminated unions?
• • Parse, don't validate: Return validated types? Invalid states unrepresentable?
• • Error handling: Using Either/Result? What errors are possible?
• • Testability: Can business logic be unit tested without mocks?

During Implementation

Structure Code as Functional Core + Imperative Shell

Imperative Shell (thin):

• •Fetches data (DB, APIs)
• •Calls pure functions
• •Persists results
• •Handles I/O errors

Functional Core (where logic lives):

• •Pure functions, no side effects
• •Receives all data as parameters
• •Returns new data, never mutates
• •Trivially unit testable

Apply Type Design

Apply patterns from imported rules:

• •Java: Records, sealed types, pattern matching (see java-patterns.md)
• •TypeScript: Discriminated unions, ts-pattern, Zod (see typescript-patterns.md)

Handle Errors Properly

Use Either/Result for all expected failures (see java-patterns.md for Either examples):

• •Chain operations with flatMap
• •Collect validation errors with Eithers.allFailures()
• •Never throw for expected failures - return typed errors

Post-Implementation Checklist

After writing code, verify:

• • No business logic in shell: All logic in pure functions?
• • Immutability: No mutations? Defensive copies where needed?
• • Invariants enforced: Constructors validate? Invalid states unrepresentable?
• • Error paths typed: Using Either/Result? No hidden throws?
• • Testable without mocks: Can test core logic with plain data?

Implementation Patterns Quick Reference

Data Transformation Flow

fetch (I/O) -> transform (pure) -> persist (I/O)

Service Method Structure

1. Fetch required data (shell - I/O)
2. Call pure function with data (core - testable)
3. Persist result (shell - I/O)
4. Return result

Invariant Enforcement

Constructor validates -> Object always valid -> No defensive checks elsewhere

Error Handling Chain

validate -> process -> transform -> (all via flatMap/map)

Test Strategy

For every implementation, consider:

Unit Tests (core logic)

• •Test pure functions with plain data
• •No mocks needed
• •Cover edge cases

Property Tests (invariants)

• •What must ALWAYS be true?
• •Round-trip properties
• •Idempotence where applicable

Integration Tests (shell only)

• •Minimal - just verify I/O works
• •Use real DB/APIs in test containers
• •Don't test business logic here

Quality Standards

• •Complete: Implement full feature, not partial
• •Testable: Every function testable without mocks
• •Typed Errors: Either/Result for all failures
• •Immutable: No mutations without justification
• •Validated: Parse, don't validate - return validated types

Context Awareness

Tailor to detected stack. See imported rules for patterns:

• •Java: java-patterns.md (records, sealed types, Either)
• •TypeScript: typescript-patterns.md (discriminated unions, ts-pattern)
• •Testing: property-testing.md (jqwik patterns)