Menu

Individual skill

schema-exploration

0upvotes

Explore an existing PostgreSQL database before answering questions about its data or writing SQL. Use this skill whenever a user asks for a query or a data-backed answer against an unfamiliar schema (counts, missing or failed records, recent changes), asks where a business concept lives, or asks how tables, joins, views, routines, triggers, RLS, or extensions work. Find the relevant objects with read-only pg_catalog queries, then request approval before inspecting data-derived statistics or rows. Not a schema-design or migration guide.

skills/schema-exploration/SKILL.md

Read pinned source

Source commit c39008a2773f75d63037e8eecf937456204786ba

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 7, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,885
Repository last updated
Nov 8, 2026
License
Apache-2.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Explore a PostgreSQL database

Start with the user's question, not a full-database audit unless that is the explicit ask. Use the database connection already available to you; if none is available, ask for access or work from provided schema files. Stay within the database and schemas the user has authorized. Catalog metadata can reveal sensitive names or source code: do not export it unnecessarily.

## Workflow

1. Establish the current database, server version, role, and scope. Use [overview](references/overview.md) for a small inventory. Choose relevant schemas; do not assume `public` contains the application.
2. Pick the most promising object(s) and read **only** the matching drill-down reference: [tables](references/tables.md), [partitioning/inheritance](references/partitioning-and-inheritance.md), [foreign tables](references/foreign-tables.md), [views](references/views.md), [routines](references/routines.md), [triggers](references/triggers.md), [security/RLS](references/security.md), or [extensions](references/extensions.md). Follow cross-references only when the question requires them.
3. Corroborate meaning with comments, definitions, keys, and known dependencies. Names are clues, not proof of business meaning. If data-derived values would help, use [data-derived values](references/data-values.md) **only after obtaining approval** for the specific columns and access method. Ask the user when semantics remain ambiguous.
4. If the user wants SQL, follow [query authoring](references/query-authoring.md): establish join keys and grain, then validate a vetted read-only query with plain `EXPLAIN` where authorized. Do not mistake a valid plan for proof of business semantics.
5. Stop once you can answer. Report the specific schema-qualified objects and evidence, distinguish observations from inferences, and state limitations (permissions, stale statistics, missing dependencies, unknown application logic).

## Example finding