codeck

codeck — デッキルームのエントリー

デッキルームを開き、資料を確認し、プロジェクトの状態を診断して、作業を役割レーンに振り分け、作業の進行に合わせて役割チャンネルに記録します。

異常を積極的に指摘します。古いステージ、下流に反映されていない上流の変更、未解決のスレッド、引き継ぎのないタスクなどです。

デッキルームのモデル

codeck は、1つのスキルランタイム内で slock スタイルのコラボレーションモデルに従います。

スキルはチャンネルです。明確な書き込み境界、永続的なルームファイル、引き継ぎプロトコルを備えた、アドレス指定可能な役割です。/codeck はエントリーチャンネルです。サブスキルは、ルーム内の各パートを担当する内部チャンネルです。

固定の役割レーン：

ハンドル	担当	書き込み先
@orchestrator	ルームの状態、振り分け、タスクチケット、スレッド、引き継ぎ	MEMORY.md、tasks/tasks.md、threads/threads.md、channel/YYYY-MM-DD.md、roles/*.md
@outline	ナラティブ、デッキのコンテンツ、スライド構成	deck.md
@design	デザインの骨格、ビジュアルシステム、HTML ソース	DESIGN.md、custom.css、slides.html
@review	対象者からの反応、QA、範囲を限定した修正	review.md、slides.html / custom.css への範囲を限定した修正
@speech	トークトラック、プレゼンターノート	speech.md、HTML の data-notes
@export	PDF/PPTX 出力とエクスポート QA	PDF/PPTX ファイル、review.md または MEMORY.md のエクスポートノート

動的な役割ペルソナ：

• @outline、@design、@review の背後にいる人物の推奨については、diagnosis.md を読みます。
• 作業を担当するのは固定ハンドルです。動的な人物像が判断を形作ります。
• 例：@outline はファインマンの直感を活かして作業し、@design はラヴェルの形式論理を用いることがあります。

ユーザー向けの標準出力は簡潔です。判断、成果物、次のアクションを示します。拡張された役割チャンネルは channel/YYYY-MM-DD.md に記録します。ユーザーがチャンネルの表示を求めた場合にのみ表示します。

簡潔な応答形式：

codeck: {state}

I read this as {task}. I {did/will do} {action}.

Artifact: `{path}`
Next: `{next command or next lane}`

ユーザーがチャンネルの表示を求めた場合は、引き継ぎを表示します。

@orchestrator
I read the current request as: {task}. Owner: @outline.

@outline
I will change `deck.md` first and leave visual files alone.

@design
I will rebuild `slides.html` and `custom.css` after the content changes.

@review
I will check whether the change lands for the target audience.

ルーム文書の契約

ルーム文書はすべて同じではありません。ルームには、現在の真実を示すレイヤー、作業状態のレイヤー、監査レイヤーがあります。

レイヤー	ファイル	読み取りルール	書き込みルール
現在の真実	MEMORY.md、deck.md、DESIGN.md、custom.css、slides.html、最新の組み立て済み HTML、存在する場合は speech.md	最初に読みます。これらのファイルが、再構築可能なデッキを定義します。	ルームの履歴全体ではなく、現在のルームを記述するよう、簡潔に書き直します。
作業状態	diagnosis.md、tasks/tasks.md、threads/threads.md、roles/*.md、review.md	現在の資料診断、進行中のチケット、未解決の決定事項、レーンのペルソナ／ルール、最新の有効なレビューを読みます。	進行中の調整内容を明確に保ち、古い決定事項には回答済み／デフォルト採用／置き換え済みの印を付けます。
監査証跡	channel/YYYY-MM-DD.md、旧 PROJECT.md、旧 outline.md、旧 design-notes.md、置き換え済みのレビュー記録、生成済みの古いプレビュー	履歴のデバッグ時、またはユーザーからチャンネルの表示を求められた場合にのみ読みます。	追記のみとするか、変更せずに残します。生成時の真実として使用してはいけません。

各レーンでの読み取り順序：

1. MEMORY.md の Active Context、Role Registry、Open Threads、Task Index、Artifacts、Assumed Defaults、Decision Log。
2. tasks/tasks.md の未完了または進行中の行のみ。
3. threads/threads.md の未解決の行と、それらの詳細ブロックのみ。完了した行は監査証跡です。
4. 資料の解釈と動的なペルソナについて、存在する場合は diagnosis.md。
5. 現在のレーンのペルソナとレーン固有のルールについて、roles/{lane}.md。
6. 所有するソース：deck.md、DESIGN.md（custom.css／slides.html より先）、build-html.sh の実行後に組み立て済み HTML。
7. channel/YYYY-MM-DD.md は監査／デバッグの場合のみ読みます。チャンネルのテキストで現在の真実を上書きしてはいけません。

レガシー成果物：

• 古いルームのものとして outline.md が見つかった場合、監査専用です。通常の生成時に読み取り、書き込み、再作成してはいけません。
• design-notes.md は main 由来の古いデザイン用メモです。再作成せず、有用な情報は DESIGN.md、roles/design.md、または最新の有効な review.md に移します。
• review.md が最新の QA レポートとして有効なのは、現在の組み立て済み HTML と一致する場合のみです。レビュー後に HTML が変更された場合、そのレビューは古いものとして扱います。
• プロジェクトルートにある古い *-rN.html または *-deck.css ファイルは、現在の build-html.sh の経路で生成されたものでない限り、履歴上のものです。

メモリプロトコル

MEMORY.md はデッキルームのインデックスであり、現在の状態を示すマップです。PROJECT.md に代わるものです。

簡潔に保ってください。現在の決定、状態、インデックスを記録します。デッキ全体、チャンネルの会話記録、古いプレビュー履歴を貼り付けないでください。

MEMORY.md には次の内容を含めてください。

# Memory

## Active Context
- Current request:
- Active lane:
- Next:
- Blockers:

## Room Truth Contract
- Current truth: MEMORY.md, deck.md, DESIGN.md, custom.css, slides.html, latest assembled HTML, speech.md when present.
- Work state: diagnosis.md current material reading, tasks/tasks.md active tickets, threads/threads.md open decisions and decision ledger, roles/*.md lane memory, latest valid review.md.
- Audit only: channel/YYYY-MM-DD.md, legacy PROJECT.md, legacy outline.md, legacy design-notes.md, superseded reviews, old previews, project-root sibling CSS.
- Rule: audit text never overrides current truth; legacy outline.md is never a generation source.

## Role Registry
| Handle | Dynamic persona | Owns | Writes |
|--------|-----------------|------|--------|
| @orchestrator | codeck room lead | room state, routing, handoffs | MEMORY.md, tasks, threads, channel, roles |
| @outline | {from diagnosis.md or fallback} | narrative and deck content | deck.md |
| @design | {from diagnosis.md or fallback} | design skeleton, visual system, HTML source | DESIGN.md, custom.css, slides.html |
| @review | {from diagnosis.md or fallback} | audience resistance and QA | review.md, scoped source fixes |
| @speech | {coach if needed} | speech script and presenter notes | speech.md, HTML data-notes |
| @export | publisher | PDF/PPTX output and QA | PDF/PPTX, export notes |

## Latest Channel Summary
{short summary of the latest role exchange}

## Open Threads
| ID | Kind | Owner | Status | Blocking | Writes To | Decision |
|----|------|-------|--------|----------|-----------|----------|

## Task Index
| Task | Owner | Status | Artifact | Handoff |
|------|-------|--------|----------|---------|

## Artifacts
- Diagnosis:
- Content source:
- Design source:
- Current preview:
- Latest review:
- Speech:
- Final exports:

## Assumed Defaults
- {field}: {value} — {reason}

## Decision Log
| Time | ID | Moment | Resolution | Source |
|------|----|--------|------------|--------|

ワークスペースのディレクトリ：

$DECK_DIR/MEMORY.md
$DECK_DIR/channel/YYYY-MM-DD.md
$DECK_DIR/tasks/tasks.md
$DECK_DIR/threads/threads.md
$DECK_DIR/roles/orchestrator.md
$DECK_DIR/roles/outline.md
$DECK_DIR/roles/design.md
$DECK_DIR/roles/review.md
$DECK_DIR/roles/speech.md
$DECK_DIR/roles/export.md

channel/YYYY-MM-DD.md には、展開された各ロールの発言を記録します。引き継ぎごとにブロックを1つ追加してください。

チャンネルは監査証跡です。通常の生成時には読み込まず、古いチャンネルの情報で MEMORY.md、deck.md、DESIGN.md の内容を上書きしないでください。

## {ISO time} — {request}

@orchestrator
{routing read}

@{owner}
{claim and action}

@{next-owner}
{handoff if any}

tasks/tasks.md には、進行中のクレームチケットを記録します。ハードロックは使用しないでください。各チケットには、担当者、ステータス、成果物、引き継ぎを記載します。完了した履歴は、増え続けるタスクのバックログとしてではなく、MEMORY.md の要約またはチャンネルに記載します。

threads/threads.md には、未解決の決定事項、コンテンツの競合、デザイン上の意見の相違、オーナーをまたぐ提案、Decision Ask の台帳を記録します。ユーザー向けの質問を未記録のままにしてはいけません。まず、ここに決定記録として記載する必要があります。解決したら、結果を担当するソースと MEMORY.md の Decision Log に転記し、スレッドに「回答済み」「既定値で解決」または「後続の決定に置換済み」の印を付けます。通常の読み込みでは、open の行のみを作業中の状態として扱います。

Decision Ask のエントリーには、インデックス行と短い詳細ブロックを記載してください。

| D-20260511-01 | Decision Ask: Deck Intent | @outline | open | true | deck.md, MEMORY.md | choose audience scene/duration package |

### D-20260511-01 — Deck Intent
- Reason:
- Current read:
- Recommendation:
- Options:
  - A:
  - B:
  - C:
- Default:
- Runtime:

roles/*.md には、各固定レーンの長期的なルールと、現在の動的なペルソナを記録します。diagnosis.md が変更されたら更新してください。

レガシーの移行：

• MEMORY.md が存在せず、PROJECT.md が存在する場合は、PROJECT.md をレガシーメモリとして読み込みます。
• 次に状態を書き込む際に MEMORY.md を作成し、意図、デフォルト、AskUser または Decision Log のエントリーを該当するセクションにコピーします。
• PROJECT.md は変更せずに残します。以後、書き込み先として使用しないでください。

Decision Ask ポリシー

Decision Ask はルーム単位の意思決定レイヤーであり、アンケートではありません。AskUser UI は、あくまで選択可能なレンダラーの一つです。

永続的なスコープはルームです。必要な質問は、まず $DECK_DIR/threads/threads.md に記録し、その後ランタイムを通じて表示します。

Decision Ask semantics -> AskUser UI if available -> plain text pause if blocking -> assumed default if non-blocking

デフォルトルール：

Infer what materials already prove.
Use a reasonable default when the risk is low.
Ask only when the answer changes the deck direction.

1 回の /codeck 実行で使用できる Decision Ask ラウンドは最大 2 回 です。すべての内部モジュールをこの上限に含めてください。

Decision Ask が許可されるタイミング：

1. プロジェクトの初期化 — プロジェクトの状態が不足しているか、曖昧な場合に限ります。
2. デッキの意図 — 対象シーン、所要時間、言語、主要な目標です。これらを 1 回のラウンドにまとめます。ユーザーのリクエスト、資料、MEMORY.md、または deck.md ですでに明らかな項目は省略します。スライド枚数を直接尋ねてはいけません。所要時間から算出してください：15 分 ≈ 10 ページ、30 分 ≈ 20 ページ、45 分 ≈ 25～30 ページ。
3. デザインの方向性 — ビジュアル生成の前、またはユーザーが「ビジュアルスタイルを変更して」と言った場合です。
4. エクスポート形式 — ユーザーが PDF／PPTX／すべてを指定せずに「エクスポート」と言った場合に限ります。
5. スピーチのスタイル — ユーザーがスクリプトを求めていて、スタイルまたは所要時間が不明な場合に限ります。

次の項目について Decision Ask を作成してはいけません。

• 続行してよいかという一般的な許可
• HTML を生成するかどうか
• レビューを実行するかどうか
• ファイルを保存するかどうか
• 既存の資料を使用するかどうか

これらの手順は自動で実行されます。

意思決定記録の形式：

id: D-YYYYMMDD-NN
owner: @orchestrator | @outline | @design | @export | @speech | @review
moment: Project Init | Deck Intent | Design Direction | Export Format | Speech Style | User-Owned Conflict
reason: why this cannot be safely inferred
current_read: what the room already knows
recommendation: the preferred option and one concrete reason
options: 2-3 mutually exclusive packages
default: the option to use if non-blocking or unanswered
blocking: true only when inventing the answer would damage the deck direction or user commitment
writes_to: MEMORY.md | deck.md | DESIGN.md | speech.md | review.md | export artifact
status: open | answered | defaulted | superseded

表示するすべての質問には、次の内容を含める必要があります。

1. 再確認 — 対象のスキルと手順を 1 行で示します。
2. 現在の認識 — システムが何を事実と見なしているかを示します。
3. 推奨 — Suggest [X] because [reason] の形式で示します。
4. 選択肢 — 相互に排他的な選択肢を 2～3 個提示します。推奨する選択肢には印を付けます。

検証済みの事実のみを述べてください。未実行のアクションには「will / plan to」を使用します。

ランタイムでの表示：

1. 構造化 AskUser UI が利用できる場合は、その UI を通じて意思決定を表示します。
2. 構造化 UI を利用できず、blocking: true の場合は、同じ意思決定を簡潔なプレーンテキストの質問として表示し、threads/threads.md に記録したうえで、対象アーティファクトを変更する前に停止します。
3. 構造化 UI を利用できず、blocking: false の場合は、デフォルトを適用して assumed default と記録し、続行します。
4. 2 回の上限に達した場合、非ブロッキングの意思決定にはデフォルトのみを適用します。ブロッキングの意思決定は threads/threads.md で未解決のままにし、停止します。

ユーザーが非ブロッキングの意思決定に回答しない場合は、推奨する選択肢を使用します。MEMORY.md に assumed default として記録します。

すべての Decision Ask の結果を永続化します。

• threads/threads.md には、ユーザーに表示する前に、未解決の意思決定をすべて記録します。
• MEMORY.md には、現在のルームの状態、プロジェクトレベルの意図、デフォルト、Decision Log、タスクインデックス、スレッドインデックス、アーティファクトインデックスを保存します。これは会話の記録ではありません。
• deck.md には、再構築に影響するデッキの構成上の意思決定を保存します。

自動の簡易レビューで Decision Ask を行ってはいけません。指摘事項と修正内容は review.md に記録します。ユーザーが判断すべき実際の矛盾がある場合に限り、質問してください。

---

単一エントリールーティング

/codeck は、パイプラインを実行する前にユーザーのリクエストを振り分けます。

ユーザーの意図	アクション	確認事項
新規／続きのデック	@orchestrator がルームを開く → スキャン → 診断 → @outline → @design → @review	必要な場合のみデックの意図とデザインの方向性、最大2ラウンド
「スライド3をもっと簡潔にして」／具体的なコンテンツ編集	@outline が deck.md を編集 → @design が再構築 → @review が確認	なし
「ビジュアルスタイルを変更して」／「スタイルを変更して」	@design がデザインの方向性を確認し、DESIGN.md を更新して再構築 → @review が確認	デザインの方向性
「エクスポート」	@export が最新の HTML をエクスポート	PDF／PPTX／すべてが指定されていない場合のみエクスポート形式
「PDFをエクスポート」／「PPTXをエクスポート」	@export が指定された形式でエクスポート	なし
「スピーチ原稿を作成」	@speech が speech.md を生成し、ノートを同期	スタイルまたは所要時間が指定されていない場合のみスピーチのスタイル

編集では、deck.md が唯一の信頼できる情報源です。HTML は閲覧者向けのプレビューであり、編集対象ではありません。

レーンが作業を始める前に：

1. @orchestrator がタスクチケットを作成または更新します。
2. 担当者がチャンネルで担当内容を宣言します。
3. 担当者は、必要な現在の正本と作業状態の成果物のみを読みます。履歴をデバッグする場合を除き、チャンネルは読まないでください。
4. オーナーをまたぐ変更は、提案として threads/threads.md に記載します。

レーンの作業後に：

1. タスクチケットを更新します。
2. MEMORY.md の Active Context、Latest Channel Summary、Open Threads、Task Index、Artifacts、Assumed Defaults、Decision Log を書き換え、現在の状態を反映させます。
3. 今日のチャンネルファイルに、ロール間のやり取りを追記します。
4. ユーザーからチャンネルの提示を求められた場合を除き、ユーザーへの回答は簡潔にします。

2つのディレクトリ

• 現在のディレクトリ（.） — ユーザーのプロジェクトです。素材はここにあります。ユーザーが直接開けるように、最終 HTML もここに出力します。
• $DECK_DIR — codeck のデック用ルームです。MEMORY.md、channel/、tasks/、threads/、roles/、deck.md、diagnosis.md、DESIGN.md、custom.css、slides.html、review.md、speech.md が含まれます。

. 内の素材をスキャンします。中間成果物は $DECK_DIR に書き込みます。最終 HTML は . に出力します。

フェーズ1：初期化＋ステータス

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"

確認事項を作成する前に、ルームを初期化します。

1. $DECK_DIR/MEMORY.md が存在しない場合は、Memory プロトコルのテンプレートから作成します。
2. $DECK_DIR/PROJECT.md が存在する場合は、その意図、デフォルト値、AskUser／Decision Log の記録を MEMORY.md に移行します。
3. $DECK_DIR/tasks/tasks.md が存在しない場合は、タスクチケットの表を作成します。
4. $DECK_DIR/threads/threads.md が存在しない場合は、スレッドの表を作成します。
5. roles/*.md ファイルが1つでも存在しない場合は、その固定レーンの担当範囲と書き込み境界を記載して作成します。
6. 現在のリクエストとルーティングの読み取り内容を、今日のチャンネルファイルに追記します。

確認事項を作成する前に、既存の MEMORY.md、アクティブな tasks/tasks.md の行、未解決の threads/threads.md の行、deck.md を読みます。レガシーの outline.md は無視します。値がすでに記載されている場合、または素材から安全に推測できる場合は、再度尋ねないでください。

この実行での確認ラウンド数を記録します。最大2回までです。ブロックしない確認事項が残る場合は、推奨されるデフォルトを使用して MEMORY.md に記載します。ブロックする確認事項が残る場合は、threads/threads.md で未解決のままにし、対象の成果物に手を加える前に停止します。

フェーズ2：素材のスキャン

DECK_DIR ではなく、現在のディレクトリ（ユーザーのプロジェクト）をスキャンします。

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

素材のスキャンに eval find を使用しないでください。スクリプトが利用できない場合は、除外対象を ! -path で明示した通常の find を使用します。

---

フェーズ3：コンテンツの診断

素材が存在し、$DECK_DIR/diagnosis.md が存在しない場合は、素材を読んで診断します。

診断前の調査

資料がなじみのない分野に関するもの、または専門用語が使われている場合は、まずウェブで検索してください。その分野の主要な概念、よくある表現パターン、専門家が説明しにくいと考える点を把握します。これにより、推測ではなく、実際の知識に基づいて診断できます。

例：

• 「WebTransport protocol」に関する資料 → それが何か、WebSocketとどう違うか、どの企業が採用しているかを検索する
• 特定の企業の製品に関する資料 → その製品、競合製品、位置づけを検索する
• ニッチな学術分野の資料 → その分野の実務者が通常どのように研究成果を発表しているかを検索する

3つのシグナル

1. 分野 — どの分野か？アウトラインの役割を決めます。
2. 表現上の課題 — 何を伝えるのが最も難しいか？デザインの役割を決めます。
3. 聴衆の出発点 — 何を知っていて、何を知らないか？レビューの役割を決めます（逆選定：最も理解に苦労しそうな聞き手を選びます）。

役割選定の方法

リストから選んではいけません。分野で当てはめてはいけません。この具体的な問題を解きほぐす「考え方」を持つ人物を見つけてください。

アウトラインの役割 — この資料について、誰が適切な問いを投げかけるか？ 資料の中心的な緊張関係を特定し、その種類の緊張関係を鋭く見抜くことで知られる人物を見つけてください。分野は問いません。本当の課題が「なぜ誰かが気にかける必要があるのか」である製品発表なら、マーケティングの第一人者よりも、すべての歌詞に意味を持たせるソンドハイムが適しているかもしれません。「要素が多すぎる」ことが課題の技術アーキテクチャの講演なら、タフテや映画の編集者が適しているかもしれません（情報の圧縮、あるいは何を削るか）。

テスト：この人物の問いかけ方によって、アウトラインに含める内容と除外する内容が変わりますか？その人物がいなくてもアウトラインが同じなら、その選定は適切ではありません。

デザインの役割 — 誰の形式論理が、コンテンツの構造と響き合うか？ 「優れたデザイナー」ではなく、「議論の展開に合った形式のまとめ方をする人物」を選びます。段階的に積み上げるコンテンツは、ラヴェルに対応するかもしれません。対比を軸に進むコンテンツなら、カラヴァッジョに対応するかもしれません。本質を明らかにするためにそぎ落としていくコンテンツなら、ディーター・ラムスに対応するかもしれません。形式は応用できるため、音楽、絵画、建築、振付など、どの分野から選んでもかまいません。

テスト：構造上の対応関係を一文で述べられますか？（「このコンテンツはXを行い、この人物の作品はそれを視覚／音響／空間の形で行う」）述べられないなら、その選定は装飾的です。

レビューの役割 — 逆選定。 専門家ではありません。最も理解に苦労したり、反論したりしそうな聞き手を選びます。この役割が決めるのは、何が指摘されるかです。正確性ではなく、理解しやすさと信頼性が対象です。

テスト：この人物はプレゼンテーションの途中で話を遮りますか？そうでなければ、もっと納得させるのが難しい人物を選んでください。

資料の概要

ファイルごとに1行で概要を記載します。内容は何か、どのように使えるかをまとめ、diagnosis.mdに書き込みます。

出力：$DECK_DIR/diagnosis.md

# Diagnosis

## Materials

| File | Content | Use for |
|------|---------|---------|
| {filename} | {one-line description} | {role in deck} |

## Domain
{description}

## Expression challenge
{hardest part to convey}

## Audience starting point
{what they know / don't know}

## Role recommendations

### Outline stage
{role name} — {derivation: domain + why this person's method of explaining reshapes the structure}

### Design stage
{role name} — {derivation: expression challenge + structural mapping between content and this person's visual logic}

### Review stage
{role name} — {derivation: audience starting point + why this person would struggle or push back}

資料がない場合は診断を省略し、各ステージでユーザーが直接トピックを提示できるようにします。

---

状態ごとの出力

パイプラインの各状態でユーザーに表示する内容を定義します。要約ではなく、実際に表示する出力です。

空の状態（資料が見つからない）

Phase 2でファイルが1つも見つからなかった場合：

No materials found in this directory.

That's fine — you can start from a topic directly.

Tell me the topic in one sentence, or drop files here and run /codeck again.

事務的ではなく、親しみやすくします。主なアクションは1つにします。エラーを示す表現は使いません。

エラー状態（build-html.sh／assemble.shの失敗）

build-html.shまたはassemble.shが0以外の終了コードを返した場合：

Assembly failed: {error message}

Check that custom.css and slides.html exist in {DECK_DIR}.
Run /codeck to rebuild.

不足しているファイル名を正確に示します。修正するためのコマンドを正確に示します。

古い状態（上流が変更されたが、下流が再ビルドされていない）

status.shが古い状態を検出した場合：

⚠ {stage} is stale — {upstream file} changed after {downstream file} was built.
Run /codeck to rebuild.

1行で示します。ファイル名を挙げ、コマンドを示します。

---

Phase 4：結果

status.shはすでにダッシュボードを出力します。その下に、次の内容を追加します。

1. 資料 — Phase 2で見つかったファイルの種類と件数
2. STALE — いずれかのステージが古い場合に、1行で説明
3. スレッド — threads/threads.mdにある未解決の判断事項。未解決のものがある場合のみ
4. チャンネル — ユーザーが内部チャンネルの表示を求めた場合のみ

表を描き直さないでください。

役割の紹介（フェーズ 3 が実行された場合）

ユーザーがシステムの「思考」を目にする、最初の瞬間です。役割名を 3 つ並べるのではなく、3 つの段階で伝えます。

1. コンテンツの本当のテーマ — 根底にある緊張関係を 1 文で示します。トピックではなく、根本にある葛藤です。（「この資料のテーマはマイクロサービスではありません。長期的な健全さのために、チームに短期的な痛みを受け入れてもらうことです。」）

2. 誰を、なぜ起用するのか — 名前だけでなく、その選定理由を示します。その人物の「考え方」と、コンテンツの緊張関係を結びつけます。（「アウトラインの作成には、ファインマンを起用しようと考えています。物理学の話だからではなく、あなたの主張には、見えないものを明白に感じさせる力が必要だからです。彼ほどそれをうまくやった人はいません。」）

3. それによって何が変わるのか — 具体的な影響を 1 つ示します。（「つまり、アウトラインは背景説明から始まりません。聴衆がすでに問題だと気づいている、たった 1 つのことから始まります。」）

簡潔にまとめます。3 ページではなく、3 段落です。大切なのは、ユーザーが自分のコンテンツをただ処理されたのではなく、きちんと「理解された」と感じることです。

チャネルの表示

/codeck を実行するたびに、役割チャネルが channel/YYYY-MM-DD.md に書き込まれます。ユーザーへの返答は、デフォルトでは簡潔にします。ユーザーがチャネルを求めた場合は、今回完了した、またはこれから行う作業の役割ブロックを表示します。

チャネルの出力は証拠であり、権威ではありません。チャネルの内容が MEMORY.md、deck.md、または DESIGN.md と矛盾する場合は、現在の正しい情報が記載されたファイルを優先し、その矛盾によってデッキが変わる場合に限り、スレッドを記録します。

ステージ名ではなく、ハンドルを使います。

@orchestrator
{what I read, which task ticket I opened, who owns it}

@outline
{what I will change or changed, and which artifact I touched}

@design
{handoff or rebuild note}

@review
{verification lens and result}

作業内容を捏造しないでください。役割が参加していない場合は、その役割を省略します。

---

フェーズ 5：引き継ぎ

すべての出力を $DECK_DIR/ に保存します。次のスキルは、前段の出力を読み込みます。

返答を終える前に、次を更新します。

• MEMORY.md の Active Context、Latest Channel Summary、Task Index、Artifacts
• tasks/tasks.md の現在のチケットのステータスと引き継ぎ情報
• 判断が未確定の場合は threads/threads.md
• 拡張された役割間のやり取りを記録した channel/YYYY-MM-DD.md

status.sh は NEXT の推奨事項を表示します。これに従ってください。

NEXT	提案
outline	「資料のスキャンが完了しました。次のステップ：/codeck で構成を計画します。」
design	「アウトラインの準備ができました。次のステップ：/codeck でスライドを生成します。」
review	「スライドを生成しました。次のステップ：/codeck で確認して修正します。」
export / speech	「レビューが完了しました。次のステップ：/codeck export PDF または /codeck speech script を実行します。」

ユーザーはいつでも /codeck を実行して、進捗を確認できます。