How do I install the Schema Change skill?

Run npx skillmds@latest add kagkarlsson/schema-change 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 Schema Change 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 Schema Change?

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 Schema Change free to use?

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

Who published Schema Change?

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

Schema Change by kagkarlsson — Agent Skill

Name: Schema Change
Author: kagkarlsson

Schema Change

Use when changing the db-scheduler database schema (adding/removing/altering columns, indexes, or the scheduled_tasks table). Walks through the lock-step update across every supported DB dialect, the matching JdbcCustomization changes, and the documentation copies. Skip for code-only changes that don't touch table structure.

kagkarlsson 4d0947a 2.7 KB Updated Sep 17, 2026

File contents

Schema change checklist

The library supports six DB dialects and ships DDL for each. A schema change that misses one dialect ships a broken release. Treat this as a single atomic change.

1. DDL files (test resources)

Update all six in lock-step. Path: db-scheduler/src/test/resources/

hsql_tables.sql
postgresql_tables.sql
mysql_tables.sql
mariadb_tables.sql
mssql_tables.sql
oracle_tables.sql

Read all six first; column ordering and types differ per dialect (e.g. TIMESTAMP WITH TIME ZONE vs DATETIME2 vs TIMESTAMP(6) WITH TIME ZONE). Don't blindly copy from one dialect to another — preserve each dialect's existing type conventions.

There's also postgresql_custom_tablename.sql under src/test/resources/com/github/kagkarlsson/scheduler/ — check whether your change needs to be reflected there too (it tests configurable table name; usually yes if columns change).

2. JdbcCustomization classes

Path: db-scheduler/src/main/java/com/github/kagkarlsson/scheduler/jdbc/

If your change affects how rows are read/written (new column, type change, nullable→ not-null, etc.), update each relevant class:

DefaultJdbcCustomization.java — base behavior
PostgreSqlJdbcCustomization.java
OracleJdbcCustomization.java
MssqlJdbcCustomization.java
MySQLJdbcCustomization.java
MySQL8JdbcCustomization.java
MariaDBJdbcCustomization.java
AutodetectJdbcCustomization.java — only if dialect-detection logic changes
JdbcCustomization.java (interface) — if the contract itself changes

Also check JdbcTaskRepository.java and QueryBuilder.java for SQL that references the changed columns.

3. Documentation DDL copies

The README and/or docs/ may carry copies of the DDL for users. Grep for a column name from the table to find them:

grep -rn "scheduled_tasks" --include="*.md" .

Update any matching SQL blocks so users get the current schema.

4. Verify

mvn -pl db-scheduler test                                # PostgreSQL tests

Dialects other than PostgreSQL currently need to be tested on CI (need to run on amd64 arch).

5. Migration note for users

Schema changes are user-visible. Add a brief migration note to the changelog / release notes describing the required ALTER TABLE (per dialect if they differ).

6. Finalize

Run /finalize before committing.

---name: schema-changedescription: Use when changing the db-scheduler database schema (adding/removing/altering columns, indexes, or the scheduled_tasks table). Walks through the lock-step update across every supported DB dialect, the matching JdbcCustomization changes, and the documentation copies. Skip for code-only changes that don't touch table structure.---# Schema change checklistThe library supports six DB dialects and ships DDL for each. A schema change thatmisses one dialect ships a broken release. Treat this as a single atomic change.## 1. DDL files (test resources)Update **all six** in lock-step. Path: `db-scheduler/src/test/resources/`- `hsql_tables.sql`- `postgresql_tables.sql`- `mysql_tables.sql`- `mariadb_tables.sql`- `mssql_tables.sql`- `oracle_tables.sql`Read all six first; column ordering and types differ per dialect (e.g. `TIMESTAMP WITHTIME ZONE` vs `DATETIME2` vs `TIMESTAMP(6) WITH TIME ZONE`). Don't blindly copy fromone dialect to another — preserve each dialect's existing type conventions.There's also `postgresql_custom_tablename.sql` under`src/test/resources/com/github/kagkarlsson/scheduler/` — check whether your changeneeds to be reflected there too (it tests configurable table name; usually yes ifcolumns change).## 2. JdbcCustomization classesPath: `db-scheduler/src/main/java/com/github/kagkarlsson/scheduler/jdbc/`If your change affects how rows are read/written (new column, type change, nullable→not-null, etc.), update each relevant class:- `DefaultJdbcCustomization.java` — base behavior- `PostgreSqlJdbcCustomization.java`- `OracleJdbcCustomization.java`- `MssqlJdbcCustomization.java`- `MySQLJdbcCustomization.java`- `MySQL8JdbcCustomization.java`- `MariaDBJdbcCustomization.java`- `AutodetectJdbcCustomization.java` — only if dialect-detection logic changes- `JdbcCustomization.java` (interface) — if the contract itself changesAlso check `JdbcTaskRepository.java` and `QueryBuilder.java` for SQL that referencesthe changed columns.## 3. Documentation DDL copiesThe README and/or `docs/` may carry copies of the DDL for users. Grep for a columnname from the table to find them:```bashgrep -rn "scheduled_tasks" --include="*.md" .```Update any matching SQL blocks so users get the current schema.## 4. Verify```bashmvn -pl db-scheduler test # PostgreSQL tests```Dialects other than PostgreSQL currently need to be tested on CI (need to run on amd64 arch).## 5. Migration note for usersSchema changes are user-visible. Add a brief migration note to the changelog / releasenotes describing the required `ALTER TABLE` (per dialect if they differ).## 6. FinalizeRun `/finalize` before committing.

Frequently asked questions