Agent skill

Database Schema Design

by mohitagw15856 in mohitagw15856/pm-claude-skills

Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns.

MITAuto-check passedDatabases

Install Database Schema Design

skills CLI
$ npx skills add mohitagw15856/pm-claude-skills --skill database-schema-design -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install mohitagw15856/pm-claude-skills database-schema-design --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/database-schema-design .claude/skills/database-schema-design && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
database-schema-design
GitHub stars
1.4k
Token cost
~3.9k tokens
SKILL.md length
1,339 words
Files
1
Skills in repo
1,322
Repo updated
First seen
Licence
MIT

At a glance

Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns.

  • Works in 8 steps: Overview → Entity Relationship Diagram → Table Definitions → …
  • Asked to design a database
  • SKILL.md covers Required Inputs, Output Format, 1. Overview and 2. Entity Relationship Diagram, plus 9 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Database Schema Design is an agent skill from mohitagw15856/pm-claude-skills. Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns. Use when asked to design a database, document an existing schema, model entities and relationships, define table structures, plan an index strategy, or produce a data model for review. Produces a structured schema document covering an ER diagram, table DDL definitions, index strategy, access pattern analysis, normalization decisions, and migration notes.

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases, covering Database schema design and Diagrams. The repository describes itself as: 1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in… The licence is MIT.

When your agent uses it

  • Asked to design a database
  • Document an existing schema
  • Model entities and relationships
  • Define table structures

Example prompts

  • “/database-schema-design”

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Overview
  2. Entity Relationship Diagram
  3. Table Definitions
  4. Index Strategy
  5. Access Pattern Analysis
  6. Normalization Decisions
  7. Triggers and Automation
  8. Migration Notes

What it can do on your machine

Read from SKILL.md and the folder at commit 1cbf1f0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are sql).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Database Schema Design loads about 3.9k tokens when it runs. Until then it costs about 126 tokens; SKILL.md has 1,339 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~126
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from mohitagw15856/pm-claude-skills at commit 1cbf1f0, republished under its MIT licence (© mohitagw15856). 1,339 words, ~3,914 tokens.

Download SKILL.mdSave it as .claude/skills/database-schema-design/SKILL.md (or your agent's skills folder).
name
database-schema-design
description
Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns. Use when asked to design a database, document an existing schema, model entities and relationships, define table structures, plan an index strategy, or produce a data model for review. Produces a structured schema document covering an ER diagram, table DDL definitions, index strategy, access pattern analysis, normalization decisions, and migration notes.

Database Schema Design Skill

Produce a complete database schema design document for a given domain. A schema document is not just a list of tables — it is a record of decisions: what was modelled, how entities relate, which queries the schema is optimised for, and what trade-offs were made.

A good schema design document lets an engineer understand the data model, query it correctly, extend it safely, and write migrations without breaking things.

Required Inputs

Ask for these if not already provided:

  • Domain description — what the system does; what business objects are being modelled
  • Entities and relationships — the main things in the domain and how they relate (e.g. "a User has many Orders; an Order has many OrderItems; an OrderItem references a Product")
  • Expected query patterns — the most important read and write queries (e.g. "fetch all orders for a user, sorted by date"; "look up a product by SKU")
  • Database engine — PostgreSQL, MySQL, SQLite, CockroachDB, etc. — this affects DDL syntax and available types
  • Expected data volume — approximate row counts, growth rate, and any partitioning needs
  • Constraints — any existing conventions, naming standards, or migration constraints to respect

Output Format


Database Schema Design: [Domain / Service Name]

Service: [Name] | Team: [Team name] Author: [Name] | Reviewed by: [Name] Date: [Date] | Database engine: [PostgreSQL X.X / MySQL X.X / etc.] Status: [Draft / Reviewed / Approved]


1. Overview

[2–3 sentences describing the domain being modelled, the scope of this schema, and any key design philosophy (e.g. "this schema prioritises read performance for the customer-facing API over write simplicity", or "designed for eventual migration to multi-tenancy")]

In scope:

  • [Entity or subsystem]
  • [Entity or subsystem]

Out of scope:

  • [e.g. Analytics / reporting tables — separate schema]
  • [e.g. Audit log tables — covered in separate design doc]

2. Entity Relationship Diagram

┌───────────────────┐         ┌───────────────────────┐
│      users        │         │       organisations    │
│─────────────────  │         │─────────────────────── │
│ id (PK)           │    ┌───▶│ id (PK)                │
│ org_id (FK)  ─────┼────┘    │ name                   │
│ email             │         │ plan                   │
│ display_name      │         │ created_at             │
│ created_at        │         └───────────────────────┘
│ updated_at        │
└─────────┬─────────┘
          │ 1
          │
          │ N
┌─────────▼─────────┐         ┌───────────────────────┐
│      [table_a]    │         │      [table_b]         │
│─────────────────  │         │─────────────────────── │
│ id (PK)           │    N    │ id (PK)                │
│ user_id (FK) ─────┼────────▶│ [table_a]_id (FK)      │
│ [field]           │    │    │ [field]                │
│ [field]           │    │    │ [field]                │
│ created_at        │         │ created_at             │
└───────────────────┘         └───────────────────────┘

Relationship summary:

Entity ARelationshipEntity BNotes
organisationshas manyusersAn org can have many users
usershas many[table_a]Soft-deleted on user deletion
[table_a]has many[table_b]Cascade delete
[table_b]belongs to[table_a]Non-nullable FK
[table_c]many-to-many (via [join_table])[table_d]Join table with metadata

3. Table Definitions

organisations

[1 sentence describing what this table stores and its role in the domain.]

sql
CREATE TABLE organisations (
    id          UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
    name        VARCHAR(255)    NOT NULL,
    slug        VARCHAR(100)    NOT NULL UNIQUE,
    plan        VARCHAR(50)     NOT NULL DEFAULT 'free'
                                CHECK (plan IN ('free', 'pro', 'enterprise')),
    settings    JSONB           NOT NULL DEFAULT '{}',
    created_at  TIMESTAMPTZ     NOT NULL DEFAULT now(),
    updated_at  TIMESTAMPTZ     NOT NULL DEFAULT now()
);
ColumnTypeNullableDefaultNotes
idUUIDNogen_random_uuid()Surrogate PK — UUID preferred over serial for distributed use
nameVARCHAR(255)No—Display name; not unique
slugVARCHAR(100)No—URL-safe identifier; unique across all orgs
planVARCHAR(50)No'free'Constrained to known values via CHECK
settingsJSONBNo{}Flexible config; avoid for queryable fields
created_atTIMESTAMPTZNonow()Always use TIMESTAMPTZ, not TIMESTAMP
updated_atTIMESTAMPTZNonow()Updated via trigger (see below)

users

[1 sentence describing what this table stores.]

sql
CREATE TABLE users (
    id              UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id          UUID            NOT NULL REFERENCES organisations(id)
                                    ON DELETE RESTRICT,
    email           VARCHAR(254)    NOT NULL,
    display_name    VARCHAR(255)    NOT NULL DEFAULT '',
    role            VARCHAR(50)     NOT NULL DEFAULT 'member'
                                    CHECK (role IN ('owner', 'admin', 'member', 'viewer')),
    email_verified  BOOLEAN         NOT NULL DEFAULT false,
    deleted_at      TIMESTAMPTZ     NULL,
    created_at      TIMESTAMPTZ     NOT NULL DEFAULT now(),
    updated_at      TIMESTAMPTZ     NOT NULL DEFAULT now(),

    CONSTRAINT users_email_org_unique UNIQUE (email, org_id)
);
ColumnTypeNullableDefaultNotes
idUUIDNogen_random_uuid()—
org_idUUIDNo—FK to organisations; RESTRICT prevents orphaning
emailVARCHAR(254)No—RFC 5321 max length; unique per org (not globally)
roleVARCHAR(50)No'member'Application-level RBAC
deleted_atTIMESTAMPTZYesNULLSoft delete; NULL = active

Soft delete policy: Rows with deleted_at IS NOT NULL are considered deleted. All application queries MUST filter WHERE deleted_at IS NULL unless explicitly fetching deleted records. Use a view or ORM scope to enforce this.


[table_a]

[Description of what this table models.]

sql
CREATE TABLE [table_a] (
    id          UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id     UUID            NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    [field_1]   VARCHAR(255)    NOT NULL,
    [field_2]   TEXT            NULL,
    [field_3]   INTEGER         NOT NULL DEFAULT 0 CHECK ([field_3] >= 0),
    status      VARCHAR(50)     NOT NULL DEFAULT 'pending'
                                CHECK (status IN ('pending', 'active', 'archived')),
    metadata    JSONB           NOT NULL DEFAULT '{}',
    created_at  TIMESTAMPTZ     NOT NULL DEFAULT now(),
    updated_at  TIMESTAMPTZ     NOT NULL DEFAULT now()
);
ColumnTypeNullableNotes
user_idUUIDNoCASCADE delete — when user is deleted, their [table_a] rows are too
[field_1]VARCHAR(255)No[Reason for length constraint]
statusVARCHAR(50)NoState machine: pending → active → archived (no other transitions)
metadataJSONBNo[What is stored here and why it's not a typed column]

[join_table] (Many-to-many)

[Description of the relationship this table represents.]

sql
CREATE TABLE [join_table] (
    [table_c]_id    UUID        NOT NULL REFERENCES [table_c](id) ON DELETE CASCADE,
    [table_d]_id    UUID        NOT NULL REFERENCES [table_d](id) ON DELETE CASCADE,
    granted_by      UUID        NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
    granted_at      TIMESTAMPTZ NOT NULL DEFAULT now(),

    PRIMARY KEY ([table_c]_id, [table_d]_id)
);

Why a composite PK: The combination of [table_c]_id + [table_d]_id is the natural key — each association is unique and the primary key doubles as the uniqueness constraint without needing a separate index.


4. Index Strategy

For each table, define which indexes are created and why. Include the query they are designed to serve.

TableIndex nameColumnsTypeQuery servedNotes
usersusers_org_id_idx(org_id)B-treeSELECT * FROM users WHERE org_id = $1FK lookup; required for join performance
usersusers_email_lower_idx(lower(email))B-tree (functional)WHERE lower(email) = lower($1)Case-insensitive email lookup
usersusers_active_by_org_idx(org_id, created_at DESC)B-treeWHERE org_id = $1 AND deleted_at IS NULL ORDER BY created_at DESCPartial index candidate (see below)
[table_a][table_a]_user_id_status_idx(user_id, status)B-treeWHERE user_id = $1 AND status = 'active'Compound — order matters
[table_a][table_a]_metadata_gin_idxmetadataGINWHERE metadata @> '{"key": "value"}'Only add if JSONB queried frequently

Partial indexes (PostgreSQL):

sql
-- Index only active (non-deleted) users — dramatically smaller for soft-delete tables
CREATE INDEX users_active_email_idx
    ON users (email, org_id)
    WHERE deleted_at IS NULL;

-- Index only pending items — avoids indexing the majority of rows
CREATE INDEX [table_a]_pending_idx
    ON [table_a] (user_id, created_at)
    WHERE status = 'pending';

Index design principles applied:

  • FKs that appear in JOIN conditions always have an index
  • Compound indexes follow selectivity order: most selective column first
  • Functional indexes for case-insensitive lookups
  • GIN indexes only where JSONB containment queries are frequent
  • Partial indexes for status-filtered queries on large tables

5. Access Pattern Analysis

Document the primary queries this schema is designed to serve. For each, show the query, the indexes used, and any caveats.

AP-1: Fetch all active users for an organisation (paginated)

Frequency: Very high — called on every dashboard load Query:

sql
SELECT id, email, display_name, role, created_at
FROM users
WHERE org_id = $1
  AND deleted_at IS NULL
ORDER BY created_at DESC
LIMIT 50 OFFSET $2;

Index used: users_active_by_org_idx (org_id, created_at DESC) Notes: Use keyset pagination (WHERE created_at < $cursor) at scale; OFFSET degrades past ~10k rows.


Show full SKILL.md (517 more words)Show less
AP-2: Look up a user by email (case-insensitive)

Frequency: High — every authentication attempt Query:

sql
SELECT id, org_id, role, email_verified
FROM users
WHERE lower(email) = lower($1)
  AND deleted_at IS NULL;

Index used: users_email_lower_idx Notes: Returns multiple rows if same email exists across orgs. Application resolves by org context.


AP-3: Fetch [table_a] items for a user by status

Frequency: High Query:

sql
SELECT *
FROM [table_a]
WHERE user_id = $1
  AND status = $2
ORDER BY created_at DESC
LIMIT 25;

Index used: [table_a]_user_id_status_idx Notes: Compound index covers both filter columns. Status filter must come second in the index because user_id is more selective.


AP-4: [Add further access patterns as needed]

6. Normalization Decisions

Document deliberate choices to normalize or denormalize, with reasoning.

DecisionApproachReasoning
[e.g. Organisation name on users table?]Not denormalized — always join to organisationsAvoid stale copies; org name changes are infrequent and joining is cheap
[e.g. Status history]Not in this table — separate [table_a]_status_history if neededCurrent status is all that's needed for 99% of queries; history is auditing, not application data
[e.g. JSONB settings column on organisations]Denormalized into JSONBSettings are read together; never queried by field; schema changes don't require migrations
[e.g. Computed aggregate counts]Not stored — computed at query timeCounts are small; maintaining a counter column requires careful locking; use SELECT COUNT(*) with the index

7. Triggers and Automation

sql
-- Automatically update updated_at on any row modification
CREATE OR REPLACE FUNCTION set_updated_at()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = now();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Apply to all tables with updated_at
CREATE TRIGGER users_updated_at
    BEFORE UPDATE ON users
    FOR EACH ROW EXECUTE FUNCTION set_updated_at();

CREATE TRIGGER [table_a]_updated_at
    BEFORE UPDATE ON [table_a]
    FOR EACH ROW EXECUTE FUNCTION set_updated_at();

8. Migration Notes

If this schema is being introduced to an existing system, note the migration approach.

StepDescriptionBackward compatibleRisk
1Create organisations tableYes — additiveLow
2Create users tableYes — additiveLow
3Backfill org_id on existing usersRequires dual-write periodMedium
4Add NOT NULL constraint on org_idRequires backfill to be 100% completeMedium
5Remove deprecated columnsRequires app code updated firstLow once app deployed

Backfill strategy: [Describe how to handle existing data — batch size, rate limiting, validation queries]

Rollback: Each migration step should be independently reversible. See [database-migration-plan skill] for the full rollback procedure template.


Quality Checks

  • Every table has a primary key and a created_at column — no implicit ordering by row insertion
  • Every foreign key has a corresponding index — no missing FK indexes that would cause full table scans on joins
  • All TIMESTAMPTZ columns, not TIMESTAMP — timezone awareness is explicit
  • Soft-delete tables document the convention and where the filter is enforced (ORM scope, view, or query standard)
  • Every access pattern in the design has a supporting index or an explicit note that a full table scan is acceptable
  • JSONB columns are justified — not used as a substitute for proper schema design on queryable fields
  • Normalization decisions are documented with reasoning, not just stated
  • Migration notes address existing data if this is a schema change, not a greenfield schema

Anti-Patterns

  • Do not use JSONB columns as a substitute for proper relational schema design on fields that will be queried
  • Do not add indexes speculatively — every index must be justified by a specific access pattern
  • Do not omit timezone-awareness — use TIMESTAMPTZ, never plain TIMESTAMP
  • Do not design without documenting normalization decisions — future maintainers need the reasoning, not just the structure
  • Do not skip the access patterns section — schema without query patterns cannot be evaluated for correctness

Example Trigger Phrases

  • "Design a database."
  • "Document an existing schema."
  • "Model entities and relationships."
  • "Define table structures."
  • "Plan an index strategy."

© mohitagw15856, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/database-schema-design of mohitagw15856/pm-claude-skills.

Open the folder on GitHubat commit 1cbf1f0

Compare with similar skills

Database Schema Design next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Database Schema Design compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Database Schema Design this skillmohitagw15856/pm-claude-skills1.4k—~3.9kAutomated safety check: PassMIT
Datamodellmnimbalyst/nimbalyst1.9k—~713Automated safety check: PassMIT
Entity ModelAI-Unified-Process/marketplace141—~1.9kAutomated safety check: PassApache-2.0
Data ModelingProrise-cool/Claude-Code-Multi-Agent305—~3.2kAutomated safety check: PassNone
Understanding DB Schemaaiskillstore/marketplace430—~1.5kAutomated safety check: PassNone
Drizzle Erdhiroppy/mf-dashboard418—~627Automated safety check: PassMIT

Similar skills

  • Datamodellm

    nimbalyst/nimbalyst

    Create visual data models for database schemas using Nimbalyst's DataModelLM editor.

    1.9k GitHub stars~713 tokensUpdated yesterday
    DatabasesAuto-check passed
  • Entity Model

    AI-Unified-Process/marketplace

    Creates entity model documents with Mermaid.js ER diagrams and attribute tables defining entities, relationships, data types, and validation rules.

    141 GitHub stars~1.9k tokensUpdated 3 days ago
    DatabasesAuto-check passed
  • Data Modeling

    Prorise-cool/Claude-Code-Multi-Agent

    Data modeling with Entity-Relationship Diagrams (ERDs), data dictionaries, and conceptual/logical/physical models.

    305 GitHub stars~3.2k tokensUpdated 23 days ago
    DatabasesAuto-check passed
  • Understanding DB Schema

    aiskillstore/marketplace

    Deep expertise in Logseq's Datascript database schema. An agent skill from aiskillstore/marketplace.

    430 GitHub stars~1.5k tokensUpdated yesterday
    DatabasesAuto-check passed
  • Drizzle Erd

    hiroppy/mf-dashboard

    A skill your agent uses when needing to visualize database schema, generate ERD diagrams from Drizzle ORM schemas, or understand table relationships

    418 GitHub stars~627 tokensUpdated yesterday
    DatabasesAuto-check passed
  • Erd Studio Setup

    liam-machine/erd-studio

    Friendly, step-by-step setup for ERD Studio in an existing dbt project, for people who may be new to dbt or data modelling.

    165 GitHub stars~8.5k tokensUpdated yesterday
    Data & AnalyticsAuto-check passed

More from mohitagw15856/pm-claude-skills

All 1,322 skills in this repo
  • Exit Waterfall

    mohitagw15856/pm-claude-skills

    Compute who gets what at each exit price from a cap table — liquidation preferences, conversion points, and where the founders' share collapses.

    1.4k GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed
  • Feature Prioritisation

    mohitagw15856/pm-claude-skills

    Apply prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items.

    1.4k GitHub stars~2k tokensUpdated yesterday
    Auto-check passed
  • Freelance Rate

    mohitagw15856/pm-claude-skills

    Derive a freelance day/hourly rate backwards from target income, honest billable utilization, overhead, and the self-employment tax premium — the arithmetic that proves a rate is not salary÷2000.

    1.4k GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed
  • Offer Comparison

    mohitagw15856/pm-claude-skills

    Compare two or more job offers as total-comp curves over four years — vesting cliffs, bonuses, 401(k) match, and the crossover year computed, not vibed.

    1.4k GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed
  • Refinance Breakeven

    mohitagw15856/pm-claude-skills

    Compute the month a refinance actually starts saving money — payment delta, breakeven month, and total interest on both paths including the term-reset trap.

    1.4k GitHub stars~1k tokensUpdated yesterday
    Auto-check passed
  • Rent Vs Buy

    mohitagw15856/pm-claude-skills

    Model rent-vs-buy honestly — year-by-year net position for both paths including the assumption everyone drops (the renter invests the difference), with a breakeven horizon instead of a verdict.

    1.4k GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Database Schema Design

What does Database Schema Design do?

Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns. Database Schema Design is an agent skill from mohitagw15856/pm-claude-skills. Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns.

When should I use Database Schema Design?

Database Schema Design fits situations like: asked to design a database; document an existing schema; model entities and relationships; define table structures.

How do I install Database Schema Design in Claude Code?

Run `npx skills add mohitagw15856/pm-claude-skills --skill database-schema-design -a claude-code`. Or copy the skill folder (skills/database-schema-design in mohitagw15856/pm-claude-skills) into .claude/skills/database-schema-design in your project. Claude Code loads it when a task matches its description.

How do I install Database Schema Design in Codex?

Run `npx skills add mohitagw15856/pm-claude-skills --skill database-schema-design -a codex`. Or copy the skill folder (skills/database-schema-design in mohitagw15856/pm-claude-skills) into .agents/skills/database-schema-design in your project. Codex loads it when a task matches its description.

Can I use Database Schema Design in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mohitagw15856/pm-claude-skills --skill database-schema-design -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/database-schema-design, .gemini/skills/database-schema-design, .github/skills/database-schema-design and .opencode/skills/database-schema-design in your project.

What does Database Schema Design need to run?

SKILL.md names no scripts, command-line tools or credentials: Database Schema Design is instructions for the agent only.

Does Database Schema Design access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Database Schema Design safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Database Schema Design use?

Database Schema Design is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Database Schema Design use?

About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Database Schema Design?

Skills that share tags, products or a category with Database Schema Design: Datamodellm (nimbalyst/nimbalyst, 1.9k stars), Entity Model (AI-Unified-Process/marketplace, 141 stars), Data Modeling (Prorise-cool/Claude-Code-Multi-Agent, 305 stars) and Understanding DB Schema (aiskillstore/marketplace, 430 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Database Schema Design?

mohitagw15856 (a GitHub user) maintains it in mohitagw15856/pm-claude-skills, which has 1,431 GitHub stars. The repository holds 1,322 skills in this directory. The repository was last updated on October 7, 2026.

Source: mohitagw15856/pm-claude-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.