はじめに

Web 開発のリポジトリで Cursor を開くと、Kaggle 用の Skill（約30個）が反応してほしくない
逆に Kaggle コンペ中は、ハッカソン用の Skill が混ざると指示がブレる

この記事で分かること:

グローバル ~/.cursor/skills に Kaggle を載せない 理由
コンペ ROOT の .cursor/skills/ だけ に閉じる設計
comp-profile.md でコンペ型ごとに読む Skill を絞る 話
広い検索はサブエージェントに任せて 親チャットのコンテキストを節約する話
使い捨てSkills — ハッカソン用のAgent SkillsをAIに作らせたの Kaggle 版 として読める考え方

結論

Kaggle 用 Skill はコンペフォルダ内だけに置く。グローバルには置かない。
Web 開発・ハッカソン・Kaggle は、開くフォルダ（ROOT）で Skill の世界を分ける のが一番ラクでした ((_๑òωó)_ﾊﾞﾝ

想定読者

Cursor の Agent Skills を複数プロジェクトで使っている方
Kaggle と Web 開発を同じ PC で行き来する方
ハッカソン向け「使い捨て Skills」の考え方を Kaggle に応用したい方 (｡･ω･｡)

私の属性

理由と手順

なぜグローバルに載せないか

Cursor のグローバル Skill（ユーザーホーム配下の skills/）は、どのフォルダを開いても Agent に載る 可能性があります。

置き場所	効く範囲	Kaggle で困ること
グローバル `~/.cursor/skills/`	全プロジェクト	Web 用 Skill が Kaggle セッションに混ざる
コンペ ROOT `.cursor/skills/`	そのフォルダを開いたときだけ	意図した Skill だけが読まれる

Kaggle 用 Skill には「submit 禁止」「license 台帳を見ろ」など コンペ固有のルール が多いです。
これがポートフォリオ用 React プロジェクトに漏れると、会話が変になります（笑）

コンペ ROOT だけに閉じる設計

comp-root/                    # コンペ専用フォルダを Cursor で開く
├── .cursor/
│   ├── skills/               # Kaggle Skill はここだけ（SSOT）
│   ├── rules/                # 軽いリマインド（例: 提出前ゲート）
│   ├── hooks.json
│   └── agents/               # サブエージェント（探索・検索委譲用）
├── AGENTS.md                 # 入口。Skill の参照先を書く
└── docs-ja/
    └── comp-profile.md       # コンペ型 × 使う Skill のマトリクス

Web 開発プロジェクト には kaggle-* Skill も three-gates 的な rule も 置かない。
Kaggle 作業時 はコンペ ROOT だけを開く、と割り切ります。

使い捨て Skills の Kaggle 版

使い捨てSkills では「大会が終わったら役目終了」でした。
Kaggle でも近いです。

ハッカソン版	Kaggle 版
大会用リポジトリに Skill を置く	コンペ ROOT に Skill を置く
3時間で完結	コンペ期間中だけ育てる
終了後はアーカイブ	終了後はフォルダごと眠らせる

「一生育てる汎用 Kaggle Skill」より、コンペごとにコピーして使い捨て の方が、ルールのブレが少ないと感じています。

comp-type で「読む Skill」を絞る

.cursor/skills/ に約30個入っていても、コンペ次第で全く使用しないSkill があります。
コンペのタイプ別にskillsを入れ替えるのは、流石に面倒と感じました。
そこで docs-ja/comp-profile.md に、コンペ型ごとの Skill マトリクス を置いています。

役割	ファイル	内容
型の確定	`AGENTS.md` の `comp-type`	simulation / tabular / notebook-output など
ルーティング SSOT	`docs-ja/comp-profile.md`	このコンペで使う Skill と使わない Skill
迷ったとき	`kaggle-comp-router`（メタ Skill）	マトリクスを見て次に使う Skill を1つ提示

使う / 使わないの例（抽象）

コンペ型が違うと、有効な Skill も変わります。

コンペ型の例	よく使う Skill の方向性	休眠（inactive）にしがちなもの
simulation	対戦ログ解析・公開 NB メタ追跡	tabular 向けローカル CV 系
tabular	ローカル eval・CV ログ戦略	simulation 専用の debug 系
notebook-output	提出 zip 検証・kernels runbook	型が合わない tracker 系

comp-profile.md には 「使わない Skill（このコンペ）」 節も書きます。
Agent が迷子になって検討違いの提案をしないようにするのが狙いです。

ルーター Skill のルールとして、マトリクス全文を毎回読まない ことも決めています。
comp-phase（active / post-comp）に応じた タスク別ルーティング節だけ を見る、くらいに絞ると軽くなりました。

依頼のたびに約30個すべてを読むのではなく、型に合った1本 に絞る流れです。

検索はサブエージェントに任せてコンテキストを節約

Skill を絞っても、リポジトリ横断の grep や Discussion 原文当たり は重いです。
親 Agent のチャットにログ全文を載せると、すぐコンテキストが膨らみます。

そこで .cursor/agents/ にサブエージェントを置き、読むだけの重い仕事 は委譲しています。

親がやること	サブエージェントに任せること
次に使う Skill の判断	リポジトリ広域探索（grep / glob）
`exp/` や `docs-ja/` への確定記録	他者 Notebook の入口調査
提出可否・ゲート判断	Discussion スレッドの新規コメント確認

委譲の入口は kaggle-subagent-delegate（メタ Skill）です。
サブには 構造化サマリだけ 返してもらい、親チャットには次の形だけ載せます。

Answer（1〜2文）
Files（パス一覧・上限あり）
Findings（箇条書き・上限あり）
Suggested next step（親が使う Skill 名）

ファイル全文やログ全文は 親チャットに貼らない ルールです。
詳細は exp/exp-intel.md や docs-en/discussion/ に書き、親は索引だけ読む、という分担です。

小さい探索（既知パスの1ファイル、短い grep）は 親が直接 で十分、と決めています。
「広いからサブ」と「判断が要るから親」を分けると、コストと精度のバランスが取りやすかったです (｡･ω･｡)

サブは 読むだけ、親は 判断と記録 — チャットに全文を載せないための分担です。

具体的手順

マスターテンプレート を1か所だけ持つ（自分用の kaggle-template など）
新コンペ開始時に、テンプレから .cursor/skills/ を comp ROOT へコピー
グローバルに Kaggle Skill が残っていたら アーカイブ用スクリプトで退避（1回やればよい）
Web 開発するときは Web 用フォルダだけ を開く（Kaggle ROOT は開かない）

指示ミスにより、何度かグローバルにKaggle Skillが作られたため、退避用を残しています。
コンペ開始の儀式とセットなら、Kaggleコンペ開始の「儀式」を固定した話と一緒に読むと流れがつながります。

注意点

ワークスペースファイルで複数 ROOT を束ねると、チャット履歴が分断されやすいので、自分は避けています
拡張機能52個でPCが重すぎた話の エディタプロファイル分離 とセットだと、さらに迷子になりにくいです
Skill を増やしすぎると Agent が読み切れない。コンペ中に本当に使うものだけ に絞る

まとめ

Kaggle 用 Skill は グローバルではなくコンペ ROOT の .cursor/skills/ にだけ置く
Web・ハッカソン・Kaggle は 開くフォルダで世界を分ける（使い捨て Skills の延長）
comp-profile.md で コンペ型ごとに使う Skill を絞り、使わない Skill は inactive と明記する
広い検索・Discussion 当たりは サブエージェントに委譲 し、親チャットにはサマリだけ載せる

提出前の verify は Kaggle提出前にローカル検証ループを回す話、API・GPU のコストは Kaggle×Cursor×Google Colabのコスト設計と併読すると流れがつながります。

環境と Skill の両方を分けたら、エージェントへの指示がだいぶ素直になりました |ω・*)

m(_ _)m 読んでくれてありがとうございました (´▽｀)