AIに毎回「うちのチームはこういうデプロイ手順で」「このプロジェクトではbun testを使って」と説明し直しているなら、そのロスをなくす仕組みがある。Cursor 2.4で登場したAgent Skills、いわゆるSKILL.mdだ。
Rules・Skills・Commands——3つの違いを整理する
Cursorにはエージェントの振る舞いを制御する仕組みが3種類ある。混同しやすいので最初に整理しておく。
| 種類 | ファイル場所 | 起動タイミング | 向いている内容 |
|---|---|---|---|
| Rules | .cursor/rules/*.mdc | 常時オン（毎回読む） | コーディング規約、禁止パターン |
| Skills | .cursor/skills/*/SKILL.md | エージェントが必要と判断した時だけ | 手順書、タスク固有の知識 |
| Commands | .cursor/commands/*.md | ユーザーが / で手動起動 | 定型プロンプト、繰り返す指示 |
iBuildWith.ai はこの関係を「Rules guide. Skills do. Commands trigger.」と端的に表現している。
Rulesは「社是」だ。会社に入ったその日から壁に貼ってあり、常に有効だ。Skillsは「業務マニュアル棚」だ。普段は引き出しの中にあり、その作業が必要になった時だけ取り出す。Commandsは「定型文テンプレート」だ。よく使う文面を呼び出すが、エージェントが自律的に判断して使うことはない。
CommandsはCursor 2.4以降も廃止されていない。Cursor ForumでColin氏が明言している。Skills登場後も「手動で呼び出すプロンプト」として役割が変わらず有効だ。
SKILL.mdとは何か——「マニュアル棚」の仕組み
2026年1月22日にリリースされたCursor 2.4で、Agent Skillsがエディタ・CLI両方でサポートされた。
SKILL.mdは「エージェントが必要な時だけ読み込む手順書」だ。YAML frontmatter（ヘッダー情報）とMarkdown本文の2部構成になっている。
エージェントはどのスキルを使うか、description フィールドを見て判断する。会話の中に「ステージングにデプロイして」「deploy to staging」という言葉が出たら、それに対応するSKILL.mdを読み込んで手順に従う。
スキルは2か所に置ける。
.cursor/skills/——プロジェクト固有のスキル（リポジトリで管理）~/.cursor/skills/——ユーザーグローバルのスキル（どのプロジェクトでも使う手順）
Cursor公式ドキュメントによると、プロジェクト固有のデプロイ手順やAPIドキュメント生成などは前者、個人の作業スタイルや汎用コマンドは後者に置くのが自然だ。
SKILL.mdの書き方——最小構成から始める
コード例1: デプロイ手順のSKILL.md
❌ Rulesに手順書を詰め込む（毎回読むのでコンテキストを圧迫）
# .cursor/rules/all-rules.mdc
## コーディング規約
TypeScriptはstrict modeで書く。
## ステージングデプロイ手順
1. git status で確認
2. bun test を実行
3. git push origin HEAD
4. gh pr create ...
5. https://staging.example.com で確認
（以下100行の手順書）
## テスト方針
bun testを使う。
（以下50行のテスト規約）
✅ 分離する（Rulesは薄く、手順はSkillsに）
# .cursor/rules/coding-style.mdc（常時オン・薄い）
TypeScriptはstrict modeで書く。bun testを使う。
# .cursor/skills/deploy-staging/SKILL.md（必要時だけ読む）
---
name: deploy-staging
description: ステージング環境へのデプロイ手順。「ステージングにデプロイして」「deploy to staging」と言われたら使う。AWS SSO認証が必要。
---
# ステージングデプロイ
## 前提確認
1. `git status` で未コミットの変更がないか確認
2. テストが全てパスしているか確認（`bun test`）
## デプロイ手順
1. `git push origin HEAD`
2. `gh pr create --title "deploy: staging" --body "自動デプロイ"`
3. CI/CDが自動でステージングにデプロイ
4. https://staging.example.com で動作確認
## よくあるエラー
- `Permission denied`: AWS SSO のトークンが切れている。`aws sso login` を実行する
descriptionの書き方がすべてを決める
エージェントがスキルを使うかどうかを判断するのは description フィールドだ。ここが曖昧だと、スキルを作ったのに使われない、という状況になる。
コード例2: descriptionの良し悪し
# ❌ 曖昧なdescription（エージェントが使いどころを判断できない）
name: deploy-staging
description: デプロイのヘルプ
# ✅ 具体的なdescription（トリガーキーワード付き）
name: deploy-staging
description: ステージング・本番環境へのデプロイ手順。「デプロイして」「staging」「production deploy」「本番リリース」と言われたときに使う。AWS SSO認証が必要。
agentskills.io仕様によると、フィールドの制約は以下だ。
name: 64文字以内、kebab-case形式（必須）description: 1024文字以内（必須）- オプション:
license、compatibility、allowed-toolsなど
本文（手順書の中身）は500行以内を推奨している。それより長くなる場合は references/ サブディレクトリに詳細を分離する設計だ。
コンテキストウィンドウの節約という実利
この仕組みの実用的な価値は、コンテキストウィンドウの節約にある。
コンテキストウィンドウは「AIが一度に読める情報の量」だ。机の上のスペースに例えるとわかりやすい。Rulesは常に机に広げられた書類だ。スキルは引き出しの中にあり、必要なときだけ取り出す。
Rulesの場合、テキストのすべてが毎回システムプロンプトに含まれる。スキルの場合、エージェントが起動する時点では name と description だけが読み込まれる（スキル1つあたり約100トークン）。スキルを実際に使うと判断した時点で、本文が追加で読み込まれる。
Medium記事によると、20のスキルがあっても起動時は約2,000トークン（name+descriptionの合計）で済む。同じ内容を全部Rulesに書いて常時オンにした場合、約40,000トークンを毎回消費する計算になる。
チームが手順書を増やすほど、この差は広がっていく。
実際のユースケース
デプロイ・CI/CDの手順書
「ステージングにデプロイして」「本番リリース」といった言葉で自動的に対応手順を読み込む。AWS SSOの認証手順、環境変数の確認、ロールバック手順を1つのSKILL.mdにまとめられる。
APIドキュメント自動生成
Mintlifyは、ドキュメントが更新されるたびにSKILL.mdを自動再生成する仕組みを実装済みだ。「ドキュメント生成して」という指示に対して、常に最新の生成ルールをエージェントが参照できる。
チームのコーディング規約（詳細版）
常時オンのRulesには薄いサマリーだけ置き、詳細な規約や例外パターンはSKILL.mdに書く。「このプロジェクトのルールを確認して」という会話が起点になり、詳細版が読み込まれる。
常時オンのRulesとの使い分け基準
迷ったときの判断軸はシンプルだ。
- 「どんな作業でも常に必要な情報か？」——YesならRules
- 「特定の作業が発生した時だけ必要な手順か？」——YesならSkills
コーディング規約（TypeScriptのstrict mode、命名規則）はどんな作業でも必要だ。Rulesに書く。デプロイ手順、テスト戦略の詳細、特定ライブラリの使い方は、作業が発生した時だけ必要だ。Skillsに分ける。
オープンスタンダードとしての広がり
Agent SkillsはCursorだけの仕組みではない。
Mintlifyのブログによると、25以上のAIコーディングツールが対応するオープンスタンダードになっている。Claude Codeなら .claude/skills/、WindsurfやClineも各ツールのディレクトリに配置することで同じSKILL.mdが機能する。
つまり、一度チームで書いたSKILL.mdは、メンバーが使うツールを変えてもそのまま再利用できる。「チームの流儀をGitで管理して、どのAIツールでも動く」という状態が現実的になっている。
制限と現実——正直に言う
サブエージェントとは非互換
Cursor 2.4では、サブエージェントがスキルを直接使えない。Cursor Community ForumでColin氏が認めた既知の制限だ。
回避策は、サブエージェントへの指示に「SKILL.mdを直接読んでから作業して」と明示的に追加することだ。根本的な解決ではないが、現状では最も確実な方法だ。
セッションリセット問題
エージェントはセッション終了でリセットされる。MemUブログが指摘しているように、エージェントがセッション中に学んだことや試行錯誤の結果は、次のセッションに引き継がれない。
SKILL.mdは「静的な定義」だ。学習しない、進化もしない。砂の城に例えるなら、SKILL.mdは設計図だ。次のセッションで同じ設計図から同じ城を正確に建てられる——でも前のセッションで発見した近道や失敗の記録は残らない。
SKILL.mdに「よくあるエラーと対処法」を書き続けていくことが、現時点でできる最善の「学習の積み上げ」になる。
Cursor 2.5 Plugin Marketplaceへの発展
2026年2月17日リリースのCursor 2.5では、SkillsはPlugin Marketplaceの構成要素の1つになった。
Figma・Stripe・Amplitudeなどのパートナー企業が、MCPサーバー・スキル・サブエージェント・フック・ルールを1パッケージとして提供する形だ。/add-plugin stripe の1コマンドで、Stripeの公式スキルが自動でインストールされる。
プラグイン全体については別の記事で詳しく解説している。
チームの流儀をGitで管理する
SKILL.mdの本質は「AIへの説明をコードで管理する」ことだ。
.cursor/skills/ をリポジトリに含めてGitで管理すれば、チームメンバー全員が同じスキルを共有できる。新しいメンバーが参加したとき、リポジトリをcloneするだけでチームのAI設定が揃う。
手順が変わったら SKILL.md を更新してPRを出す。「AIに覚えさせた内容」がコードレビューできる状態になる。
「AIに毎回同じことを説明する」という繰り返しをなくす最初の一歩は、今使っているデプロイ手順を SKILL.md に書き起こすことだ。10分もあれば最初の1枚が書ける。
