Data

Data - Data Layer Generator

Generate data layer components that implement domain interfaces and handle external data sources.

Philosophy

The data layer is the only place for:

• Freezed models with JSON serialization
• API field mapping (@JsonKey)
• Repository implementations
• Data source abstractions (remote, local, cache)

This keeps the domain pure while handling all serialization and external communication here.

When to Use This Skill

• After /domain has created entities and repository interfaces
• When implementing API integration
• When adding local storage/caching
• When you have backend code or OpenAPI specs as reference
• User asks to "implement repository", "create DTOs", or "wire up API"

Note: This skill replaces the former /api skill. All API integration functionality is now here.

What This Skill Creates

lib/features/{feature}/data/
├── models/
│   ├── {entity}_model.dart       # Freezed DTO with JSON
│   └── {entity}_model.g.dart     # Generated JSON code
├── repositories/
│   └── {feature}_repository_impl.dart  # Implements domain interface
└── data_sources/
    ├── {feature}_remote_data_source.dart   # API calls
    └── {feature}_local_data_source.dart    # Local storage (optional)

Input Sources

Workflow

Step 1: Locate Requirements

Check for:

lib/features/{feature}/.spec.md           # Feature specification
lib/features/{feature}/domain/            # Domain entities/repository interface

If domain layer doesn't exist, ask user to run /domain {feature} first.

Step 2: Analyze Data Sources

From spec:

• API Endpoints - Section 3.1 (URLs, methods, request/response shapes)
• Local Storage - Section 3.2 (what to persist, cache strategy)
• Field Mappings - API field names vs domain field names

From backend code (if provided):

• Extract endpoint paths from controllers/routes
• Extract request/response shapes from DTOs
• Map snake_case API fields to camelCase Dart fields

Step 3: Generate Code

Use reference files in reference/ directory as templates:

Step 4: Run Code Generation

dart run build_runner build --delete-conflicting-outputs

Step 5: Verify

dart run .claude/skills/data/scripts/check.dart {feature}

Commands

# Generate data layer from spec
/data {feature}

# Generate only DTOs
/data {feature} --only=models

# Generate only repository implementation
/data {feature} --only=repository

# Add new endpoint to existing data layer
/data {feature} --add-endpoint={methodName}

Checklist

Before finishing data layer generation:

• All DTOs match API response shapes
• @JsonKey mappings handle snake_case → camelCase
• toEntity() and fromEntity() methods implemented
• Repository implements all domain interface methods
• Data source handles all API endpoints
• Error handling uses typed Failures (no hardcoded strings)
• Nullable fields handled correctly
• Run build_runner to generate code
• No lint errors after generation

Naming Conventions

Data Layer Rules

1. Freezed for all DTOs - Immutability + JSON + equality
2. Always map to domain - toEntity() and fromEntity() required
3. Handle API field names - Use @JsonKey for snake_case
4. Repository is the boundary - Only repository returns domain entities
5. Data sources return DTOs - Never return domain entities from data sources
6. Typed failures - No hardcoded error strings, use Failure types

What Goes Where

Guides

Related Skills

• /domain - Run first to create entities and repository interfaces
• /feature-init - Initialize feature scaffold (run before /domain and /data)
• /plan - Plan data sources before implementation
• /presentation - Implement UI layer after data layer is complete
• /testing - Create tests for repositories and data sources
• /i18n - Localize error messages (via failure mapper)