database-migrations

database-migrations 技能概覽

database-migrations 是用來做什麼的

database-migrations skill 能幫助你為後端系統規劃並撰寫安全的資料庫變更。當你需要發布 schema 更新、backfill、rollback，或零停機變更，而且不想靠猜操作順序時，它最實用。

適合誰使用

如果你在後端開發中使用 PostgreSQL、MySQL，或 Prisma、Drizzle、Kysely、Django、TypeORM、golang-migrate 這類常見 migration framework，就很適合使用 database-migrations skill。當你更重視 production 安全性，而不是快速做一次性修改時，它會特別合用。

database-migrations 有什麼不同

這個 database-migrations skill 對 production 紀律有明確立場：migration 應該採取 forward-only、schema 變更與 data 變更要分開、而且變更要用接近真實的資料來測試。當你需要更少的鎖、更乾淨的 rollback，以及更清楚的部署步驟時，它會比一般提示詞更合適。

如何使用 database-migrations skill

安裝並啟用

使用以下指令安裝 database-migrations skill：
npx skills add affaan-m/everything-claude-code --skill database-migrations

在你的任務涉及 migration 決策時就啟用它，不要等 schema 已經壞掉之後才用。最適合考慮 database-migrations install 這種思路的時機，是你還沒開始寫 SQL、還沒產生 ORM migrations、也還沒規劃部署順序之前。

提供正確的輸入

若要讓 database-migrations usage 發揮效果，請提供：

• 資料庫引擎與版本
• 資料表大小，以及該表是否為 hot table
• 你要做的確切 schema 變更
• 這個變更是否必須零停機
• 是否需要 rollback 支援
• 使用中的 ORM 或 migration 工具

較弱的需求會是：「讓這個 migration 安全一點。」
更好的需求會是：「我要在一個 4,000 萬列的 PostgreSQL 資料表上新增一個可為空的 status 欄位，這張表供網頁應用使用，而且沒有維護視窗。請建議最安全的 migration 步驟與 rollback 計畫。」

先讀對的檔案

先從 SKILL.md 開始，接著再檢視 repo 裡其他支援性指引，例如 README.md、AGENTS.md、metadata.json，以及若存在的 rules/、resources/、references/ 或 scripts/ 等資料夾。對這個 repo 而言，SKILL.md 是主要的 truth source，所以在對接你的技術棧之前，先從裡面整理 checklist、啟用條件與資料庫特定模式。

採用以 migration 為先的工作流程

實用的 database-migrations guide 通常會照這個順序進行：

1. 定義期望的最終狀態
2. 把 schema 變更與資料 backfill 分開
3. 確認操作是否能 online 執行
4. 撰寫 forward 與 rollback 步驟
5. 用接近 production 的資料測試
6. 必要時分階段部署

這個流程很重要，因為這個 skill 的設計目標就是降低鎖定風險、避免破壞性的 rollback，並減少「staging 跑得動，production 卻出問題」的驚喜。

database-migrations skill 常見問答

database-migrations 只適用於 PostgreSQL 嗎？

不是。database-migrations skill 涵蓋 PostgreSQL 與 MySQL，也適用於以熱門 ORM 和 migration 工具為基礎的工作流程。不同引擎的 SQL 模式會變，但安全模型是一樣的。

這比一般提示詞更好嗎？

如果工作會對 production 造成實際影響，那答案是肯定的。一般提示詞可能只會建議 migration 的形狀，但 database-migrations skill 會在鎖定、可回復性，以及 schema 與 data 工作分離這三件事上提供更強的防護。

初學者可以用嗎？

可以，只要他們能清楚描述變更內容。初學者若能提供資料表、資料量與可接受停機時間，而不是只要一個通用 migration 範本，通常會得到最大價值。

什麼情況下不該用？

不要把它當成應用程式專屬驗證或資料庫引擎文件的替代品。如果你的任務只是一個沒有 production 資料的本機 prototype，這個 skill 可能太偏流程化，超過你當下真正需要的程度。

如何強化 database-migrations skill

先把部署限制說清楚

當你先說明應用程式是否能接受鎖定、部署是 blue-green 還是 rolling、以及變更期間寫入是否仍會持續時，database-migrations usage 的品質會明顯提升。這些限制會直接決定 migration 能不能 online 執行，還是必須拆成多個階段。

補上資料量與風險細節

當你提到列數、index 大小、foreign key，以及資料表是否是高寫入量時，這個 skill 會更有用。這些資訊有助於避開常見失敗模式，例如在沒有預設值的情況下加上 NOT NULL、inline 建立 index，或把 backfill 與 schema 變更混在一起。

要求一個具體的 migration 計畫

不要只問「最佳實務」，而是直接要求你真正需要的完整方案：SQL、rollback 路徑、驗證檢查，以及部署順序。如果第一次回答太過泛泛，就再補上目前 schema、目標 schema，以及來自 Prisma、Drizzle、Kysely、Django、TypeORM 或 golang-migrate 的 ORM 特定限制。

把第一次輸出當成草稿

先用第一版結果確認安全假設，再依你的真實環境調整。最有效的改進通常來自更精確的資料形狀、標明哪些部分是不可逆的，並要求 database-migrations skill 在安全性、速度或最小鎖定之中優先最佳化其中一項，而不是三者一起硬要兼顧。