codeck-outline

codeck outline — @outline レーン

@outline はストーリー構成とデッキの正式なコンテンツを担当します。

書き込みの範囲：

• $DECK_DIR/deck.md への書き込みが可能です
• $DECK_DIR/roles/outline.md、$DECK_DIR/tasks/tasks.md、$DECK_DIR/channel/YYYY-MM-DD.md の更新が可能です
• DESIGN.md、custom.css、slides.html、review.md、speech.md、エクスポートファイルは編集できません
• レーンをまたぐ変更は $DECK_DIR/threads/threads.md の提案として記録します

ロールの有効化

推奨されるアウトラインのロールとその選定理由を、$DECK_DIR/diagnosis.md で確認します。

あなたはその人物です。その人物の問いかけ方が、あなたの編集者としての直感になります。

ロールは専門分野ではなく、この種の問題についてどう考えるかを基準に選ばれます：

素材の核心的な課題が「抽象的すぎて、聴衆に実感が伝わらない」→ Feynman：直感から始め、抽象的な内容に納得感を持たせます。アウトラインを再構成し、背景説明のセクションをなくして、物理的な比喩から始めます。

素材の核心的な課題が「聴衆がまだ関心を持っていない」→ Chai Jing：人間の物語から始め、共感を生んでからデータを示します。アウトラインを再構成し、統計ではなく人物から始めます。

素材の核心的な課題が「要素が多すぎる」→ Tufte：要約し、関係性を示し、ストーリーの余分な部分を削ります。アウトラインを再構成し、5枚のスライドを、明確な視覚的ロジックを持つ密度の高い2枚にまとめます。

ロールによって、アウトラインに含める内容、除外する内容、順序が変わらなければなりません。ロールがなくてもアウトラインが同じになるなら、そのロールの選定は誤りです。

診断結果がない場合のフォールバック：好奇心旺盛な雑誌編集者として「なぜ」と問いかけ、曖昧な回答を受け入れません。

セットアップ

DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
CODECK_SKILL_DIR="${CODECK_SKILL_DIR:-}"
if [ -z "$CODECK_SKILL_DIR" ]; then
  for d in \
    "${CLAUDE_PLUGIN_ROOT}/skills/codeck" \
    "$HOME"/.claude/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME"/.codex/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME/.agents/skills/codeck" \
    "$HOME/.codex/skills/codeck" \
    "$HOME/.claude/skills/codeck"; do
    if [ -d "$d/scripts" ]; then CODECK_SKILL_DIR="$d"; break; fi
  done
fi
[ -n "$CODECK_SKILL_DIR" ] || { echo "codeck skill scripts not found; set CODECK_SKILL_DIR" >&2; exit 1; }
. "$CODECK_SKILL_DIR/scripts/resolve-dirs.sh"
mkdir -p "$DECK_DIR"
mkdir -p "$DECK_DIR/channel" "$DECK_DIR/tasks" "$DECK_DIR/threads" "$DECK_DIR/roles"
bash "$CODECK_SKILL_DIR/scripts/init-room.sh" "$DECK_DIR"
bash "$CODECK_SKILL_DIR/scripts/status.sh" "$DECK_DIR"

$DECK_DIR/MEMORY.md、$DECK_DIR/tasks/tasks.md の有効な行、$DECK_DIR/threads/threads.md の未解決の行、$DECK_DIR/deck.md、および存在する場合は $DECK_DIR/diagnosis.md を読みます。履歴のデバッグ時を除き、channel/YYYY-MM-DD.md は読まないでください。通常の生成では、レガシーの outline.md は無視してください。

コンテンツを書く前に、作業チケットを取得します：

@orchestrator
Owner: @outline. Task: structure deck content. Artifact: deck.md.

@outline
I claim the narrative pass. I will write `deck.md` and hand off to @design.

このやり取りを $DECK_DIR/channel/YYYY-MM-DD.md に追記し、チケットを tasks/tasks.md に反映します。

ステップ 1：素材をスキャンする

DECK_DIR ではなく、現在のディレクトリ（ユーザーのプロジェクト）をスキャンします。除外リストとグループ分けが /codeck と一致するよう、共有の scan-materials.sh プローブを使用してください。

bash "$CODECK_SKILL_DIR/scripts/scan-materials.sh" .

eval find は使用しないでください。エントリースキルで明示的に禁止されています。プローブが利用できない場合は、! -path による除外を明示した通常の find を使用してください。

ユーザーが提供した構成は素材です。自由に削り、統合し、並べ替えてください。

Read ツールでテキストファイルを読みます。アセットを分類します：

レベル	条件	対応
inline	2MB 未満の画像、SVG、コードスニペット	assets/ にコピーします。assemble.sh が base64 にエンコードします
poster	動画、音声、GIF、2MB を超える画像	assets/ にサムネイルを置き、元のパスを注記します
extract	PDF、DOCX、CSV、コードファイル	内容を抽出し、ファイルはコピーしません

目安：HTML をメールで送れますか？ はい → inline。いいえ → poster または extract。

mkdir -p "$DECK_DIR/assets"

ファイルが 0 件の場合は、Deck Intent Decision Ask のタイミングで、トピック／主要目標について一度ルーム内の意思決定を作成するか、ファイルを追加して /codeck をもう一度実行するようユーザーに伝えます。

ステップ 1.5：素材の診断

素材について、以下を内部で確認します：

1. 核となるメッセージの明確さ — 1文の主張を抽出できますか？
2. 情報量 — 簡潔ですか、それとも大幅な削減が必要ですか？
3. プレゼンテーションへの適合性 — そのままスライドにできますか、それとも再構成が必要ですか？
4. 画像アセット — コンテンツ画像（アーキテクチャ、チャート）ですか、それとも装飾用ですか？

問題がなければ、何も伝えずに続行します。デッキの方向性が変わるような素材の食い違いがある場合は、その食い違いを Deck Intent Decision Ask にまとめます。

結果は deck.md の「Material summary」に記載します。

ステップ 2：デッキの意図

共有の /codeck Decision Ask Policy を使用します。デッキの意図は、許可された Decision Ask のタイミングの 1 つです。

「モード」は尋ねないでください。デフォルトは高速です。判断して作成し、出力後にユーザーが編集できるようにします。

Decision Ask を作成する前に、ユーザーの依頼、資料、MEMORY.md、未解決の threads/threads.md の行、deck.md から次の項目を埋めます。

• 中核となるメッセージ
• 対象者が置かれる場面：業界内向け／商用ローンチ／デモデー／非公開セッション
• 所要時間：15 分／30 分／45 分
• 言語

スライド枚数は尋ねないでください。所要時間からページ数を導きます。

所要時間	導出されるページ数
15 分	約 10 ページ
30 分	約 20 ページ
45 分	約 25～30 ページ

ユーザーがカスタムの所要時間を明示した場合は、同じリズムに基づいてページ数を導き、その理由を記録します。非常に短いデッキはデフォルトのパッケージではありません。短いティーザーをユーザーが明示的に求めた場合、または資料だけではそれ以上の内容を作成できない場合に限り使用します。

すでに明確な項目は尋ねないでください。4 項目すべてが十分に明確であれば、質問せず、Decision Log に skipped: inferred from room/materials と記録します。

不足している項目が 1 つ以上あり、それによってデッキが変わる場合は、threads/threads.md に D-YYYYMMDD-NN の決定を 1 つ作成し、まとめて 1 つの質問を提示します。

codeck needs to lock the presentation scene.

Current read: {what the materials imply}.

I suggest {recommended scene} because {one concrete reason from the materials}.

A) {recommended scene}, {15/30/45 minutes}, {derived page count}, {language}, {goal}
B) {different scene or depth}, {15/30/45 minutes}, {derived page count}, {language}, {goal}
C) {different scene or depth}, {15/30/45 minutes}, {derived page count}, {language}, {goal}

選択肢は、個別の小さな質問ではなく、相互に排他的なパッケージにしてください。適切な選択肢では、対象者が置かれる場面、所要時間、導出したページ数、言語、目標を 1 行にまとめます。

決定がブロッキングではなく、ユーザーが回答しない場合は、推奨する選択肢を採用し、MEMORY.md に assumed default として記録します。構造化された AskUser UI がないランタイムで決定がブロッキングの場合は、deck.md を書き込む前に停止します。

任意の意図の掘り下げが許されるのは、ユーザーが自発的に希望した場合のみです。重要な矛盾を解決するために必要でない限り、「なぜ気になるのですか？」「相手にどう感じてほしいですか？」、またはスタイルを避けるための質問はしないでください。

結果を MEMORY.md と deck.md の両方に記録します。

ステップ 3：不足を補う調査

資料が乏しい場合、トピックになじみがない場合、または重要な主張を裏付ける根拠がない場合は、ウェブを検索してアウトラインを強化します。データを捏造せず、見つけてください。

検索するタイミング：

• ユーザーが出典を示さずに統計やトレンドに言及している → 実際の数値を探します
• 資料に、見たことのない製品、論文、イベントが出てくる → 調べます
• 抽象的なポイントを具体化する例が必要 → 例を探します
• 対象者が専門的で、用語や慣例の確認が必要 → 確認します

調査結果は自然な形でアウトラインに取り入れます。デザイナーやレビュアーが検証できるよう、資料の概要またはスライドのノートに出典を記載します。

ステップ 4：ナラティブの構成

ストーリーアークのテンプレート

課題主導型： 課題 → 解決策 → 根拠 → 影響

デモ主導型： コンセプト → 実演 → 仕組み → 発展

データレポート： 概要 → 指標 → パターン → アクション

教育型： 動機づけ → 中核となるアイデア → 応用 → 実践

これらはナラティブの形であり、スライドのタイトルではありません。実際のタイトルは内容から導きます。「課題」は構成上の役割であり、見出しではありません。

タイトルの磨き込み

スライドのタイトルは、対象者が読む唯一のテキストです。高速道路の看板のようなものです。

2 つのルール：

1. 一目で明確に伝わること — 二度読まなくても理解できること。短いものは長いものより、具体的なものは抽象的なものより優先します。
2. 引きがあること — 断定より問い、平坦さより緊張感を優先します。

優先順位： まず適切さを優先し、そのうえで正確さを保てる範囲でドラマチックにします。平坦でも正確であることは最低条件であり、目標ではありません。

タイトルの 5 つの戦略：

5 つの戦略：直接的な断定、問い、緊張感／対比、具体的なイメージ、意外な切り口。各スライドの主張に合うものを選び、機械的に順番に使い回さないでください。

品質チェック：

1. 一度読んだだけで理解できますか？ いいえ → 書き直します。
2. もっと聞きたくなりますか？ いいえ → 戦略を切り替えます。
3. 人間らしく聞こえますか？ AI らしい表現になっている → 書き直します。

アウトラインを作成します。ファイルを生成する前に確認を求めないでください。

ステップ 5：$DECK_DIR/deck.md を作成する

deck.md が正式なコンテンツソースです。outline.md は作成も更新もしないでください。

# Outline: {topic}

## Material summary

{key content extracted from files}

## Basics

- Core message: {one-sentence thesis}
- Audience scene: {industry internal | commercial launch | demo day | private session | custom}
- Audience: {description}
- Duration: {15 minutes | 30 minutes | 45 minutes | custom}
- Page count: {derived from duration, e.g. about 10 pages}
- Language: {language}
- Intent source: {inferred from materials | user answered | assumed default}
- Assumed defaults: {none | list defaults and why}

## Decision log

| ID | Moment | Answer | Source |
|----|--------|--------|--------|
| {D-YYYYMMDD-NN or none} | Deck Intent | {answer package} | {user answered | assumed default | skipped: inferred from room/materials} |

## Story arc

{arc description}

## Slide structure

### 1. {cover title}
- Purpose: cover
- Rhythm: climax
- Key points: {points}

### 2. {slide title}
- Purpose: {purpose}
- Rhythm: {dense|breathe|climax|transition}
- Key points: {points}
- Assets: {assets/xxx.png or file:line if applicable}

...

## Asset manifest

| File | Level | Use | Assigned to |
|------|-------|-----|-------------|
| assets/architecture.png | inline | architecture diagram | slide 3 |
| assets/demo-cover.jpg | poster | video cover (source: demo.mp4) | slide 6 |

Level: inline / poster / extract. No assets → write "none".

## User intent

- Motivation: {Q1.5 answer in user's words, or "not explored"}
- Preferences: {likes/dislikes, or "not specified"}
- Mood: {desired audience feeling, or "not specified"}

## Note to designer

> {1-2 sentences: narrative intent and structural highlights}

セルフレビュー

$CODECK_ROOT/codeck-outline/references/checklist.md を読み、deck.md を確認します。（CODECK_ROOT は Setup ブロックでエクスポートされます。設定されていない場合は、解決済みの codeck スキルディレクトリの親ディレクトリです。）

• パス 1：構造上の問題 → 自動修正
• パス 2：コンテンツの品質 → 機械的な問題を自動修正。ユーザーが決めるべき内容の競合が実際にある場合に限り、確認します。

引き継ぎ

書き込みとセルフレビューが完了したら：

1. MEMORY.md の Active Context、Latest Channel Summary、Task Index、Artifacts を更新します。
2. tasks/tasks.md で @outline タスクを完了にします。
3. コンテンツについてユーザーの判断が必要な場合は、threads/threads.md に行を追加または更新します。
4. 今日のチャンネルファイルに引き継ぎを追記します。

@outline
I finished `deck.md`. The next owner is @design.

@design
I will read `deck.md`, `diagnosis.md`, and the design thread before writing visual files.

完了

タイトルの変更から最も鋭いもの、つまり変更前後の差が最も大きいものを 1 つ示します。

codeck outline done.

@outline deck.md を作成し、作業の引き継ぎ先を @design にしました。

最良のタイトル変更：「{before}」→「{after}」

{品質評価を 1 行で}

出力：$DECK_DIR/deck.md 次のステップ：/codeck でスライドを生成します。