How do I install the Pythia Explore skill?

Run npx skillmds@latest add thaildhe172591/pythia-explore in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pythia Explore safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pythia Explore?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pythia Explore free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pythia Explore?

thaildhe172591 (@thaildhe172591) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pythia Explore by thaildhe172591 — Agent Skill

Name: Pythia Explore
Author: thaildhe172591

Pythia Explore

Use when you need to understand anything in an Oracle schema - finding objects, reading PL/SQL source, signatures, table columns, DDL, searching code, or asking who uses what. ALSO use when a .sql file, dump, export, migration script or repo copy of an object appears to answer the question already, including one the developer points you at - because those files drift from the database and are wrong in ways that read as correct. The database is the only source of truth.

thaildhe172591 826eb48 2 files · 6.0 KB Updated Sep 17, 2026

File contents

Exploring the Schema

Announce at start: "Using pythia-explore — asking the database directly."

Phase: Learn

The principle: ask the database, never the dump

Repositories of exported .sql files go stale the day after export. A real mid-size system, audited in 2026, compared its repo dump against the live database:

Object type	In the dump	In the database	Verdict
Procedures	3,827	3,827	matched
Tables	952	952	matched
Types	0	115	all missing
Packages	0	9	all missing
Indexes	116	1,016	~89% missing

Code that "reads fine" against the dump can reference types and packages the dump never heard of.

When the developer hands you a .sql file — "explain this procedure", "here is the export, what does it do" — the file is a claim, not the truth. Read it, then run pythia src <NAME> and answer from the database. If the two differ, say so first: which is newer is exactly what the developer needs to know, and it is invisible from the file alone. Never answer about a database object from a file alone while the database is reachable.

Read files as the answer only when the database is unreachable — and say that is what you are doing.

What you need → what you run

Need	Command
Is the connection alive, what schema	`pythia check`
Find objects by name	`pythia ls "PKG_%"`
Read source, with the compiler's line numbers	`pythia src NAME` (`--body`, `--spec`)
A procedure/function signature	`pythia args NAME`
Columns and real data types	`pythia cols TABLE_NAME`
Full DDL	`pythia ddl TABLE NAME`
Search all PL/SQL text	`pythia grep "text"`
What an object depends on	`pythia deps NAME`
What depends on an object	`pythia impact NAME`
Exact identifier usages (beats grep)	`pythia plscope NAME`
Programs named like this one	`pythia similar NAME`
Everything currently broken	`pythia invalid`, `pythia errors`
A free-form question	`pythia sql "select ..."` (SELECT/WITH only)

Rules that keep answers honest

Truncation is always announced. Outputs end with -- truncated ... or set "truncated": true in --json. If you do not see the marker, you saw everything; if you do, say so or fetch more (--limit, --offset, --max-lines) — never present a truncated list as complete.
plscope before grep for "where is X used": PL/Scope is recorded by the compiler and exact; grep matches comments and look-alike names. If PL/Scope has no data, the command says so and grep is the fallback.
src line numbers are the compiler's own — an error at line 47 means line 47 in src output. No offset arithmetic.
Default output caps exist to protect your context window; raise them only for the object you are actually working on.

Deeper reference — which dictionary views back these commands, PL/Scope enablement, licensing boundaries: reference/data-dictionary.md.

---name: pythia-exploredescription: Use when you need to understand anything in an Oracle schema - finding objects, reading PL/SQL source, signatures, table columns, DDL, searching code, or asking who uses what. ALSO use when a .sql file, dump, export, migration script or repo copy of an object appears to answer the question already, including one the developer points you at - because those files drift from the database and are wrong in ways that read as correct. The database is the only source of truth.---# Exploring the Schema**Announce at start:** "Using pythia-explore — asking the database directly."**Phase:** Learn## The principle: ask the database, never the dumpRepositories of exported `.sql` files go stale the day after export. A realmid-size system, audited in 2026, compared its repo dump against the livedatabase:| Object type | In the dump | In the database | Verdict ||---|---|---|---|| Procedures | 3,827 | 3,827 | matched || Tables | 952 | 952 | matched || **Types** | **0** | **115** | **all missing** || **Packages** | **0** | **9** | **all missing** || **Indexes** | **116** | **1,016** | **~89% missing** |Code that "reads fine" against the dump can reference types and packages thedump never heard of.**When the developer hands you a `.sql` file** — "explain this procedure","here is the export, what does it do" — the file is a claim, not the truth.Read it, then run `pythia src <NAME>` and answer from the database. If thetwo differ, say so first: which is newer is exactly what the developer needsto know, and it is invisible from the file alone. Never answer about adatabase object from a file alone while the database is reachable.Read files as the answer only when the database is unreachable — and saythat is what you are doing.## What you need → what you run| Need | Command ||---|---|| Is the connection alive, what schema | `pythia check` || Find objects by name | `pythia ls "PKG_%"` || Read source, with the compiler's line numbers | `pythia src NAME` (`--body`, `--spec`) || A procedure/function signature | `pythia args NAME` || Columns and real data types | `pythia cols TABLE_NAME` || Full DDL | `pythia ddl TABLE NAME` || Search all PL/SQL text | `pythia grep "text"` || What an object depends on | `pythia deps NAME` || What depends on an object | `pythia impact NAME` || Exact identifier usages (beats grep) | `pythia plscope NAME` || Programs named like this one | `pythia similar NAME` || Everything currently broken | `pythia invalid`, `pythia errors` || A free-form question | `pythia sql "select ..."` (SELECT/WITH only) |## Rules that keep answers honest- **Truncation is always announced.** Outputs end with `-- truncated ...` or set `"truncated": true` in `--json`. If you do not see the marker, you saw everything; if you do, say so or fetch more (`--limit`, `--offset`, `--max-lines`) — never present a truncated list as complete.- **`plscope` before `grep`** for "where is X used": PL/Scope is recorded by the compiler and exact; grep matches comments and look-alike names. If PL/Scope has no data, the command says so and grep is the fallback.- **`src` line numbers are the compiler's own** — an error at `line 47` means line 47 in `src` output. No offset arithmetic.- Default output caps exist to protect your context window; raise them only for the object you are actually working on.Deeper reference — which dictionary views back these commands, PL/Scopeenablement, licensing boundaries: `reference/data-dictionary.md`.

Frequently asked questions