psql
Skill4 starsChanged 3 months agoMITView on GitHub
Safely query, inspect, validate, and diagnose PostgreSQL from an agent shell. Use only when the project or target uses PostgreSQL; do not use for another database. Covers data/schema checks, views/functions/procedures, migrations, profiling, locks, and connection/quoting guidance.
- Reads credentials
1 other project uses a version of this.
Adopted by
Most recently taken up by
- matejformanek/postgres-claudetheir own version, first seen Jun 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- matejformanek/postgres-claude★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository21 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- architecture-doc-builderSkill
- confluenceSkill
- conformanceSkill
- doc-checkSkill
- feature-doc-builderSkill
- gh-issueSkill
- gh-stackSkill
- gh-wikiSkill
- handoffSkill
- jiraSkill
- pr-builderSkill
- proposal-builderSkill
- pr-reviewSkill
- qa-testingSkill
- spec-builderSkill
- spec-drivenSkill
- sqlcmdSkill
- standard-builderSkill
- worktreeSkill
- zazz-boardSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 4 are distinctive, and 11 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use repo commands only for project-specific setup, migrations, fixtures, or test flows.
- Distinctive: line 44
Prefer test, development, or disposable targets.
- Very specific: line 46
Default to read-only queries, -X, -v ON_ERROR_STOP=1, and a short exploratory timeout.
- Very specific: line 51
Default connection source: the project’s declared .env file or inherited environment variables.
- Very specific: line 56
Prefer DATABASE_URL when available:
- Very specific: line 76
Use -A -t for a scalar and --csv for tabular script output:
- Very specific: line 85
Use one SQL string or one meta-command per -c.
- Very specific: line 86
Prefer -f for a script file.
- Very specific: line 87
Use -w only when noninteractive credentials are already configured.
- Very specific: line 88
Use -v variables with :'name' for literals and :"name" for identifiers.
- Very specific: line 93
Use the smallest validation query.
- Distinctive: line 95
Use a read-only transaction for multi-query inspection when supported.
- Very specific: line 135
Start with a plan estimate, then safe EXPLAIN ANALYZE, then existing workload stats.
- Distinctive: line 136
Treat tuning as deliverable work: hypothesis, before/after evidence, regression checks, and required human approval.
- Very specific: line 141
Use one meta-command per -c:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
psql
psql is the standard interface for agent-driven PostgreSQL inspection and validation.
Use repo commands only for project-specific setup, migrations, fixtures, or test flows.
Common Tasks
| Task | Default approach |
| Confirm the connection and target | Query current_database(), current_user, and version(). |
| Inspect tables, columns, views, functions, or procedures | Use psql meta-commands or PostgreSQL catalogs. |
| Validate table or view data | Run a bounded SELECT and compare it with an explicit expected result. |
| Exercise a function | Use SELECT schema.function_name(...); compare the returned value or rows with the contract. |
| Exercise a procedure | Use CALL schema.procedure_name(...) only on the intended non-production target and with authority for side effects. |
| Validate a migration or feature | Run its declared setup, then inspect resulting schema and data. |
| Diagnose performance or locks | Load the targeted reference under Performance Profiling And Tuning. |
Human-Only Destructive Operations
Never execute destructive operations through this skill, even when requested. A Contributor Agent reports the operation and impact, then asks the Deliverable Owner or an approved human database operator to perform it manually after confirming target, backup/recovery, maintenance window, and impact. Do not provide a runnable command or workaround.
This includes:
- object drops or
CASCADE;TRUNCATE; broad or unverifiedDELETE/UPDATE; - restore, replace, clean, benchmark initialization, or database/schema reset;
- data-losing DDL, integrity/availability-affecting constraint or index removal;
- session cancellation/termination, lock forcing, or diagnostic-statistics reset; and
- server-wide configuration, ownership, privilege, persistence, or replication changes.
For a destructive test reset, record the manual action and wait for human-confirmed results before continuing.
Safety Defaults
- Prefer test, development, or disposable targets; never write to production.
- Load connection settings from repo configuration; never hardcode or expose secrets.
- Default to read-only queries,
-X,-v ON_ERROR_STOP=1, and a short exploratory timeout. - Redact secrets and personal data from output.
Invocation Pattern
Default connection source: the project’s declared .env file or inherited environment
variables. Read repo instructions before loading anything. Prefer DATABASE_URL; otherwise
use PGHOST, PGPORT, PGUSER, and PGDATABASE (with the project’s approved password
mechanism). Do not invent connection values or expose credentials.
Prefer DATABASE_URL when available:
psql -X "$DATABASE_URL" -v ON_ERROR_STOP=1 \
-c "select current_database(), current_user, version();"Otherwise use the repo's host, port, user, and database variables:
PGPASSWORD="$DB_PASSWORD" psql \
-X \
-h "$DB_HOST" \
-p "$DB_PORT" \
-U "$DB_USER" \
-d "$DB_NAME" \
-v ON_ERROR_STOP=1 \
-c "select version();"Use -A -t for a scalar and --csv for tabular script output:
psql -X "$DATABASE_URL" -v ON_ERROR_STOP=1 -A -t \
-c "select count(*) from information_schema.tables where table_schema = 'public';"Command Shape Rules
- Use one SQL string or one meta-command per
-c; use repeated-coptions or stdin for both. - Prefer
-ffor a script file; pair-1withON_ERROR_STOPfor all-or-nothing scripts. - Use
-wonly when noninteractive credentials are already configured. - Use
-vvariables with:'name'for literals and:"name"for identifiers; never concatenate untrusted SQL.
Query And Validation Workflow
- Confirm the target database and environment class.
- Use the smallest validation query; add
ORDER BYandLIMITfor row inspection. - State the expected row count, value, presence/absence, shape, or invariant.
- Use a read-only transaction for multi-query inspection when supported.
- Record the query and a redacted result summary. Command success alone is not evidence.
Example read-only validation session:
psql -X "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
begin read only;
set local statement_timeout = '30s';
select current_database(), current_user;
select id, status
from public.example_view
where id = 42
order by id
limit 10;
commit;
SQLExample scalar function assertion:
psql -X "$DATABASE_URL" -v ON_ERROR_STOP=1 -A -t \
-c "select public.compute_example_score(42);"For a procedure or another writing statement, name the target and side effect first. Use a
test transaction and ROLLBACK only when the routine does not manage its own transaction.
Performance Profiling And Tuning
Load only the reference needed. Do not enable extensions, change server configuration, run benchmarks, or process production logs merely to investigate.
| Need | Read |
| Profile one query, function, or procedure; inspect I/O, row estimates, or plan shape | references/query-profiling.md |
Find expensive workload statements; inspect pg_stat_statements / auto_explain; guide a human-run benchmark | references/workload-profiling.md |
Inspect active sessions, waits, locks, pg_activity, or log-based pgBadger reports | references/live-monitoring.md |
Start with a plan estimate, then safe EXPLAIN ANALYZE, then existing workload stats.
Treat tuning as deliverable work: hypothesis, before/after evidence, regression checks,
and required human approval.
Schema Inspection
Use one meta-command per -c:
psql -X "$DATABASE_URL" -c '\dt public.*'
psql -X "$DATABASE_URL" -c '\d+ public.example_table'
psql -X "$DATABASE_URL" -c '\df+ public.*'For scripting, query catalogs or information_schema:
psql -X "$DATABASE_URL" -v ON_ERROR_STOP=1 -A -F $'\t' \
-c "select column_name, data_type, is_nullable
from information_schema.columns
where table_schema = 'public' and table_name = 'example_table'
order by ordinal_position;"Output
Report target environment, command/query shape, redacted result summary, and profiling method when applicable.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

