agentsclimarketplace
Sign in

Checklist

Skill Hainrixz/claude-db/skills/checklist

Render a production-readiness GO/NO-GO grid for a database — runs a read-only audit, then maps the findings onto a fixed launch checklist (PITR/backups, RLS on tenant tables, FK indexes, money-as-numeric, timestamptz/UTC, connection pooling sized, migration reversibility, secrets-not-in-schema, charset/utf8mb4). Each row is PASS/WARN/FAIL/NEEDS-LIVE with the finding id, topped by a plain-language verdict. Read-only. Use when the user asks if a database is production-ready, ready to launch/ship, a go/no-go, a pre-launch or readiness checklist, or what to fix before going live.From its SKILL.md

Install
npx -y skills add Hainrixz/claude-db --skill checklist

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

  • 19 stars19 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.4 KB, as published. Nobody here has run it

/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). ↩

Keep looking

Skills are one crate of 627,801. 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.