agentsclimarketplace
Sign in

Data modeling

Skill SWEStash/swe-workflow-skills/plugins/backend/skills/data-modeling

Design database schemas, relationships, indexes, and migration strategies — relational and document stores. Triggers: data model, schema design, ER diagram, database schema, table design, foreign key, index strategy, normalization, denormalization, migration plan, document model, partition key.From its SKILL.md

Install
npx -y skills add SWEStash/swe-workflow-skills --skill data-modeling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, 706 tokens by cl100k_base, as published. Nobody here has run it

Data Modeling

Guide the user through designing data models that are normalized, consistent, and evolvable. Good data models make the right things easy and the wrong things hard.

Workflow

Step 1: Understand the Domain

Before touching schemas, understand the business domain:

  • What are the core entities? (nouns in the requirements: User, Order, Product)
  • What are the relationships? (verbs: User places Order, Order contains Products)
  • What are the cardinalities? (one-to-one, one-to-many, many-to-many)
  • What are the access patterns? (how will the data be queried most often)
  • What are the invariants? (rules that must always hold: "an order must have at least one item")

If the user describes a feature rather than a domain, extract the entities from the feature description first.

Step 2: Design the Conceptual Model

Produce an entity-relationship description listing:

  • Each entity with its key attributes
  • Relationships with cardinality (1:1, 1:N, M:N)
  • Business rules that constrain the model

Present this as a structured list or ASCII diagram. Don't jump to SQL yet — validate the conceptual model with the user first.

Step 3: Apply Normalization

Design tables following normalization principles:

  • 1NF: No repeating groups; every column holds atomic values
  • 2NF: Every non-key column depends on the whole primary key
  • 3NF: No transitive dependencies (non-key → non-key)

Denormalize only with explicit justification (specific read performance requirement with measured data). Document every denormalization decision and the access pattern it serves.

Step 4: Define the Physical Schema

Produce SQL DDL or ORM model definitions. For each table include:

  • Primary key strategy (auto-increment, UUID, ULID — justify the choice)
  • Foreign keys with ON DELETE/ON UPDATE behavior
  • Indexes based on identified access patterns
  • Constraints (NOT NULL, UNIQUE, CHECK) that enforce business rules
  • Timestamps (created_at, updated_at) as appropriate

Use templates/schema.md as a starting point for table DDL, index naming, enum patterns, and migration file structure.

Step 5: Plan the Migration

If modifying an existing schema:

  • Backwards-compatible changes: Add columns with defaults, add tables, add indexes
  • Breaking changes: Require a migration strategy (expand-contract pattern)
  • Data backfills: Script them, don't do them manually

Produce migration files appropriate to the ORM/framework in use. Each migration should be independently reversible.

Step 6: Validate

Cross-check the schema against:

  • Every acceptance criterion from the feature plan can be served by the schema
  • Every identified access pattern has an appropriate index
  • Every business invariant is enforced by constraints
  • No data can be orphaned (foreign keys and cascades are correct)
  • The migration is reversible

Principles Applied

  • DRY: Single source of truth for each piece of data
  • KISS: Start normalized; denormalize only when measured performance demands it
  • Functional Independence: Each table represents one concept
  • YAGNI: Don't add columns or tables "just in case"

What ships with it: 3 files

9.2 KB alongside SKILL.md

evals/

references/

templates/

Gives 0 of the 12 instructions most data backend skills give in 706 tokens

Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07

  • Separate business logic into service layersin 22 of 229, across 15 files
  • Retry failures with exponential backoffin 21 of 229, across 14 files
  • Select only needed database columnsin 20 of 229, across 13 files
  • Abstract data access into repository classesin 19 of 229, across 12 files
  • Use centralized error handlersin 17 of 229, across 10 files
  • Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
  • Use async/await for all I/O operationsin 16 of 229, across 5 files
  • Implement structured loggingin 15 of 229, across 4 files
  • Use dependency injection for all servicesin 14 of 229, across 2 files
  • Use resource-based URLs for REST APIsin 13 of 229, across 7 files
  • Invalidate cache after data changesin 13 of 229, across 9 files
  • Use a dependency injection containerin 12 of 229, across 4 files

Said here and by no other author read

  • Extract core entities from feature descriptions
  • Document entity relationships and cardinalities
  • Validate the conceptual model before writing SQL
  • Apply first, second, and third normal forms
  • Document every explicit denormalization decision
  • Define primary keys, foreign keys, and indexes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.