Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/garrytan/gbrain/postgres-adoptnpx skills add garrytan/gbrain --skill postgres-adoptgit clone --depth 1 https://github.com/garrytan/gbrainWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00085 | $0.01400 |
| Opus 5 | $0.00043 | $0.00700 |
| Sonnet 5 | $0.00017 | $0.00280 |
| Haiku 4.5 | $0.00009 | $0.00140 |
Grade A, and why
postgres-adopt scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Postgres Adopt
The engine is the brain's foundation: PGLite is the zero-config floor, Postgres is where concurrency, multi-machine access, and 1000+ pages live. This skill answers "which one am I on?", prefers Postgres when the operator wants it, and moves data safely — never by flipping config.
Contract
This skill guarantees:
- Detection is engine-free and read-only:
gbrain engine status --jsonanswers with the database down (that is the point of the command). - Engine changes NEVER happen by editing config. Moving data uses
gbrain migrate --to <supabase|pglite>— which brings its own guardrails (quiesce mutex, resume manifest, non-empty-target guard, and a config flip only on a fully clean run). This skill wraps it; it never reimplements it. - Provisioning consent is explicit: the docker rung needs
--allow-docker, creating a database on a local server needs--allow-create-db. Headless mutation of infrastructure the operator didn't opt into never happens.
Step 1 — Detect
gbrain engine status --json
Branch on the output:
effective_engine: "postgres"and (optionally)--probesays ok → report healthy, done.effective_engine: "postgres"but the probe fails → this is an ACCESS problem, not an adoption problem: route to db-repair.config_file_enginediffers fromeffective_engine→ an env URL is overriding the config file; tell the operator which one wins — the signal isdb_url_source(env:GBRAIN_DATABASE_URL/env:DATABASE_URLmeans env wins;env.noteadditionally fires when both env URLs are set or the cwd-.env shadow guard excluded one).thin_client: true→ the brain lives on a remote server; engine choices belong to that host. Stop.effective_engine: null(no brain) → Step 2.effective_engine: "pglite"with data → Step 3.
Step 2 — Fresh install, Postgres-first
gbrain init --prefer-postgres
The ladder tries, in order: an env URL → Supabase Management-API discovery
(SUPABASE_ACCESS_TOKEN, plus SUPABASE_PROJECT_REF on multi-project
accounts and SUPABASE_DB_PASSWORD for the connection string) → a local
Postgres (only when PGHOST/PGPORT/PGUSER/PGPASSWORD are set or
--local-postgres is passed) → docker → PGLite. Each unusable rung prints a
one-line note and falls through; nothing is silent.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 131 lines · 85 tokens per session scan A 4c402527bd0d
postgres-adopt is a skill published in the GitHub repository garrytan/gbrain (29,440 stars, last pushed yesterday), licensed MIT. It adds 85 tokens to every session and 1,400 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
postgres-pro
Use when optimizing PostgreSQL queries, configuring replication, or implementing advanced database features. Invoke for EXPLAIN analysis, JSONB operations, extension usage, VACUUM tuning, performance monitoring.
postgres-database-migration
Use this skill for planning, testing, and safely executing PostgreSQL schema migrations — especially when working with production data or shared databases. Trigger when user asks to: Test a schema migration before applying it to production Add, remove, or rename columns safely on a live table Change a column's data…
setup-timescaledb-hypertables
Use this skill when creating database schemas or tables for Timescale, TimescaleDB, TigerData, or Tiger Cloud, especially for time-series, IoT, metrics, events, or log data. Use this to improve the performance of any insert-heavy table. Trigger when user asks to: Create or design SQL schemas/tables AND…
claimable-postgres
Provision instant temporary Postgres databases via Claimable Postgres by Neon (neon.new) with no login, signup, or credit card. Supports REST API, CLI, and SDK. Use when users ask for a quick Postgres environment, a throwaway DATABASEURL for prototyping/tests, or "just give me a DB now". Triggers include: "quick…
dsql
Build with Aurora DSQL — manage schemas, execute queries, handle migrations, diagnose query plans, diagnose cluster performance, load data, and develop applications with a serverless, distributed SQL database. Covers IAM auth, multi-tenant patterns, MySQL-to-DSQL and PostgreSQL-to-DSQL schema conversion, FK…
django-migrations
Django migration patterns and safety workflow for PostHog. Use when creating, adjusting, or reviewing Django/Postgres migrations, including non-blocking index/constraint changes, multi-phase schema changes, data backfills, migration conflict rebasing, and product model moves that require SeparateDatabaseAndState. Also…