What problem does it solve? When a project brief or design document calls for structured storage, developers often improvise inconsistent connection code, skip schema definitions, or silently swap the chosen database for a more familiar one. This Skill standardizes how SQLite, Postgres, or MongoDB is scaffolded so the store named in the design is the store that gets built. ## Core Features & Use Cases - Store-specific scaffolding: Creates a single small module (e.g. db.py) exposing only the operations the app needs, such as get(id), insert(record), and query(filter), so callers never touch the driver directly. - Grounded recommendations: During requirements interviews, recommends SQLite for local-first demos, Postgres only for concurrent writers or relational integrity needs, and MongoDB only for document-shaped records. - No mock mode enforcement: Treats a missing DATABASE_URL or MONGODB_URI as a hard stop rather than silently falling back to SQLite. - Use Case: A teaching demo brief specifies Postgres for a multi-user task tracker. The Skill adds psycopg[binary], writes a schema.sql with CREATE TABLE statements, scaffolds db.py, and documents reset steps in data/README.md. ## Quick Start Use the database skill to scaffold the Postgres connection, schema, and query module specified in my design document.
