使い捨てSkills — ハッカソン用のAgent SkillsをAIに作らせた

はじめに

ハッカソンに向けて、Cursor の Agent Skills を プロジェクト専用の使い捨て として量産した話です。 「Skills を育て続ける」より「大会が終わったら役目を終える」運用にしたら、準備がかなり楽になりました(´▽｀)

対象は 全日本AIハッカソン 2026（現地オフライン・3時間開発）です。

想定読者

• ハッカソン前に AI エージェントの指示を整えたい方
• Cursor の Skills を触ったことがあるが、何を Skill 化すればいいか迷っている方

私の属性

• 30代女性・事務職（エンジニアへの転職希望中）
• AWS 系資格を複数取得済み。
• 今回のハッカソンは 2名チーム 必須だった

なぜ「使い捨てSkills」にしたか

参加予定だったのは 全日本AIハッカソン 2026 です。
3rd オフライン大阪向けに、ハッカソン用リポジトリを用意しました。

開発時間が短い＆10年振りくらいに再会する学生時代のクラスメイトと初めて共同作業をするため、少し準備しようと考えました。
チーム必須なので、統一した物があると便利かな？と考えて、前日寝る前の数十分で作成しました！

• 大会レギュレーション：審査（ブラウザで操作、3分/チーム）
• 開発時間は 3時間
• アイデア出し → UI 設計 → タスク分解 → S3 デプロイ、という流れ

これを AGENTS.md に書くだけだと、エージェントが「次に何の Skill を読むべきか」まで自分で判断しにくいです。
そこで、フェーズごとに Skill を分けて .cursor/skills/ に置く 方針にしました。

ハッカソン全般向けの汎用 Skill として設計した

Skills 自体は、特定の1大会専用のハードコード にはしていません。
hackathon-summary や hackathon-ideation などは、説明文に「短期型ハッカソン」「プロジェクト内ドキュメントがあればそこから制約を読み取る」と書いてあり、大会名・審査方式・開発時間は docs/ 側で差し替える 形です。

層	役割	大会ごとに変える？
.cursor/skills/	手順・フォーマット・人間/AI の分担	基本は共通（汎用）
docs/*-summary.md	大会 HP から作る要約	毎回作り直す
docs/*-regulation-summary.md	応募要項ベースのレギュ要約	毎回作り直す
AGENTS.md	その大会の制約・コマンド・Skill 入口	毎回更新
docs/idea.md など	採用案・タスク・デモ手順	当日の成果物

「使い捨て」とは Skill テンプレを捨てる意味ではなく、局所的な用途でAIに自動作成してもらって、メンテナンスしない という意味です。
次のハッカソンに出るときは、Skills はそのまま使い、要約ファイルと AGENTS.md だけ差し替えればよい、という設計にしています。

前日の数十分で Skill の骨格を AI に作らせ、中身の大会固有情報は docs/ に逃がす。これが「使い捨て」運用のコアです。

準備からアプリ作成までの流れ

実際に取った手順は、次の順番です。

① ハッカソン HP の URL を渡す
    ↓ hackathon-summary
② 大会要約・レギュレーション要約（docs/）を作成
    ↓ 前提情報の受け渡し完了を確認
③ AGENTS.md の作成依頼
    ↓ hackathon-agents-md
④ アイデア出し（prep → live）
    ↓ hackathon-ideation
⑤ アプリ作成（UI 設計 → タスク分解 → 実装）
    ↓ hackathon-design-md / hackathon-tasks-plan / 実装系 Skill

① ハッカソン内容を URL で渡す

チャットに大会トップページや応募要項の URL を貼るだけから始めます。
hackathon-summary は「ハッカソン URL の共有」で起動するよう Skill に書いてあります。

このハッカソンに参加します。要約ファイルを作って。
https://www.aifestival.jp/hackathon
参加ラウンドは 3rd オフライン大阪です。

② 要約ファイル作成（前提情報の受け渡し）

hackathon-summary が公式ページを読み、docs/ に要約を出力します。

• docs/{event-slug}-summary.md — 大会概要
• docs/{event-slug}-regulation-summary.md — レギュレーション要約（応募要項を正とする）

Skill 側では 推測・過去大会ルールの混入を禁止、verified: true は検証完了後のみ、と決めています。
この2ファイルができて初めて、以降の Skill が「何の大会か」を共有できる状態になります。

③ AGENTS.md 作成依頼

要約が揃ったら hackathon-agents-md でルート AGENTS.md を作ります。
開発時間・審査方式・デプロイコマンド・Skill 一覧を、その大会用に1枚にまとめる 段階です。

hackathon-agents-md で AGENTS.md を作って。
制約は docs/*-regulation-summary.md を参照。
審査は操作型（プレゼン不要）、審査員は IT 素人。

④ アイデア出し

テーマ告知前は hackathon-ideation の prep、告知後は live に切り替えます。
docs/ideas/ に候補を溜め、comparison.md でスコアリングして、人間が1案を選びます。

⑤ アプリ作成

採用案が docs/idea.md に入ったら、UI → タスク → 実装の順です。

• hackathon-design-md で DESIGN.md
• hackathon-tasks-plan で docs/tasks.md
• フロント実装・Bedrock 連携は hackathon-bedrock など

開発中の進捗更新は hackathon-tasks-sync、競合調査が必要なら hackathon-competitive-analysis を挟みます。

作った Skills 一覧（8個）

.cursor/skills/ に配置したものです。
中身の作成は、ほぼCursor エージェントへの依頼で行いました（私は要件と制約を渡し、ドラフトをレビュー）。

Skill	用途
hackathon-summary	大会要約・レギュレーション要約の整理
hackathon-agents-md	ルート AGENTS.md の作成・更新
hackathon-ideation	アイデア出し（発散→比較→採用）
hackathon-competitive-analysis	競合・類似サービスの Web 調査
hackathon-design-md	UI デザインシステム（DESIGN.md）
hackathon-tasks-plan	当日タスクの初期分解
hackathon-tasks-sync	開発中の進捗同期
hackathon-bedrock	Amazon Bedrock / Lambda 実装パターン

Skills の中身（抜粋）

ここからは、実際に置いた Skill の 一部 を紹介します。
全文は長いので、設計の肝だけ掲載します。

0. hackathon-summary — 大会 HP から要約を作る

準備フローの起点になる Skill です。大会名をハードコードせず、URL を渡せば動く ようにしています。

---
name: hackathon-summary
description: >-
  ハッカソンの公式ページを取得し、要約Markdownとプロジェクト基本構成を作成する。
  要約作成・レギュレーション整理・参加準備の依頼時に使用。情報源の照合と検証を必須とする。
---

ワークフローの要点は次のとおりです。

- [ ] Step 1: 情報源の特定と取得（応募要項を最優先）
- [ ] Step 2: 情報の抽出・分類
- [ ] Step 2.5: クロスチェック（必須）
- [ ] Step 3a: 要約ファイルの作成（docs/）
- [ ] Step 3b: プロジェクト構成の作成
- [ ] Step 4: 品質チェック（verified: true は検証完了後のみ）

推測で埋めない、応募要項が正、年次・ラウンドを混ぜない — この3つを Skill 内の原則として固定しています。
以降の Skill はすべて、この要約ファイルを前提に動く想定です。

1. hackathon-ideation — アイデア出し

Skill の先頭は、Cursor が「いつ読むか」を判断するための frontmatter です。

---
name: hackathon-ideation
description: >-
  短期型ハッカソン（数時間〜1日）向けのアイデア出し。テーマに沿ったMVP案の発散・絞り込み・
  実現性評価・docs/ideas/ への候補記録と docs/idea.md への採用反映。ブレスト・アイデア出し・
  MVP決定・チーム議論・テーマ確定後の方針整理の依頼時に使用。
---

テーマ告知前後でモードを分けています。

モード	いつ	目的
prep	テーマ未確定	議論ルールの合意・練習
live	テーマ確定後	候補生成 → 比較 → 採用

live モードのワークフローは、チェックリスト形式で書きました。

Task Progress:
- [ ] Step 1: 制約の収集
- [ ] Step 2: テーマ解釈の確認（人間必須）
- [ ] Step 3: 発散（10案以上）
- [ ] Step 4: 候補ファイル作成（上位5〜10案）
- [ ] Step 5: 実現性スコアリング → comparison.md 更新
- [ ] Step 6: 人間による議論・shortlisted 決定
- [ ] Step 7: 最終決定 → idea.md 反映

人間と AI の分担も Skill 内に固定しています。

担当	人間	AI
テーマ解釈の合意	●	解釈案の提示のみ
10案以上の発散		●
shortlisted / 最終決定	●	推奨のみ

Step 6 の出力フォーマットまで書いておくと、エージェントが 勝手に1案を決め打ちしにくく なります。

## shortlisted（議論用）

1. **01** — 理由
2. **03** — 理由
3. **05** — 理由

→ どれで進めますか？

3時間大会向けに、議論のタイムボックスは 5分 と明記しました。

2. mvp-scorer — 実現性の採点表

hackathon-ideation から参照する採点ルールです。5観点 × 3点満点の15点制です。

#	観点	3点の例
A	開発時間内に Must が完結	余裕あり
B	テーマ適合	直球で一致
C	審査で伝わる	操作だけで即理解
D	動くプロダクト	1機能が確実に動く
E	技術リスク	既知スタックのみ

9点未満は採用しない、A が2点未満なら他が満点でも推奨しない、というルールも書いてあります。
当日は「かっこいい案」より「3時間で URL が出る案」を優先させるためです。

3. hackathon-design-md — UI を揃える

アイデア確定後、フロント実装の前に使う Skill です。
Google design.md 準拠の DESIGN.md を作ります。

---
name: hackathon-design-md
description: >-
  短期型ハッカソン向けに Google design.md 仕様の DESIGN.md（UIデザインシステム）を
  作成・更新する。YAML design tokens + Overview/Colors/Typography 等8セクション。
  デザインシステム・UI統一・ブランドトークン・DESIGN.md 作成の依頼時に使用。
---

3時間向けの最小セットも Skill 側で定義しています。

必須 tokens	必須セクション
colors, typography, spacing, rounded, components	Overview, Colors, Typography, Layout, Components, Do's and Don'ts

120行以内を目標に書く、という制約も入れました。細部まで詰めるより 一貫性 を取るためです。

4. hackathon-tasks-plan — タスク分解

idea.md が決まった直後に1回だけ走らせる Skill です。

---
name: hackathon-tasks-plan
description: >-
  短期型ハッカソンでアイデア確定後に docs/tasks.md へ詳細な初期タスクを作成する。
  idea.md の MVP・レギュレーション要約の審査方式・開発時間から P0/P1 を分解。
  タスク計画・初期 tasks 作成・役割分担の依頼時に使用。
---

優先度の定義はこう書いています。

優先	意味
P0	Must + 横断タスク。未完成だと審査・提出不可
P1	Nice。P0 後のみ
P2	記録のみ（当日やらない）

1タスク = 30分以内、Must 1行 = 最低1 P0、という分解ルールも Skill に入れてあります。

5. AGENTS.md — Skill への入口

Skill 一覧そのものは、ルートの AGENTS.md にも載せています（抜粋）。

## チーム運用

- ブレスト → docs/ideas/ に候補追加、comparison.md で議論
- テーマ確定 → docs/idea.md → hackathon-design-md で DESIGN.md
  → hackathon-tasks-plan で docs/tasks.md 初期化
- 開発中 → hackathon-tasks-sync で進捗更新
- 議論が5分超えたら MVP を削って決める

## Cursor Skills

| Skill | 用途 |
|-------|------|
| hackathon-ideation | アイデア出し |
| hackathon-competitive-analysis | 競合分析（Web 検索） |
| hackathon-design-md | UI デザインシステム（DESIGN.md） |
| hackathon-tasks-plan / hackathon-tasks-sync | タスク計画・進捗 |
| hackathon-bedrock | Bedrock / Lambda / API 実装 |

当日発表された「審査員が IT 素人」、という制約も AGENTS.md に書いて、design Skill と内容を揃えています。
印象としては、その制約を付け加えてから、デザインの彩度や雰囲気が明るくハッキリとなり、文字も大き目になりました。

| 原則 | 具体例 |
|------|--------|
| 専門用語を使わない | 「API」「プロンプト」等は画面に出さない |
| 最初の1画面で目的が分かる | キャッチ＋「ここから始める」 |
| 操作は最小・大きく | 1画面1 primary CTA |

実際の使い方（チャットでの依頼例）

進捗や新規情報に合わせて、ルートの AGENTS.md やDESIGN.md は、更新を依頼しています。

依頼文に Skill 名を入れると、Cursor が .cursor/skills/ 配下を読みに行きやすくなります。毎回 AGENTS.md 全文を貼るより楽でした。

AI に Skills を作らせたときのコツ

1. 制約は docs/ に逃がす（Skill に大会名を書かない）

Skill より先に hackathon-summary で 人間が読む一次情報 を docs/ に置きます。
Skill 側は「docs/*-regulation-summary.md を読んで動け」と書くだけにすると、別のハッカソンでも Skill を流用しやすく、ハルシネーションも減ります。

2. 「1 Skill = 1 フェーズ」で依頼する

いきなり「ハッカソン用 Skill 全部作って」は避け、1つずつ 頼みました。

ハッカソンURLを渡して、用途の希望を出しながらskill作成を依頼します。一旦書かせてから、再度「汎用的に使用できるようにして」と見直しを依頼しています。
また、自分の中で十分と感じても、最後に「他に必要と考えられる仕組みはありますか？」と逆に質問して、用途と有用度別に提案をしてもらいます。

Cursor には create-skill 用の Skill もあるので、Skill の書き方自体も AI に任せられる のが楽でした。

3. AGENTS.md で Skill への入口を固定する

ルートの AGENTS.md に、Skill 一覧と「いつ使うか」を表形式で書きました。
2名で別 PC から作業しても、Git 上の AGENTS.md が共通の入口 になります。

Skill 内に API キーや .env の実値は書かない。.cursor/ は Git 管理するが、秘匿情報は .env のみ、というルールも AGENTS.md に明記しています。

長く使う Skills との使い分け

ハッカソンskillsは 「その場で役に立てば十分」 という割り切りをしています(ﾉ´∀｀*)
準備に時間を書けずに、それぞれのskillsの中身までは確認していません。

うまくいったこと・しんどかったこと

うまくいったこと

• prep / live の2モード を Skill に書いておくと、5/30 当日の切り替えがスムーズ
• docs/ideas/ を2人で別 PC から同じ候補表で議論できた
• 1つの提案から派生でアイデア提案が5つも出てきたりしたので、楽でした
  • 一番、「タービン」らしいアイデアとの評価でした（笑）
• 審査員向け UX を AGENTS.md と design Skill の両方に書いた
  • デザイン素人なので、AIに任せられるのは楽だった
  • 工夫次第では、もっとテーマに合わせて簡単に凝れるとは感じました

しんどかったこと

• docs/ideas/ を同じ形式で作成できたので、見比べはしやすかったが、Git等にやるのも面倒で、結局PC2台を並べて見ていた（物理）
  • 共有方法をもう少し考えとけば良かった
• テーマ「タービン」の解釈（直球 vs 比喩）で、迷走しました（笑）
  • アイデアに時間を一番かけたので、推測したイメージとは違った
  • 「IT素人」の評価基準が想定外だった

まとめ

準備の流れは HP の URL → 要約ファイル → AGENTS.md → アイデア出し → アプリ作成 です。
特にアイデア出し Skill は「発散は AI、決定は人間」を Skill 内に明文化できて、3時間開発向きでした。

もし、次にハッカソンへ出る際は、Skillsをコピーするだけで、始める事ができます。
考え込むよりも短期で取り合えず増やして試す。「使い捨てskills」でしたm(_ _)m