Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/jpicklyk/task-orchestrator/check_schema_versiongit clone --depth 1 https://github.com/jpicklyk/task-orchestratorWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00014 | $0.00598 |
| Opus 5 | $0.00007 | $0.00299 |
| Sonnet 5 | $0.00003 | $0.00120 |
| Haiku 4.5 | $0.00001 | $0.00060 |
Grade A, and why
check_schema_version scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Check the schema version of the Task Orchestrator database on a Docker volume.
Instructions
- Parse the volume name from the user's command, defaulting to "mcp-task-data" if not provided
- Create a temporary SQL file with the query
- Run the Docker command mounting both the volume and the project directory
- Display the results in a clear, formatted way
- Clean up the temporary SQL file
Working Pattern (Windows Git Bash Compatible)
Due to shell escaping issues on Windows, use a mounted SQL file approach:
Step 1: Create temporary SQL file in project root:
-- File: .tmp_check_schema.sql (in project root directory)
.mode box
.headers on
SELECT
installed_rank,
version,
description,
type,
script,
installed_on,
execution_time,
success
FROM flyway_schema_history
ORDER BY installed_rank DESC
LIMIT 10;
Temp File Location: Create .tmp_check_schema.sql in the project root directory (D:\Projects\task-orchestrator)
Step 2: Run via Docker with mounted SQL file:
powershell.exe -Command "docker run --rm -v {{VOLUME_NAME}}:/data -v '${PWD}:/work' alpine sh -c 'apk add --no-cache sqlite >/dev/null 2>&1 && sqlite3 /data/tasks.db < /work/.tmp_check_schema.sql'"
Step 3: Clean up:
rm .tmp_check_schema.sql
Note: The alpine/sqlite image doesn't work well with inline SQL on Windows. Use alpine with sqlite installed instead.
Expected Output Format
Present the results with:
- Current schema version (the most recent migration)
- List of recent migrations (up to 10)
- Success status for each migration
- Installation timestamps
If the query fails:
- Explain that the volume may not exist, or
- The database may not have been initialized with Flyway, or
- The database file doesn't exist yet
Additional Helpful Commands
After showing the results, offer these follow-up options:
- Show all migrations: Remove the LIMIT from the SQL query
- Show table structure: Create SQL file with
.schema flyway_schema_history - Show all tables: Create SQL file with
.tables - Check database file:
docker run --rm -v {{VOLUME_NAME}}:/data alpine ls -lh /data/
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 89 lines · 14 tokens per session scan A 01a317d2792f
check_schema_version is a command published in the GitHub repository jpicklyk/task-orchestrator (205 stars, last pushed 29d ago), licensed MIT. It adds 14 tokens to every session and 598 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
f5-db
Database operations and migrations.
dejavu-pg-rescue
Postgres corruption rescue toolkit — scan, patch-toast, reset-flags, rebuild-table, reindex. Codifies the 2026-05-14 disk-full rescue playbook.
dejavu-rescue
Rescue a corrupted Weaviate shard by walking its LSM segments, recreating the class, restoring records, and gap-reindexing from Postgres canonical.
dejavu-weaviate-rescue
Weaviate corruption rescue toolkit — scan, quarantine-segment, redo-class. Codifies the 2026-05-14 LSM-segment rescue playbook.
dejavu-db
Check or browse database schema (Prisma / Drizzle / TypeORM / SQL) — catches typos and fabricated table/column references.
dejavu-reindex
(Re)index the current project's source files into the symbol grounding database.