はじめに
- 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 がメイン
- ハッカソン・Web ・Kaggle と、触る土俵がコロコロ変わる
- 使い捨てSkills では 大会専用リポジトリ に Skill を閉じた経験あり
理由と手順
なぜグローバルに載せないか
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 読んでくれてありがとうございました (´▽｀)