agentsclimarketplace

Database basics

Skill protosphinx/sphinxstack/skills/database-basics

A stack of skills for your AI agent, made for people starting from zero. 103 skills and 149 project briefs — load one into Codex, Claude Code, Copilot, Gemini, or Cursor and do the thing.

Install
npx -y skills add protosphinx/sphinxstack --skill database-basics

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 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

Give their app real persistence with a hosted database. A free-tier Postgres or SQLite, a schema for their actual data, and full CRUD from their app. Use when localStorage stops being enough, when data must survive across devices or users, or when they ask "how do I store this properly".

SKILL.md

3.3 KB, 692 tokens by cl100k_base, as published. Nobody here has run it

database-basics

Move someone's app from localStorage to a real database: a hosted free-tier database with a schema designed around their actual data, and their app reading and writing it. The durable lesson is modeling. Tables, rows, and types that match the thing they are tracking.

Ground rules

  • Use their real data. The best schema exercise is the app they already built (build-web-app leaves exactly this). If they have no app, pick one small enough that the whole loop still fits in a session.
  • Compare the current official plans for a hosted Postgres or SQLite service, or use SQLite on a server they already control. Record storage, inactivity, export, and backup limits before committing. No card details anywhere.
  • Their account, their connection string. Database URLs and service keys are secrets: env vars on the server side, gitignored .env locally, never in frontend code. If they use Supabase from the browser, explain which key is publishable and which must never ship, and turn on row-level security before any write works.
  • Design the schema on paper first. One entry becomes one row; every field gets a type; you both say why. Two tables maximum, and only add the second when a real one-to-many appears in their data.
  • SQL is not optional. Even behind a client library, they type at least the CREATE TABLE and a few SELECTs by hand in the database console, so they can inspect the layer underneath the client library.

The path

  1. Model out loud: what is one entry, what are its fields, what type is each, what makes a row unique. Write the CREATE TABLE together and run it in the provider's SQL console.
  2. Seed and query by hand: INSERT three rows, SELECT them back, UPDATE one, DELETE one, all in the console. Now the database is real before any app code touches it.
  3. Connect from their code with the connection string in an env var. First read: the app lists rows from the database instead of localStorage.
  4. Complete the loop: create, update, delete from the app. Bad input rejected before it reaches the database, and a NOT NULL or type error triggered once on purpose so they see the database defend itself.
  5. Prove persistence: redeploy the app, open it on their phone, data still there. Delete localStorage use from the code.
  6. README note in their words: what the schema is and where the connection string lives for anyone cloning.
  7. Export a small backup or schema dump and document how it would be restored.

Done

  • A hosted database with a schema they designed and can explain
  • Their app doing full CRUD against it; localStorage retired
  • Data survives redeploys and shows up across devices
  • Connection string and keys in env vars only, proven absent from git
  • A tested export path and restore note, so the provider is not the only copy
  • They can write a SELECT with a WHERE clause unaided

Then: auth-basics, since data shared by everyone raises the question of who is allowed to see and change which rows.

What ships with it: 1 file

211 B alongside SKILL.md

agents/

Gives 0 of the 12 instructions most databases sql skills give in 692 tokens

Counted across 589 of the 662 authors here whose files we hold, read 2026-08-07

  • Use parameterized queriesin 37 of 589, across 34 files
  • Use timestamptz for timestampsin 30 of 589, across 14 files
  • Index foreign keysin 29 of 589, across 18 files
  • Create indexes concurrentlyin 29 of 589, across 24 files
  • Use numeric type for moneyin 25 of 589, across 8 files
  • Use cursor pagination instead of offsetin 24 of 589, across 17 files
  • Select only required columnsin 24 of 589, across 20 files
  • Add indexes manually on foreign key columnsin 22 of 589, across 12 files
  • Normalize to third normal formin 19 of 589, across 10 files
  • Configure connection poolingin 19 of 589, across 17 files
  • Put equality columns before range columns in indexesin 18 of 589, across 10 files
  • Read individual rule files for detailed explanationsin 18 of 589, across 4 files

Said here and by no other author read

  • use their real data
  • compare official database plans before committing
  • design the schema on paper first
  • limit to two tables maximum
  • write create table statements by hand
  • connect using an environment variable

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,984. 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.