mcpField
C
checklist

checklist

github.com/hainrixzData & databases2271 installsUpdated 6d ago
Repository

About checklist

A read-only database production-readiness audit that maps findings to a fixed launch checklist and returns a GO, GO WITH CAVEATS, or NO-GO verdict. It helps teams assess database and schema risks without changing files or the database.

Key features

  1. 01Read-only database audit
  2. 02Fixed production-readiness checklist
  3. 03PASS, WARN, FAIL, and NEEDS-LIVE statuses
  4. 04Finding IDs linked to checklist rows
  5. 05Engine-aware N/A checks
  6. 06Launch verdict with blocker summary

Use cases

  1. 01Checking schema before production launch
  2. 02Identifying database reliability gaps
  3. 03Reviewing findings from an existing audit
  4. 04Distinguishing offline checks from live verification

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/hainrixz/claude-db --skill checklist

After installing, type/checklistin Claude Code to confirm it loaded.

Details

From the project README

/claude-db:checklist

A production-readiness GO/NO-GO grid. Read-only — runs an audit and maps the findings onto a fixed launch checklist; never writes files or mutates the database.

$ARGUMENTS = <path|connection-target> [flags]. The target is a repo path (schema/ORM/migration files) and, optionally, a live database via $DATABASE_URL for Tier-1/2 verification. If no target is given and no artifacts are found, say so and suggest /claude-db:start or /claude-db:design.

What to do

  1. Invoke the db-orchestrator skill with the target and --tier flag to run the read-only audit (stack detection → schema parse → auditor subagents → merged findings → scores). Reuse an existing findings.json if the user passes one.

  2. Map the merged findings onto the fixed checklist below. Each row gets a status — PASS (satisfied), WARN (non-blocking gap), FAIL (blocking gap), or NEEDS-LIVE (cannot be confirmed without a live connection / higher tier) — plus the finding id(s) that drive it.

    CheckWhat it verifies
    PITR / backupsPoint-in-time recovery or backup policy is configured — NEEDS-LIVE by default 1
    RLS on tenant tablesRow-level security enforced on multi-tenant tables
    FK indexesEvery foreign key column is covered by an index
    Money as numericMonetary columns use numeric/decimal, never float
    timestamptz / UTCTimestamps are timezone-aware and stored in UTC
    Connection pooling sizedPool is configured and sized for the platform's limits
    Migration reversibilityMigrations have working down/rollback paths
    Secrets not in schemaNo credentials/secrets embedded in schema or DDL
    charset / utf8mb4MySQL uses utf8mb4 (full Unicode), correct collation

  3. Render the grid as a table (Check · Status · Finding id · one-line note). Mark NEEDS-LIVE rows distinctly and state the tier needed to resolve them. Checks not applicable to the detected engine/paradigm (e.g. RLS or utf8mb4 on a non-relational store) are shown as N/A with a reason — never a silent pass.

  4. Lead with a plain-language verdict at the top: GO (no FAILs), GO WITH CAVEATS (WARNs/NEEDS-LIVE only), or NO-GO (one or more FAILs) — one sentence on the headline blocker.

End by offering: "Run /claude-db:fix to apply the safe, reversible fixes, or /claude-db:next to see what to tackle first." Read-only throughout. Respond in the user's language (EN/ES).

Footnotes

  1. No static module audits backups/DR/PITR, so this row is rendered NEEDS-LIVE by default — it can only be confirmed at Tier-1 (a live connection / provider config) and offline is reported as needs_api, never assumed present (never a silent PASS). ↩

Comments

Markdown supported