ワンクリックで
db
Interact with the TMI PostgreSQL database for queries and administration. Use when asked to show data, check tables, or run SQL queries.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Interact with the TMI PostgreSQL database for queries and administration. Use when asked to show data, check tables, or run SQL queries.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Run the TMI comprehensive test suite including unit tests, integration tests, API tests, and CATS security fuzzing. Use when asked to run tests, verify code changes, or check for regressions.
Run the TMI comprehensive test suite against Oracle ADB (OCI) including unit tests, integration tests, API tests, and CATS security fuzzing. Use when asked to run tests against Oracle database.
Scan staged or branch changes for reintroduction of previously-fixed TMI security vulnerabilities (SSRF/DNS-rebinding, open redirect, verbose-error 500s, OTLP data leak, OAuth brute-force, PATCH privilege escalation, etc.). MANDATORY before any commit that touches security-sensitive code paths — outbound HTTP, OAuth/auth handlers, PATCH endpoints, span/trace instrumentation, error-classification, or any handler returning a redirect. Use whenever the user asks to "commit", "push", "open a PR", "finish", "land", or "ship" code, when finishing a development branch, or proactively before reporting any security-adjacent change as complete. Also use when explicitly asked to run a "security regression check", "regression scan", or "check for regressions of fixed CVEs".
Dispatch the oracle-db-admin subagent to review changes that can affect Oracle Database compatibility. Use whenever the working set includes GORM model/schema files (api/models/*.go), struct tags affecting columns/indexes/constraints, repository/store code, raw SQL via db.Raw/db.Exec, transaction or locking patterns, JSON/CLOB handling, foreign-key or cascade design, retry/error-classification code (internal/dberrors/), or schema-affecting config. Invoke BEFORE reporting the change as complete; the subagent's verdict (APPROVED, APPROVED WITH NOTES, or BLOCKING ISSUES) must be addressed.
File a bug report against the TMI client (tmi-ux) when a problem is identified as a client-side issue. Creates a GitHub issue in ericfitz/tmi-ux, adds it to the TMI project, and sets status to In Progress.
| name | db |
| description | Interact with the TMI PostgreSQL database for queries and administration. Use when asked to show data, check tables, or run SQL queries. |
| allowed-tools | Bash, Read |
You are helping the user interact with the TMI PostgreSQL database.
IMPORTANT: All database connection information and credentials are stored in config-development.yml:
PostgreSQL command-line tools (psql) are NOT installed on the host machine.
You MUST use docker exec to run psql commands inside the tmi-postgresql container.
To start an interactive psql session:
docker exec -it tmi-postgresql psql -U tmi_dev -d tmi_dev
To run a single SQL query:
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "YOUR SQL QUERY HERE"
To execute SQL from a file:
docker exec -i tmi-postgresql psql -U tmi_dev -d tmi_dev < /path/to/file.sql
Or using heredoc:
docker exec -i tmi-postgresql psql -U tmi_dev -d tmi_dev <<'EOF'
YOUR SQL QUERY HERE
EOF
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "\dt"
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "\d table_name"
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "SELECT COUNT(*) FROM table_name;"
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "SELECT * FROM table_name LIMIT 10;"
The database schema is managed by GORM AutoMigrate(), driven by the struct tags
in api/models/*.go — there are no standalone SQL migration files. The schema is
applied automatically on server startup (make dev-up). Legacy SQL migrations
are archived under docs/reference/legacy-migrations/ for historical reference only.
To reset the local dev database (drop and recreate schema):
make reset-database # Drop and recreate the local dev schema
For the Heroku database, use make reset-db-heroku (DESTRUCTIVE).
To clear automatically generated test data (test users with @tmi.local
emails, test groups, and CATS-seeded artifacts) out of the development database
without dropping and recreating it:
make test-db-cleanup
Note: this runs scripts/delete-test-users.py, which deletes via the admin API
(not direct SQL), so the TMI server must be running and the
charlie@tmi.local admin account must exist. It cascades related data and
preserves charlie@tmi.local.
Key tables in the TMI database:
users - User accounts and authenticationthreat_models - Top-level threat model entitiesdiagrams - Threat model diagrams (DFD, etc.)cells - Diagram cells (nodes and edges)threats - Identified threatsdocuments - Document attachmentsrepositories - Code repository linksnotes - Text notesassets - Asset inventory itemsmetadata - Flexible key-value metadata for entitiesdocker ps --filter "name=tmi-postgresql"
docker exec -i tmi-postgresql psql -U tmi_dev -d tmi_dev <<'EOF'
SELECT * FROM table_name WHERE condition = 'value';
EOF
If you encounter errors:
make start-database (this is all the psql commands above need). make dev-up also starts it, but additionally brings up the full kind dev environment (cluster + server + Redis) — use that only if you want the whole stack.docker psconfig-development.ymlmake migrate-databaseconfig-development.yml are for local development onlydev123) is intentionally simple for local developmentdocker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "
SELECT tm.id, tm.name, u.email AS owner, tm.created_at
FROM threat_models tm
JOIN users u ON u.internal_uuid = tm.owner_internal_uuid
ORDER BY tm.created_at DESC
LIMIT 5;
"
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "
SELECT a.id, a.name, a.type, tm.name as threat_model
FROM assets a
JOIN threat_models tm ON a.threat_model_id = tm.id
WHERE a.type = 'software';
"
The schema is managed by GORM AutoMigrate() (see "Schema Migrations" above),
so there is no per-migration history table. The current schema state is recorded
as a single-row fingerprint stamp in tmi_schema_versions (id, a SHA-256
fingerprint of the GORM model set, and applied_at):
docker exec tmi-postgresql psql -U tmi_dev -d tmi_dev -c "
SELECT id, fingerprint, applied_at
FROM tmi_schema_versions;
"
(The schema_migrations table, columns version/dirty, is a vestigial
golang-migrate artifact and is not used by GORM AutoMigrate.)
When the user asks to:
make reset-database (local), make test-db-cleanup (clear test data only), or specific DELETE queriesAlways show the user the SQL query you're about to execute before running it, especially for INSERT, UPDATE, or DELETE operations.