agentleFS
Sign inStart free
launch52-ailaunch52-ai/flutter-template/.claude/skills/data/SKILL.md

data

Skill2 starsChanged 9 months agoMITView on GitHub

Generate data layer code (Freezed DTOs, repository implementations, data sources) from feature specifications or API references. Creates the bridge between domain entities and external data sources. Use after /domain to implement the data layer.

We split this skill into the rules it gives an agent

11 rules. 0 are common, 7 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    After /domain has created entities and repository interfaces

    line 23
  2. Distinctive:

    When implementing API integration

    line 24
  3. Distinctive:

    When adding local storage/caching

    line 25
  4. Distinctive:

    When you have backend code or OpenAPI specs as reference

    line 26
  5. Very specific:

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

    line 64
  6. Very specific:

    Use reference files in reference/ directory as templates:

    line 80
  7. Distinctive:

    Before finishing data layer generation:

    line 130
  8. Very specific:

    Handle API field names: - Use @JsonKey for snake_case

    line 156
  9. Distinctive:

    Repository is the boundary: - Only repository returns domain entities

    line 157
  10. Distinctive:

    Data sources return DTOs: - Never return domain entities from data sources

    line 158
  11. Distinctive:

    Typed failures: - No hardcoded error strings, use Failure types

    line 159

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

SourceWhat Claude Extracts
Feature spec (.spec.md)Endpoints, DTOs, storage needs
Backend code (NestJS, Express)Controllers, DTOs, types
OpenAPI/Swagger specPaths, schemas, request/response shapes
Endpoint descriptionsGET /users → User[]

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:

ComponentReference File
Simple DTOreference/models/simple_model.dart
Nested DTOreference/models/nested_model.dart
Custom convertersreference/models/custom_converter_model.dart
Request DTOsreference/models/request_models.dart
Paginationreference/models/paginated_response.dart
Basic repositoryreference/repositories/basic_repository_impl.dart
Cached repositoryreference/repositories/cached_repository_impl.dart
Mock repositoryreference/repositories/mock_repository.dart
Remote data sourcereference/data_sources/remote_data_source.dart
Local (prefs)reference/data_sources/local_data_source_prefs.dart
Local (secure)reference/data_sources/local_data_source_secure.dart
Failuresreference/failures/failures.dart
Error mappingreference/failures/dio_error_handler.dart
i18n mappingreference/failures/failure_mapper.dart
Provider registrationreference/providers/repository_provider.dart

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

ElementConventionExample
DTO class{Entity}ModelMemoryModel
DTO file{entity}_model.dartmemory_model.dart
Repository impl{Feature}RepositoryImplMemoriesRepositoryImpl
Remote data source{Feature}RemoteDataSourceMemoriesRemoteDataSource
Local data source{Feature}LocalDataSourceMemoriesLocalDataSource

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

ConcernLayerExample
Entity fields & business logicDomainMemory.isSynced
JSON serializationData@JsonKey(name: 'is_synced')
API endpointsData_dio.get('/memories')
Field mappingDatatoEntity(), fromEntity()
Error typesDataNetworkFailure.noConnection()
Error messagesPresentationt.errors.noConnection (i18n)

Guides

GuideUse For
patterns-guide.mdBasic pattern descriptions and when to use
advanced-patterns.mdPagination, retry, caching, uploads, auth interceptor
examples.mdComplete before/after examples by input source
reference/Actual code templates

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)

Download now (ZIP)

  • Other versions14 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 14

    1. Zafer-Liu/Data-Analysis-Agent★ 2.6ksame name
    2. trycompai/comp★ 2ksame name
    3. whitecircle/halo★ 825same name
    4. notque/vexjoy-agent★ 443same name
    5. notque/claude-code-toolkit★ 442same name
    6. robium-ai/robium★ 93same name
    7. emretasss/stellar-paygate-mcp★ 1same name
    8. Evan-Kim2028/agent-skills★ 1same name
    9. joaocarloscruz/skills★ 1same name
    10. ksed8/cc-loopkit★ 1same name

    4 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use content, frontend and 3 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • Rayan55050Skill

      content

      Создание контента: посты, статьи, тексты

      Also in 3 projects that use this

    • imehrSkill

      frontend

      Use when building UI components, pages, or features - guides Claude through the approved frontend stack (Next.js 15, React 19, Shadcn, Tailwind) with design-first workflow for complex UIs, enforcing patterns and quality standards

      Also in 4 projects that use this

    • alxyrginSkill

      writing

      Создание контента для личного бренда — статьи, посты, туториалы. Use when user asks to "напиши статью", "создай пост", "подготовь контент", "write article", "create content", or when task requires content creation for blogging, LinkedIn, Medium, or other publishing platforms.

      Also in 3 projects that use this

    • 0xSeroSkill

      security

      Also in 4 projects that use this

    • NVIDIASkill

      research

      Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.

      Also in 4 projects that use this

  • In this repository27 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free