check_schema_version

A command that reads the recorded Flyway database-migration history from a SQLite database stored on a Docker volume. Flyway is a tool that applies and tracks database structure changes.

In plain words
What is it for?
Use it to inspect recent migration versions, descriptions, scripts, dates, runtimes, and success states for the Task Orchestrator database.
Why use it?
It shows which schema changes have run, helping you check whether the database is up to date and whether a migration failed.

Command for Claude Code

Install

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.

agentmods
npx agentmods add commands/jpicklyk/task-orchestrator/check_schema_version
Clone the repo
git clone --depth 1 https://github.com/jpicklyk/task-orchestrator

Made for: Claude Code.

Per session 14 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 598 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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

ModelPer sessionOnce 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

Measured 3d ago against content hash 01a317d2792f, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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.

.claude/commands/check_schema_version.md · 89 lines

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

  1. Parse the volume name from the user's command, defaulting to "mcp-task-data" if not provided
  2. Create a temporary SQL file with the query
  3. Run the Docker command mounting both the volume and the project directory
  4. Display the results in a clear, formatted way
  5. 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:

  1. Show all migrations: Remove the LIMIT from the SQL query
  2. Show table structure: Create SQL file with .schema flyway_schema_history
  3. Show all tables: Create SQL file with .tables
  4. Check database file:
    docker run --rm -v {{VOLUME_NAME}}:/data alpine ls -lh /data/
    

Read the full file on GitHub · 89 lines

Changes

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.

  1. 3d ago First seen · 89 lines · 14 tokens per session scan A 01a317d2792f

Subscribe to this mod's changes

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.