code-designing

<objective>
Domain type design and architectural planning for Go code.
Use when planning new features or identifying need for new types during refactoring.

**Reference**: See `reference.md` for complete design principles and examples.
</objective>

<quick_start>
1. **Analyze Architecture**: Check for vertical vs horizontal slicing
2. **Understand Domain**: Identify problem domain, concepts, invariants
3. **Identify Core Types**: Find primitives that need type wrappers
4. **Design Self-Validating Types**: Create types with validating constructors
5. **Plan Package Structure**: Vertical slices by feature
6. **Output Design Plan**: Present structured plan before implementation

Ready to implement? Use @testing skill for test structure.
</quick_start>

<when_to_use>
- Planning a new feature (before writing code)
- Refactoring reveals need for new types (complexity extraction)
- Linter failures suggest types should be introduced
- When you need to think through domain modeling
</when_to_use>

<purpose>
Design clean, self-validating types that:
- Prevent primitive obsession
- Ensure type safety
- Make validation explicit
- Follow vertical slice architecture
</purpose>

<workflow>

<architecture_pattern_analysis priority="FIRST_STEP">
**Default: Always use vertical slice architecture** (feature-first, not layer-first).

Scan codebase structure:
- **Vertical slicing**: `internal/feature/{handler,service,repository,models}.go`
- **Horizontal layering**: `internal/{handlers,services,domain}/feature.go`

<decision_flow>
1. **Pure vertical** → Continue pattern, implement as `internal/[new-feature]/`
2. **Pure horizontal** → Propose: Start migration with `docs/architecture/vertical-slice-migration.md`, implement new feature as first vertical slice
3. **Mixed (migrating)** → Check for migration docs, continue pattern as vertical slice
</decision_flow>

**Always ask user approval with options:**
- Option A: Vertical slice (recommended for cohesion/maintainability)
- Option B: Mat