Design and review persistence, queries, schemas, transactions, and data access using framework-agnostic database principles.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add soden46/engineer-flow --skill database --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Database?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/soden46-database)More formats (shields.io, HTML) on the badges page.
---
name: database
description: Design and review persistence, queries, schemas, transactions, and data access using framework-agnostic database principles.
metadata:
internal: true
---
# Database
Use this skill for persistence, queries, schema changes, migrations, transactions, data integrity, and data-access behavior.
This skill is language, ORM, and database framework agnostic.
## Data Integrity
Enforce important invariants at the strongest practical layer.
Use appropriate:
- constraints
- uniqueness rules
- foreign keys
- nullability
- validation
- transaction boundaries
Application validation does not replace database integrity where concurrent writes can violate an invariant.
## Queries
Prefer structured and parameterized query mechanisms.
Avoid:
- unbounded reads
- unnecessary columns
- repeated identical queries
- N+1 access patterns
- avoidable full scans
- query construction from untrusted input
Inspect the actual workload before adding optimization complexity.
## Transactions
Use transactions when multiple operations must succeed or fail as one logical change.
Keep transaction scopes as small as practical.
Consider:
- partial failure
- retries
- deadlocks
- external side effects
- long-running work
Do not hold database transactions open while performing unnecessary external operations.
## Concurrency
When correctness depends on concurrent access, explicitly consider:
- lost updates
- duplicate creation
- stale reads
- locking
- atomic operations
- optimistic concurrency
- idempotency
Do not assume application-level checks remain valid between read and write.
## Schema Changes
Schema changes should consider:
- backwards compatibility
- existing data
- nullability
- defaults
- index creation
- rollout ordering
- rollback strategy
- large table impact
For risky migrations, prefer staged changes.
## Data Access Boundaries
Keep persistence concerns separate from unrelated presentation or transport logic.
Avoid leaking database-specific details throughout the application when an established data-access boundary exists.
## Verification
Relevant checks may include:
- correct persisted state
- constraint enforcement
- transaction rollback
- concurrent behavior
- query count
- execution plan
- migration safety
- backwards compatibility
## Framework Adaptation
Use the project's native ORM/query/database mechanisms when suitable.
Stack-specific guidance may provide implementation details but must not weaken data-integrity requirements.Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!