agentsclimarketplace

Go database

Skill nyquistwilder/personal-pi/skills/go-database

My personal pi harness configuration.

Install
npx -y skills add nyquistwilder/personal-pi --skill go-database

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.

What its author says it does

Copied from the file, not written here

Greenfield Go database workflow for database/sql, pgx, migrations, transactions, pooling, query correctness, test databases, and safe data boundaries.

SKILL.md

2.5 KB, as published. Nobody here has run it

Go Database

Rule

Make persistence explicit, transactional, context-aware, and isolated from real mutable systems. Keep SQL close enough to review and data access behind small boundaries.

Hard Stops

Stop before:

  • Touching production or developer databases without explicit approval and backup/safety plan.
  • Running destructive migrations, changing schema, or changing data retention semantics without rollback and compatibility discussion.
  • Adding an ORM, query generator, migration tool, or container dependency without approval.
  • Using real credentials or committing generated secrets.

Defaults

  • Use database/sql for generic SQL access and jackc/pgx/v5 for PostgreSQL driver/pool needs.
  • Prefer explicit SQL and small repository/store types over full ORMs in greenfield Go.
  • Use golang-migrate/migrate/v4 for versioned SQL migrations when migration tooling is needed.
  • Pass contexts into queries and transactions.
  • Make transaction boundaries explicit; do not hide large workflows in auto-transactions.
  • Map database errors to domain errors at the data boundary.
  • Configure pool limits and timeouts intentionally.

Testing

Use isolated test databases, transaction rollbacks, temporary schemas, or approved testcontainers-go when real database behavior matters. Do not use production-like shared state by default. Test migrations up/down when the tool supports it, constraints, not-found behavior, uniqueness conflicts, and transaction rollback.

Workflow

  1. Define schema, migrations, queries, transaction boundaries, indexes, and failure behavior.
  2. Choose stdlib database/sql, pgx, or project-approved tool based on needs.
  3. Implement data access behind a small interface or concrete store consumed by services.
  4. Add isolated tests and fixtures.
  5. Run migrations/tests, go test ./..., race tests for concurrent DB use, lint, and just check.

Antipatterns

  • Building SQL with string concatenation and untrusted input.
  • Global DB handles hidden in packages.
  • Ignoring rows.Err() or leaking Rows/transactions.
  • N+1 queries without measurement or accepted tradeoff.
  • Tests that depend on a developer's local database.

Completion

Report schema/query changes, transaction model, tool choices, test database approach, commands, and safety boundaries.

Keep looking

Skills are one crate of 328,083. 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.