agentleFS
zazzcodezazzcode/zazz-skills/.agents/skills/psql/SKILL.md

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

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
  1. Distinctive:

    Use repo commands only for project-specific setup, migrations, fixtures, or test flows.

    line 9
  2. Distinctive:

    Prefer test, development, or disposable targets.

    line 44
  3. Very specific:

    Default to read-only queries, -X, -v ON_ERROR_STOP=1, and a short exploratory timeout.

    line 46
  4. Very specific:

    Default connection source: the project’s declared .env file or inherited environment variables.

    line 51
  5. Very specific:

    Prefer DATABASE_URL when available:

    line 56
  6. Very specific:

    Use -A -t for a scalar and --csv for tabular script output:

    line 76
  7. Very specific:

    Use one SQL string or one meta-command per -c.

    line 85
  8. Very specific:

    Prefer -f for a script file.

    line 86
  9. Very specific:

    Use -w only when noninteractive credentials are already configured.

    line 87
  10. Very specific:

    Use -v variables with :'name' for literals and :"name" for identifiers.

    line 88
  11. Very specific:

    Use the smallest validation query.

    line 93
  12. Distinctive:

    Use a read-only transaction for multi-query inspection when supported.

    line 95
  13. Very specific:

    Start with a plan estimate, then safe EXPLAIN ANALYZE, then existing workload stats.

    line 135
  14. Distinctive:

    Treat tuning as deliverable work: hypothesis, before/after evidence, regression checks, and required human approval.

    line 136
  15. Very specific:

    Use one meta-command per -c:

    line 141

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

TaskDefault approach
Confirm the connection and targetQuery current_database(), current_user, and version().
Inspect tables, columns, views, functions, or proceduresUse psql meta-commands or PostgreSQL catalogs.
Validate table or view dataRun a bounded SELECT and compare it with an explicit expected result.
Exercise a functionUse SELECT schema.function_name(...); compare the returned value or rows with the contract.
Exercise a procedureUse CALL schema.procedure_name(...) only on the intended non-production target and with authority for side effects.
Validate a migration or featureRun its declared setup, then inspect resulting schema and data.
Diagnose performance or locksLoad 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 unverified DELETE / 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 -c options or stdin for both.
  • Prefer -f for a script file; pair -1 with ON_ERROR_STOP for all-or-nothing scripts.
  • Use -w only when noninteractive credentials are already configured.
  • Use -v variables with :'name' for literals and :"name" for identifiers; never concatenate untrusted SQL.

Query And Validation Workflow

  1. Confirm the target database and environment class.
  2. Use the smallest validation query; add ORDER BY and LIMIT for row inspection.
  3. State the expected row count, value, presence/absence, shape, or invariant.
  4. Use a read-only transaction for multi-query inspection when supported.
  5. 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;
SQL

Example 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.

NeedRead
Profile one query, function, or procedure; inspect I/O, row estimates, or plan shapereferences/query-profiling.md
Find expensive workload statements; inspect pg_stat_statements / auto_explain; guide a human-run benchmarkreferences/workload-profiling.md
Inspect active sessions, waits, locks, pg_activity, or log-based pgBadger reportsreferences/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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.