Rules と Skills で再現性を上げる

Rules はチームの取扱説明書

デザインのトーン、触ってほしくないディレクトリ、コミットメッセージの言語、個人情報を載せない。こうした約束を書いておくと、Agent のばらつきが減ります。

はじめての方は、文章ルールや公開文言のトーン、禁止事項の提案が得意領域です。実装規約は開発者と一緒に書けば十分です。

リポジトリ直下の `AGENTS.md`（とくに Cursor Cloud specific instructions）は、起動や確認の手順メモです。方針・禁止は Rules、Cloud での進め方は AGENTS.md、と分けるチームもあります。環境レッスンでも触れます。Cursor CLI は同じ直下の `CLAUDE.md` も Rules として読みます（公式 CLI using）。Claude Code から来たチーム向けで、はじめての約束は AGENTS.md か `.cursor/rules` で十分です。

Rules は三層ある

公式のベストプラクティスでは、Rules を三層で使い分けます。『どこに書くか』で効く範囲が変わります。

• 個人（User rules）: Cursor Settings の自分用。自分の全リポジトリに効く。口調や個人の好み向け
• チーム（Team rules）: ダッシュボードの Rules / Commands / Hooks。組織の共通約束向け
• リポジトリ（Repo rules）: `.cursor/rules/*.mdc` を Git に置く。そのプロジェクトだけの約束向け

モバイル起動でも効くのはどれ？

公式 Cursor for iOS では、Automations / Rules / Skills の管理画面は Web（または Desktop）にあります。スマホアプリは司令塔と確認向けで、設定の正ではありません。

一方、リポジトリに入っている `.cursor/rules`、`.cursor/skills`、AGENTS.md は Agent が読み込むので、モバイルから起動しても効きます。個人用の `~/.cursor/skills/` に置いた Skill も、Cursor に同期（synced）されていれば同様に使えます（管理・追加は Web 側）。同期されるのは `~/.cursor/skills/` だけです。`~/.agents/skills/` や未同期の手元 Skill は、Cloud Agent・Agents Window の Remote SSH・自前ワーカー（My Machines / Team Pool）にはコピーされません（公式 Agent Skills）。Web で Rules を編集しても、実行時に効くのは Git に入った内容です。スマホから約束を変えたいときは、リポジトリ Rules を更新する PR を Agent に頼むのが確実です。

スラッシュコマンドや Skills の実行は、モバイルでも CLI や Web と同様に使えます（first-cloud-agent のモバイル節も参照）。

Skills は手順の型

Rules が『いつも守る約束』なら、Skill は『この種の仕事の進め方』です。毎回同じ説明をしているなら、Skill にしてみましょう。例:『文言変更 PR の出し方』『プレビュー確認の報告フォーマット』。

Skill はフォルダ1つ＋その中の SKILL.md が最小単位です。必要なときだけ読み込まれるので、長い手順書を毎回プロンプトに貼らなくてよくなります。

公式も、Agent がテストや確認でつまずくときは、Skills と AGENTS.md で『いつ・どう確認するか』を渡すことを勧めています。Agent は賢いけれど、そのリポジトリの事情はまだ知らない新人、と考えると伝わりやすいです。

モノレポでは、パッケージ配下の `.cursor/skills/` も拾われます。そのディレクトリのファイルを触っているときだけ出やすい、という公式の説明があります。ルートの Skill は保管庫全体で使えます。

Skill の作り方（設定の骨格）

チームで共有するならリポジトリの `.cursor/skills/{スキル名}/SKILL.md` に置きます（個人用ならホームの `~/.cursor/skills/`）。フォルダ名は英小文字・数字・ハイフンだけにします。別の個人用フォルダ `~/.agents/skills/` は手元の Desktop 向けで、Cloud Agent や自前ワーカーには届きません。

SKILL.md の先頭に name と description を書きます。name はフォルダ名と同じ。description には『何をするか』と『いつ使うか』を書いておくと、Agent が自動で選びやすくなります。その下に、手順・完了条件・禁止事項を Markdown で書きます。

手早く作るなら Agent チャットで `/create-skill` と入力します。すでに似た Rules やスラッシュコマンドがあるなら `/migrate-to-skills` で変換できます。約束だけ書きたいときは `/create-rule`、作業の途中チェックなら `/create-hook`、役割を分けた子 Agent なら `/create-subagent` もあります。Explore / Bash / Browser は最初から入っているので、探す・コマンド・画面操作用に自分で作る必要はありません（公式 Agent Skills / Subagents）。

Desktop なら、入れたものの確認はサイドバーの Customize がまとめて扱う画面です。プラグイン・Skill・MCP・サブエージェント・Rules・コマンド・Hooks を、自分 / この作業場 / チームで絞って見られます。Marketplace からの追加と、チームのリーダーボード（よく使われているプラグイン・Skill・MCP）から1クリックで足すこともできます（公式 Customize）。コミュニティのプラグインや MCP は cursor.directory です。

• 使う: チャットで `/スキル名` と打つ、または依頼内容が description に合うと自動適用
• 確認: Desktop ならサイドバーの Customize。Skills 以外の MCP や Hooks も同じ画面
• 共有: Git にコミットして PR。Cloud Agent も同じリポジトリの Skill を使える
• 届く範囲: 同期は `~/.cursor/skills/` だけ。自前ワーカーではリポジトリの Skill か、イメージへの焼き込み（公式 Agent Skills）
• 整理: カテゴリ用のフォルダをネストしてよい。Skill の名前は SKILL.md があるフォルダ（親カテゴリではない）
• 対象ファイル: 先頭の `paths`（glob。新規はこちら。古い `globs` も通る）で、触っているファイルのときだけ出す
• 明示だけ: `disable-model-invocation: true` にすると、`/スキル名` と打ったときだけ読み込む
• 互換フォルダ: `.claude/skills/` と `.codex/skills/`（ホームの `~/.claude/skills/` / `~/.codex/skills/` も含む）も拾う。Claude や Codex 向けに置いた手順が Cursor でも出やすい（公式 Agent Skills）
• Custom Mode のバッジ: 任意の `icon` と `color`。ピン留めしたときの見た目用（公式 Agent Skills）

Rules と Skills の使い分け

いつも守ってほしいこと（トーン、禁止ディレクトリ、秘密情報を載せない）は Rules。特定の作業フローだけに効かせたいことは Skills。迷ったら、毎回プロンプトに貼っている段落を Skill 候補にします。

Hooks：作業の途中に挟む自動チェック

Hooks は、Agent がファイルを直したあとや、コマンドを打つ前後、依頼を送る前、サブエージェントの開始／終了などに動く自動処理です。例: 編集後に整形する、秘密情報が混ざりそうなら止める、危険な操作をゲートする。

Cloud Agent は、リポジトリの `.cursor/hooks.json`（プロジェクト向け）を読みます。手元だけの `~/.cursor/hooks.json` は Cloud には届きません。Enterprise ではダッシュボードからチーム／組織向け Hooks も配れます。

公式の例では、ツール実行前後（preToolUse / beforeShellExecution / afterFileEdit）、プロンプト送信前（beforeSubmitPrompt）、サブエージェントの開始・終了（subagentStart / subagentStop）、コンテキスト整理（preCompact）、応答のあと（afterAgentResponse / afterAgentThought）、実行終了（stop）などがあります。Tab 専用や workspaceOpen は Desktop 向けで、Cloud では動きません。

Cloud Agent が実行できるのは command-based（外部コマンドを走らせる型）の Hooks だけです。prompt-based（モデルに判定させる型）は Desktop 向けで、クラウド VM では動きません。詳しい人が両方混在させているリポジトリでは、Cloud 用に command-based だけ残す、と整理されることがあります。

Enterprise プランでは、ダッシュボードから配るチーム Hooks や enterprise-managed hooks も Cloud Agent で動きます。リポジトリの `.cursor/hooks.json` と併用されるイメージです。

Hooks から『いまのターンを送った人』と『所有者』を比べたいときは、エージェントメタデータの `turn/user-id` と `owner/user-id` を読む公式例があります（environments-and-secrets の OIDC / メタデータ節）。認証ではなく監査・ログ用です。

sessionStart や beforeMCPExecution / afterMCPExecution も、Cloud では動かない公式の種類です（読み取り専用の最初の探索中は Hooks 自体が読み込まれないため）。

書き込み可能な環境になってから Hooks が動き始めます。最初の読み取りだけの探索中は動かない、という公式の説明も覚えておくと、『なぜ最初の数ターンだけ効かない？』が分かりやすくなります。

最初から入っている Skills

自分で SKILL.md を書かなくても、Cursor が用意しているビルトイン Skills があります。チャットで `/` と打つと一覧でき、依頼がはっきりしていれば Agent が自分で選ぶこともあります（公式 Agent Skills）。

• `/autopilot`: 開いた PR の指摘・コンフリクト・赤い Checks を見守って直す。マージまで任せたいときの近道（review-and-merge）
• `/cursor-blame`: AI が書いた変更と、そのときの依頼文を調べる。確認チェックリストの『なぜ入った？』向け
• `/split-to-prs`: 大きな変更を小さな PR に分ける。『ついでに』が増えたとき（follow-up-loop）
• `/canvas`: 会話の横に触って試せる画面やダッシュボードを出す。言葉だけではイメージしにくいときの見本。同僚へ渡すなら Shared Canvases（リンクをコピー。このレッスンの Canvas 節）
• `/review` / `/review-bugbot` / `/review-security`: コードレビュー Agent を選んで走らせる。push やマージの前に先に読んでもらう入口。同じ差分のまま PR を出すと保管庫側は再実行を飛ばすことがある（Cursor 3.7+ / cursor.com/agents）
• `/agent-review`: Desktop で手元の変更を読む。PR の Bugbot や `/review` とは別。設定は Agents（Cursor 3.11 以降は Git & PRs）。深さは Quick / Deep（公式 Agent Review）
• `/create-rule` / `/create-hook` / `/create-subagent`: 約束・途中チェック・子 Agent のひな型を作る。Explore / Bash / Browser は設定不要のビルトインなので、自分で作らなくてよい（公式 Subagents）
• `/create-skill` / `/migrate-to-skills` / `/automate` / `/loop` / `/goal` は、この学習パスの他のレッスンでも使います
• `/shell`: 渡した文をそのままシェルで実行する。コマンドを渡されたときだけ使う。はじめての方は5要素の依頼の方が安全です（公式 Agent Skills）

チームへ公開する（Publish）

Teams / Enterprise では、個人用の `~/.cursor/skills/` をチームの Default marketplace へ Publish できます。Customize → Skills で Skill を開き、Publish を選びます（公式 Plugins）。

公開しても、同僚は自分で入れます。作者には自動で付きます。全員に強制したいときは、管理者が marketplace の Required にします。自分の Cloud Agent だけに使わせたいなら、同期（Sync Skills）で足り、Publish しなくてよいです。

管理者が新規公開を止めたいときは、Dashboard → Plugins → Default marketplace の Marketplace Settings で Allow Members to Publish をオフにします。既定はオンです。オフにしても、すでに公開した作者は更新や非公開ができます（公式 Plugins）。

プラグインには2つの型があります。Agent Plugins はスキルと MCP をまとめる公開の標準（ルートの `plugin.json`）。Cursor Plugins はそれに加えて Rules・コマンド・Hooks なども入れられる Cursor 側の型（`.cursor-plugin/plugin.json`）です。チーム marketplace はどちらも配れます。はじめての方は『Skill を Git に置くか Publish する』で十分です（公式 Plugins）。

Canvas の3つの形（見本・共有・プラグイン）

`/canvas` は、会話の横に触って試せる画面（React の部品）を出します。導線の見本だけでなく、ダッシュボード・分析・監査・報告にも向きます。コードを直す依頼ではなく、『この流れを触って理解したい』『数字を表ではなく画面で見たい』ときの見本です（公式 Canvases / Agent Skills）。依頼の型は prompting の添付と具体物の節も参照してください。

開き方は3つあります。返信末尾のカード、コマンドパレットの Open Canvas（View 配下）、Agents Window の新しいタブ。ワークスペースの Canvas 一覧から、あとで開き直したり新しいデータで再実行したりできます。レイアウトが違うときは手で直さず、Agent に『ここをこう変えて』と頼む方が早い、という公式の案内です。

同僚に見せたいときは Shared Canvases です。ツールバーの Publish で、その時点の画面のスナップショットが上がり、リンクをツールバーからコピーして送ります。チームのメンバーならブラウザで開け、閲覧は読み取り専用です。会話履歴を渡したり、Agent を再実行したりしなくて済みます（公式 Canvases）。

ダッシュボードの Shared Canvases に並ぶのは、自分が公開したものだけです。同僚が Publish した Canvas は一覧に出ないので、リンクをもらって開きます。共有リンクはブラウザで全画面表示でき、会議で見せるときに向きます（公式 Canvases / changelog Canvas Design Mode）。

できた見本のレイアウトを直したいときは、手でソースを触るより、Canvas 上の Design Mode で部品を選んで『ここをこう』と頼む方が早いです。ブラウザの Design Mode と同じ考え方です。大きな作り直しは、戻してから依頼し直す公式の案内もあります。

Shared Canvases は有料プラン（Pro / Teams / Enterprise）かつチーム所属が必要です。Free は共有を作れません。Pro でもチームに入っていれば共有できます。データ保存を許す Privacy Mode が必要で、Privacy Mode（Legacy）では共有できません。管理者はチーム設定の Shared Canvases でオフにできます。

同じ型の報告を毎回出したいときは、Canvas のレイアウトを Skill にできます。公式では次の4つを書いておくと、短い依頼で同じ形が再現され、チームでも揃います。(1) いつ使うか（例: 四半期の売上報告、依存関係の監査）(2) どの欄・表を出すか (3) 数字の取り方（SQL / API / コマンド）(4) 単位や日付の揃え方。

プラグイン側にも、最初から用意された Canvas があります。Customize からインストール済みプラグインの Canvas を開くと、ゼロから設定しなくて済みます（公式 Plugins）。こちらはプラグインのひな型で、自分の Canvas を Publish する Shared Canvases とは別物です。

• Hex Canvas: データの可視化。数字の並びを図にして共有したいとき
• Atlassian Canvas: Jira と Confluence の Issue・プロジェクト・文書をリアルタイムで見るとき
• 自作の見本だけなら `/canvas`。同僚にリンクで渡すなら Shared Canvases（Publish → リンクをコピー）。チームのひな型を開くならプラグインの Canvas