期限の知らせを受けて .agents/workflows/ を開いてみたところ、名前だけでは何をするものか思い出せないファイルが並んでおりました。
個人開発のアプリのリリース手順や、自分のサイトの更新作業を書き留めてきたもので、作った当時は毎週のように呼んでいたはずなのに、いまは手が伸びないものが大半です。
Workflows は 2026 年 11 月 1 日に廃止されます。10 月 12 日の時点で、残りは 20 日です。移行コマンドは用意されていますので、慌てる必要はありません。ただ、コマンドを打つ前に、何を移すのかを自分で決めておくほうが、あとの手間がはるかに小さくなります。
最初にお伝えしたいのは、この記事の結論です。移行の前に「残す・まとめる・手放す」の 3 つに仕分けておく。それだけで、移行後に直す箇所がほぼ半分になります。
何がいつ変わるのか
公式ドキュメントに明記されている範囲を、先に整理しておきます。
| 項目 | 内容 |
|---|---|
| 廃止日 | 2026 年 11 月 1 日（それまでは動作します） |
| 廃止後 | スラッシュコマンドと索引から外れます |
| 移行先 | Skills（.agents/skills/<名前>/SKILL.md） |
| 移行コマンド | Antigravity 2.0 の /migrate-workflows |
| 走査される場所 | グローバル（~/.gemini/config/workflows/）とワークスペース（.agents/workflows/） |
| 元ファイル | .bak が付いて退避されます |
| 同名の衝突 | Workflow と Skill が同名なら Skill が優先されます |
つまり、何もしなくても 11 月 1 日までは困りません。そして、コマンド一つで機械的な移し替えは終わります。
では、なぜ棚卸しが要るのでしょうか。私自身の手元を例に、考えてみます。
最初に考えた案と、やめた理由
当初は、全部をそのままコマンドに任せるつもりでおりました。動いているものを一本ずつ触るのは気が重く、一括で済むなら一括がよいと考えたのです。
ただ、少し立ち止まって考え直しました。使っていない Workflow まで Skills に変わると、一覧が膨れるだけでなく、似た名前のものが並んで、どれを呼ぶべきか自分でも迷うはずです。
Skills は、エージェントが会話の冒頭で名前と説明を読み、必要なときに呼び出す仕組みです。並んでいる数が多いほど、読まれる材料も増えます。使わないものを抱えたまま移すのは、荷物を新しい家へ丸ごと運ぶようなものでしょう。
移す前に減らす。 この線引きで進めることにしました。
手順 1: 手元の Workflow を一覧にする
まず、どこに何があるのかを見える形にします。次のスクリプトは、2 か所のフォルダを走査して、ファイル名・文字数・最終更新日を並べます。
#!/usr/bin/env bash
# 移行前の棚卸し: Workflow の一覧を、最終更新の古い順に並べる
for dir in "$HOME/.gemini/config/workflows" "./.agents/workflows"; do
[ -d "$dir" ] || continue
echo "== $dir"
for f in "$dir"/*; do
[ -f "$f" ] || continue
chars=$(wc -m < "$f" | tr -d ' ')
mtime=$(date -r "$f" +%Y-%m-%d 2>/dev/null || stat -c %y "$f" | cut -d' ' -f1)
printf '%s\t%s\t%s\n' "$(basename "$f")" "$chars" "$mtime"
done | sort -t$'\t' -k3
doneワークスペースの側は、リポジトリごとに .agents/workflows/ があります。プロジェクトのルートで実行してください。
最終更新が古く、文字数が小さいものは、手放す候補です。一方、文字数が上限に近いものは、手順を詰め込んだ可能性があります。後半で触れる「説明文の書き直し」が必要になるのは、たいていこちらです。
手順 2: 3 つに仕分ける
一覧を見ながら、一本ずつ次の問いに答えます。
| 仕分け | 目安 | その後 |
|---|---|---|
| 残す | この 1 か月で実際に呼んでいる、または呼ぶ場面がはっきり思い浮かぶ | 移行の対象にします |
| まとめる | 名前が違うだけで、やっていることがほぼ同じ | 1 本に統合してから移行します |
| 手放す | 何をするものか、読み返さないと思い出せない | 移行の前に別の場所へ退避します |
「手放す」は削除ではありません。移行コマンドが走査するのは、先ほどの 2 か所だけです。そこから外へ出しておけば、Skills には変換されず、中身は手元にそのまま残ります。
# 手放す候補を、走査対象の外へ退避する（削除はしません）
mkdir -p "$HOME/archive/workflows-2026-10"
mv ./.agents/workflows/old-release-note.md "$HOME/archive/workflows-2026-10/"なぜ削除ではなく退避なのかと申しますと、「使っていない」という判断自体が、記憶に頼っているからです。数か月後に必要になったとき、取り戻せる余地を残しておきたいのです。
手順 3: 移行したあとに、説明文を必ず書き直す
仕分けが終わったら、/migrate-workflows を実行します。Antigravity 2.0 で走らせると、残した分が .agents/skills/<名前>/SKILL.md として作り直されます。
ここからが、棚卸しの本当の目的です。機械的な移し替えでは、一つだけ取りこぼしが出るのです。
説明文です。
Workflows には 12,000 文字の上限がありました。私は説明を短く削って、その分を手順に回しておりましたので、まさにここが当てはまります。ところが Skills では、冒頭で読まれるのは名前と説明だけです。説明が薄いと、エージェントはそのスキルを呼ぶ理由を見つけられません。
書き直す前と後の違いを、一つ例で示します。
<!-- Before: Workflow 時代の説明（手順が主役で、呼ぶ条件がない） -->
description: リリース手順
<!-- After: 何をするかと、いつ使うかを具体的に書く -->
description: アプリのリリース前に、バージョン番号の更新・変更履歴の追記・ビルド確認を順に行います。ストア提出の直前に使います。「何をするか」と「いつ使うか」の二つが入っていれば十分です。三人称で書き、手順そのものは本文に残します。
移行した全スキルで説明が書かれているかは、次のコマンドで見つけられます。frontmatter に description: を置く書き方を前提にした確認です。
# description の行が無い SKILL.md を探す
grep -L '^description:' .agents/skills/*/SKILL.md何も表示されなければ、少なくとも空欄はありません。中身が薄いかどうかは、一本ずつ目で読むしかありません。
期限の組み方
残り 20 日を、私は次のように割っています。
1 週目は棚卸しと仕分けにあてます。2 週目に /migrate-workflows を実行して、説明文を書き直します。3 週目は実際に呼んでみて、選ばれない Skill を見直します。余った数日は予備です。
期限の直前は、判断が雑になります。仕分けだけでも今週のうちに済ませておくと、あとが楽になるのだと思います。
なお、Rules と Skills のどちらに何を置くかで迷う場合は、Rules と Skills の置き分けに別の観点から書いております。移行先の設計を決めるときに、併せてご覧ください。
まずは今夜、棚卸しのスクリプトを一度だけ実行して、古い順に並んだ一覧を眺めてみてください。「これは何だったか」と手が止まるものが、手放す候補の一本目です。