提出ガイド

SkillArenaには 成果物提出（Cowork で生成した成果物を提出）と スキル提出（SKILL.mdをサーバ側で実行）の2 つの方式があります。同じスキルが両方で動くように設計するのが目標です。最初の提出は、Cowork で動作を確認しやすい成果物提出から始めるのが向いています。

課題を選ぶ AI AgentとAgent Skills Agent Skills公式仕様

2つの提出方式

どちらも同じスキルを使います。補完的な検証経路として両方を活用するのが理想です。

	成果物提出DIRECT_ARTIFACT	スキル提出SKILL_RUN
何を提出するか	各ケースで生成した成果物（PDFなど）をzipにまとめたもの	SKILL.md本体 + 補助アセット
どこでAIを動かすか	ユーザのCowork（手元で動作確認できる）	サーバ側（hidden test caseで実行）
強み	動作過程が見える。サーバコスト低。デバッグしやすい	未知入力での汎化を検証。他人の環境でも動く保証
例の課題	企画書作成（成果物提出版）	企画書作成（スキル提出版）

どう使い分けるか

同じ課題に成果物提出版とスキル提出版の両方が用意されている場合、まず成果物提出版でCowork 上でスキルを書いて動作を確認し、同じスキルをスキル提出版にもアップロードして未知の入力に対する汎化を検証する流れがおすすめです。

サーバがスキル提出で使う起動プロンプトは、成果物提出の標準起動プロンプトと同一です（例: /proposal-deck {input} を {output} にまとめて）。スキル名は半角英数字・ハイフン・アンダースコアのみ使えます（日本語不可）。ローカルで動いたスキルがそのままサーバ側でも動くよう、入力ファイル名・出力ファイル名や案件メタ情報（想定読者・枚数）をスキル本体にハードコードしない設計を心がけてください。

また、スキルがCowork標準スキル（pdf、pptx、docx、xlsx）に依存することを明示する課題が標準的です。reportlabやpython-pptxなどサードパーティのPython ライブラリは使わず、対応する標準スキルを呼び出してください。

成果物提出のやり方

Coworkで動作を確認しながらスキルを開発する方式です。最初の提出はここから始めましょう。

1
課題を選ぶ
成果物提出版の課題を1つ選びます。例: 企画書作成タスク（成果物提出版）。課題一覧から「成果物提出」ラベルの付いたものを探してください。
2
配布物zipをダウンロード
課題詳細ページから配布物zipをダウンロードし、Coworkでプロジェクトとして展開します。zipの中には各ケースの入力ファイルがcase_a/、case_b/、case_c/ ディレクトリに分かれて入っています。
3
Coworkでスキルを作る（skill-creator）
課題詳細ページの「このスキルの責務」を読み込ませて、Coworkのskill-creatorでスキルのたたき台を作ります。hardcodedの項目はスキル本体に固定し、notHardcodedの項目（想定読者・枚数など）はプロンプト引数で受け取る設計にします。PDFを作る課題ならpdf標準スキルを呼び出します。
4
スキルを書く
下のテンプレートを参考に、課題の制約に合わせたSKILL.mdを仕上げます。入力ファイル名・出力ファイル名はハードコードせず、引数として渡される設計にしてください。
5
各ケースで成果物を生成
課題詳細ページに表示される標準起動プロンプト（例: /proposal-deck case_a/brief01.mdをcase_a/deck01.pdfにまとめて）を順に実行し、すべてのケースで成果物が同じディレクトリに出力されることを確認します。
6
提出zipにまとめて提出
課題詳細ページに表示される提出zip化プロンプトをコピーして実行するとsubmission.zipが作成されます。これを提出フォームからアップロードします。

スキル提出のやり方

SKILL.mdをサーバ側で実行し、未知の入力（hidden test case）に対する汎化を検証する方式です。

1
スキル提出版の課題を選ぶ
スキル提出版の課題を1つ選びます。課題一覧から「スキル提出」ラベルの付いたものを探してください。成果物提出版と同じ課題テーマのスキル提出版が用意されています。
2
制約と責務を抜き出す
ページ数、ファイル名、必須セクション、禁止事項のような必須条件をメモします。課題詳細ページの「このスキルの責務」も合わせて確認し、何をhardcodedとして固定し、何を引数で受け取るかを整理します。
3
Coworkでスキルを作る（skill-creator）
Coworkのskill-creatorを使い、整理した責務をスキル本体に落とし込みます。PDFを作る課題ならpdf標準スキル、Wordならdocx標準スキルを依存として呼び出す設計にします。
4
SKILL.mdを仕上げる
下のテンプレートを使って、進め方・出力条件・最終確認を埋めます。サーバは固定の起動プロンプトでスキルを呼び出します。入力ファイル名・出力ファイル名・想定読者・枚数などをハードコードせず、引数で受け取る設計にしてください。
5
SKILL.mdと補助アセットをzipにして提出
SKILL.mdをzipの一番上に置いて提出します。参考資料やひな形はreferences/、assets/ に入れられます。最初はSKILL.md 1ファイルで始めましょう。
6
結果を見て1点ずつ直す
一度に全部を変えず、description・手順・最終チェックのどこが弱かったかを切り分けて改善します。サーバはhidden test caseで実行するため、ローカルで動いたスキルがそのまま通ることが確認の目安です。

そのまま使えるテンプレート

成果物提出・スキル提出のどちらでも同じSKILL.md テンプレートが使えます。各見出しを課題に合わせて埋めてください。

SKILL.mdテンプレート

---
name: competition-slide-builder
description: >
  メモや要件や課題文から、制約を守ったプレゼン成果物を作るときに使う。
  ページ数・ファイル名・必須セクションなどの必須条件があるときに
  特に有効。制約のないオープンなアイデア出しには使わない。
---

# Competition Slide Builder

## Goal
課題文の制約をすべて満たした提出用プレゼン成果物を作る。

## Operating principles
- 制約遵守がスタイルより優先
- 書き始める前に課題文を全部読む
- 入力にない事実を捏造しない

## Input reading order
1. 出力形式とファイルルール
2. 聴衆と意思決定の文脈
3. ソースのメモや根拠
4. あれば見た目の要件

## Workflow
1. 必須条件をチェックリストに抜き出す
2. タスクを一文で要約する
3. ページ別の構成を作る
4. 各ページに最も強い論点だけを入れる
5. 提出前にチェックリストを通す

## Output contract
- 指定されたファイル名・形式に従う
- 各ページの目的を明示する
- 最後に決定事項または次のアクションを入れる

## Final checks
- すべての必須条件を満たしているか
- 根拠のない主張を追加していないか
- 最終ページで決定/アクションを求めているか

descriptionが一番大事

Skillが使われるかどうかはdescription の質で決まります。「何をするか」ではなく「どんな依頼で使うか」を書きます。

良い例

description: >
  メモや要件からスライド構成案を作るときに使う。
  ページ数・聴衆・必須セクション・決定依頼のような
  明示的な出力制約があるときに適用する。
  純粋なデザイン修正や短いメモだけの依頼では使わない。

弱い例

description: スライドを作る。

呼び出し条件に必要な情報がなく、いつ使うSkillなのか判定できません。

提出するzipの構成

提出方式によってzipの中身が異なります。

成果物提出

各ケースの成果物が入ったディレクトリ構造。提出zip化プロンプトを実行すると自動で作成されます。

submission.zip
├── case_a/
│   └── deck01.pdf
├── case_b/
│   └── deck02.pdf
└── case_c/
    └── deck03.pdf

# 課題ごとの「提出zip化プロンプト」をそのまま実行すれば、
# この構造のzipが自動で作られます。

スキル提出

SKILL.mdをzipの一番上に置くだけで始められます。慣れてきたら参考資料やひな形を足します。

submission.zip
└── SKILL.md

# 慣れてきたら:
submission.zip
├── SKILL.md
├── references/
│   └── writing-rules.md
└── assets/
    └── structure-template.md

提出前チェックリスト

提出直前に確認してください。ここを通すだけでも失点をかなり減らせます。

課題文の必須条件を全部抜き出したか
descriptionに「いつ使うか」と「いつ使わないか」が入っているか
Workflowが入力読解 → 構成化 → 出力 → 最終確認の順になっているか
Output contractに成果物の条件（形式・ファイル名など）が書かれているか
Final checksに失格条件の確認が入っているか
【成果物提出】すべてのケース（case_a/、case_b/、case_c/）で成果物が生成されているか
【スキル提出】入力ファイル名・出力ファイル名をハードコードしていないか

よくある失敗

descriptionが短すぎる
「スライドを作る」だけでは呼び出し条件が弱すぎます。どんな依頼で使い、どんな依頼では使わないかまで書きます。
守備範囲が広すぎる
分析・要約・設計・実装を全部1つのSkillに入れると、いつ使うべきか判定しづらくなります。1つの仕事に絞りましょう。
Output contractがない
途中の手順が良くても最終成果物がぶれます。ファイル名・形式・必須構成まで固定してください。
Final checksがない
最後の3行でもいいので、制約違反を検出する自己検証を入れるだけで失点を減らせます。
長文を詰め込みすぎる
詳細資料を全部本文に入れるより、参考資料を分けて必要時だけ読む構成の方が効きます。
途中で確認待ちになる
提出環境では、作業中に人へ確認を返せません。必要な条件は最初に書き、最後まで進められる形にしましょう。
ファイルパスをハードコードする（スキル提出）
スキル提出では、サーバが別の入力ファイル名でスキルを呼び出します。case_a/brief01.mdのような固定パスを書かず、起動プロンプトの引数から受け取る設計にしてください。

よくある質問

成果物提出とスキル提出はどう違う？: 成果物提出はCoworkで手元でスキルを動かして生成した成果物を提出する方式、スキル提出はサーバがSKILL.mdを受け取ってhidden test caseで実行する方式です。どちらも同じスキルが使われることを想定しています。上の比較表を参照してください。
両方を順に提出してもいい？: むしろそれが推奨フローです。まず成果物提出版でCowork上でスキルを仕上げ、完成したら同じSKILL.mdをスキル提出版にもアップロードして未知入力での汎化を検証してください。
最初はどれくらいの長さで書くべき？: 30〜80行で十分です。大事なのは長さではなく、呼び出し条件・手順・出力条件が分かれていること。
補助ファイルは最初から必要？: いいえ。まず文章だけで再現できるか試し、決まった処理が必要になったときだけ補助ファイルを足します。
Skillが自動で発火しないときは？: まずdescriptionを見直します。「何をするか」ではなく「どんな依頼で使うか」に寄せるのが第一です。
課題で最優先すべきことは？: 課題文の制約を読み落とさないこと。品質改善より先に、ファイル形式・ページ数・必須項目のような失格条件を潰してください。

準備ができたら、課題に挑戦しましょう

まずは成果物提出版でCowork上でスキルを仕上げ、その後スキル提出版でも試してみてください。

課題に挑戦する成果物提出版を見るスキル提出版を見る