data

/dotclaude:data — database + persistent-state discipline kit

You are setting up the data layer's audit + safety discipline. The output is a .claude/ subset focused on what code review and tests can't catch: latent corruption / drift / orphans in the actual data, migration safety, query cost, and access-policy correctness.

The data-auditor agent runs the five-category integrity sweep; the migration-create skill enforces the four-step migration workflow; the query-discipline rule prevents the unbounded-MCP-DB-read class of token waste.

Phase 1 — Read the project's data shape

Before any question:

1. DB platform + ORM / framework — read whichever exists:

   cat package.json 2>/dev/null | grep -E "supabase|prisma|drizzle|knex|sequelize|typeorm|mongodb|mongoose|sqlite|pg|mysql"
   cat Cargo.toml 2>/dev/null | grep -E "sqlx|diesel|sea-orm|tokio-postgres"
   cat pyproject.toml 2>/dev/null | grep -E "alembic|sqlalchemy|django|asyncpg|psycopg|pymongo"
   cat go.mod 2>/dev/null | grep -E "gorm|sqlx|ent|mongo-go-driver"
   

2. Migration directory — find it:

   ls migrations/ db/migrations/ supabase/migrations/ alembic/versions/ 2>/dev/null
   find . -path ./node_modules -prune -o \( -name "*.sql" -o -name "*migration*" \) -print 2>/dev/null | head -20
   

   Note the convention: how migrations are named, whether they include UP + DOWN, whether they include access-policy blocks alongside DDL.

3. Schema files — find canonical schema sources:

   ls schema.sql schema.prisma drizzle/schema.* 2>/dev/null
   find . -name "*.types.ts" -path "*db*" -o -name "database.types.ts" 2>/dev/null | head
   

4. Access-control signal — does the project use RLS / equivalent?

   # Postgres RLS
   grep -rn "row level security\|enable rls\|create policy" migrations/ db/ supabase/ 2>/dev/null | head
   # Application-layer auth
   grep -rn "tenant_id\|workspace_id\|owner_id" --include="*.ts" lib/ src/ 2>/dev/null | head