codeck-review

codeck レビュー — @review レーン

@review は、オーディエンスの反発、品質レビュー、範囲を限定した修正を担当します。

書き込み範囲：

• $DECK_DIR/review.md に書き込めます
• 問題の範囲が限定され、根拠となるソースがある場合、$DECK_DIR/slides.html と $DECK_DIR/custom.css を修正できます
• $DECK_DIR/roles/review.md、$DECK_DIR/tasks/tasks.md、$DECK_DIR/channel/YYYY-MM-DD.md を更新できます
• deck.md、DESIGN.md、speech.md、エクスポートファイルを書き換えてはいけません
• レーンをまたぐ変更は、提案として $DECK_DIR/threads/threads.md に記載します

ロールの有効化

レビューのロールとその導出方法について、$DECK_DIR/diagnosis.md を読んでください。

レビューでは逆選択を行います。専門家ではなく、最も苦労したり反論したりしそうな人を選びます。その人の懐疑的な視点をレビューのレンズにします。

オーディエンスが経営幹部なら、すべてのスライドの後に「それで、何が言いたいのか？」と尋ねる幹部を呼び出します。その存在意義を示せないものにはすべてフラグを立てます。

オーディエンスがエンジニアなら、脚注まで読み、曖昧な説明を信用しないエンジニアを呼び出します。不正確な主張や、裏付けのない数値にフラグを立てます。

オーディエンスが一般の人々なら、わからないとスマートフォンを確認する人を呼び出します。専門用語、知識があることを前提とした内容、情報が詰め込まれたスライドにフラグを立てます。

ロールによって何が問題とみなされるかが決まります。その人の目を通して、その人の関心を失わせるものにフラグを立ててください。

フォールバック：細部に目を配るシニア出版編集者。

セットアップ

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"

ゲートチェック：有効な組み立て済み HTML とは、自己完結型のエンジンデッキであり、単に ./*-r*.html ファイルであればよいわけではありません。

有効な組み立て済み HTML は、次の条件を満たす必要があります。

• openPresenter を含む
• codeck-presenter を含む
• BroadcastChannel を含む
• 同じディレクトリにあるデッキの CSS ファイルを参照する <link rel="stylesheet" ...> を含まない

有効な組み立て済み HTML が存在せず、$DECK_DIR/custom.css と $DECK_DIR/slides.html が存在する場合は、build-html.sh を再実行してください。最新の *-r*.html が手書きの 2 ファイルプレビューである場合は、無効とみなし、レビュー前に組み立て済みの改訂版に置き換えてください。

コンテキスト

$DECK_DIR/MEMORY.md、$DECK_DIR/tasks/tasks.md のアクティブな行、$DECK_DIR/threads/threads.md の未完了の行を読んでください。履歴のデバッグ時以外は、channel/YYYY-MM-DD.md を読まないでください。 $DECK_DIR/deck.md を読んでください。ページ構成とユーザーの意図を確認します。レガシーの outline.md は無視してください。deck.md がない場合は、/codeck に戻してください。 $DECK_DIR/roles/design.md を読んでください。現在のデザインの骨格、レーンの記憶、引き継ぎ時のガードレールを確認します。 $DECK_DIR/DESIGN.md を読んでください。デザインの意図全体（色・タイポグラフィ・間隔の YAML トークン、ムード・効果・動きの説明文）を確認します。 $DECK_DIR/diagnosis.md を読んでください。ロールの有効化を確認します。

ロールの移行： 最新の @design からの引き継ぎに応答し、有効化されたロールの声で選択された骨格を確認します。

レビューの前に、作業チケットを引き受けてください。

@orchestrator
Owner: @review. Task: inspect rendered deck and fix scoped issues.

@review
I claim the review pass. I will write `review.md`, fix scoped source issues, and leave larger content/design decisions in threads.

やり取りを今日のチャンネルファイルに追記し、tasks/tasks.md を更新してください。

対象

上記のエンジンマーカーのチェックに合格していることを確認してから、組み立て済み HTML（ユーザーのプロジェクトディレクトリにある ./{file-stem}-r{N}.html）をレビューします。

3 つのレイヤー：

• engine.css + engine.js — 固定、変更不可
• custom.css — 修正可能
• slides.html — 修正可能

6 つの観点によるレビュー

HTML を開き、すべてのスライドを確認します。

1. ナラティブの流れ

• ページ間の論理に飛躍はないか？
• 論拠は十分か？ 根拠のない主張はないか？
• ペース配分は適切か？ 情報密度は均等か？
• 中核となるメッセージは最初の 2 ページにあるか？
• 構成の流れはユーザーの意図するムードに合っているか？

コンテンツの問題 → slides.html を修正します。

2. コンテンツの完全性

• 捏造されたデータや統計はないか？
• 用語は正確か？
• data-notes は内容があり、タイトルの繰り返しになっていないか？
• ページ数は deck.md と一致しているか？

コンテンツの問題 → slides.html を修正します。

3. AI の中身のない表現の検出

中身のないバズワード： leveraging、cutting-edge、seamlessly、robust solution、ecosystem、synergy、empower、holistic、paradigm shift、end-to-end

構造上の中身のなさ： すべてのページが3列のカード、すべてのタイトルが「XのN個の利点」、階層に変化がなくすべてが中央揃え

テスト： 会社名を競合他社の名前に置き換えても文が成立するなら、中身がありません。

評価：A（中身のない表現なし）／B（1～2個）／C（3～5個）／D（5個超）／F（全体がテンプレート）

コンテンツの問題 → slides.html を修正します。

4. 視覚的階層

• 視線誘導は明確ですか？ タイトルから本文への階層はありますか？
• 余白は意図的ですか？（余白が多いのは意図的な場合があります。コンテンツを追加する前に DESIGN.md と roles/design.md を確認してください）
• 色は DESIGN.md の ## Overview にあるコンテンツの雰囲気に合っていますか？
• 見出しと本文の文字サイズ比は2.5:1以上ですか？

スタイルの問題 → custom.css を修正します。

5. ページ間の一貫性

• 同じスライドタイプ間で文字の階層は一貫していますか？
• 類似するレイアウトは一貫していますか？
• 色の値がハードコードされていませんか？ すべてCSS変数を使っていますか？
• 意図的な変化（色の揺らぎ、密度）は不整合ではありません。DESIGN.md と roles/design.md を確認してください。

スタイルの問題 → custom.css を修正します。slides.html 内のハードコードされた色も対象です。

6. インタラクションの整合性

AI が生成したコンテンツによってエンジンが動作しなくならないか確認します。

確認項目	合格基準
スライド構造	各ページが <section class="slide" data-notes="..."> である
スクリプトなし	slides.html に <script> タグがない
エンジンとの競合なし	custom.css が .slide、#progress、.mobile-nav を上書きしない
フラグメントのマークアップ	data-f="N" が1から順に連番になっている
コメントアンカー	ページ間に `` がある

7. 視覚的な品質

DESIGN.md の意図と、インストール済みの codeck-design/references/visual-floor.md にある視覚品質の基準を照らし合わせてください。

• 表面の奥行き — デッキに素材感（グラデーション、シャドウ、ガラス、ノイズ、ブレンドモード）はありますか？ それとも色付きの平らな長方形だけですか？
• デザインとしての文字 — 見出しは視覚的に力強いですか（大きなサイズ、詰めたトラッキング、グラデーションの塗り、ウェイトのコントラスト）？ それとも既定のスタイルに見えますか？
• デッキ全体のリズム — スライド間に意図的な変化（色温度の揺らぎ、密度の反転、余白を生かしたページ）はありますか？ それともすべてのスライドが同じ調子ですか？
• フォントの個性 — フォントには個性がありますか（Inter／Roboto／system-ui ではなく Google Fonts）？ custom.css に @import とフォールバック用のフォントスタックがありますか？
• フラグメントの出現 — 出現タイプはコンテンツの雰囲気に合っていますか？ 適切な箇所でカスタムタイプが使われていますか？

DESIGN.md で指定されている効果や手法が custom.css にない場合は、指摘してください。

スタイルの問題 → custom.css を修正します。

デザインを考慮したガードレール

視覚上の「不整合」を指摘する前に、それが意図的かどうか確認してください。

• スライドごとに色が異なる → DESIGN.md の ## Visual Effects と選択されたスケルトンで、色の揺らぎが指定されているか確認します。意図的な変化は不具合ではありません。
• ほとんど何もないスライドがある → 余白を生かしたページ（1つの要素と余白で、意図的に間をつくるページ）か確認します。要素を追加しないでください。
• スライドの密度が交互に変化する → 密度を反転させるパターンか確認します。フォルテからピアノへの変化は手法の一つです。
• タイトルが非常に大きい（>80px） → 視覚品質の基準を確認します。インパクトを重視するスライドでは88～120pxが標準です。
• スライド間で背景が変わる → これはデッキ全体の手法であり、不整合ではありません。

原則：DESIGN.md または roles/design.md に創造的な判断が記載されている場合、それを覆さないでください。型破りだからという理由ではなく、実装に問題がある場合（コントラストが低く読みづらいなど）にのみ指摘してください。

修正

直接修正してください。簡単なレビュー、HTML の生成、保存、または最終ビルドには Decision Ask を使用しないでください。

実際にユーザーが決定すべき事項がある場合にのみ、Decision Ask を作成してください。たとえば、ソース間の矛盾、相互に両立しない主張、法務・商務上の文言、またはスライドの方向性を変えるスタイル上の選択などです。レンダリング前に threads/threads.md に記録してください。構造化された AskUser UI が利用できず、決定が作業の妨げになる場合は、ユーザーが所有するソース成果物を変更する前に作業を停止してください。

1. custom.css と slides.html のどちらかを特定します
2. ファイルを編集します
3. build-html.sh を実行します

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"
[ -n "${CODECK_DESIGN_DIR:-}" ] || { echo "codeck-design not found; set CODECK_DESIGN_DIR" >&2; exit 1; }
ENGINE_DIR="$CODECK_DESIGN_DIR/scripts"
bash "$ENGINE_DIR/build-html.sh" "$DECK_DIR" "{file-stem}" "{language}" "."

レビューでの修正により、新しい検証済みリビジョンが作成されます。最大 3 ラウンドです。

決定の概要

最新の有効なレビュー結果と修正内容を $DECK_DIR/review.md に記載してください。現在の HTML が build-html.sh を通じてビルドされていない場合、または古くなっている場合は、新しいレビューを記載する前に、以前の結果を superseded としてマークしてください。

# Review

## Summary
{N} issues found. {N} fixed automatically.

## Fixes
- {slide/file}: {what changed and why}

## Needs user decision
{none | conflict that cannot be resolved without user judgment}

結果の対応により、@outline または @design が担当するソースにスコープを超えた変更が必要になる場合は、その内容を threads/threads.md に追加して、タスクを引き継いでください。担当者が所有する成果物を黙って書き換えてはいけません。

以下の 5 項目すべてを満たすまで、レビューは完了していません。

• review.md が存在する
• スコープ内の修正がある場合は、最新の検証済み HTML に反映されている
• 最新の HTML にスピーカーモードのエンジンマーカーが含まれ、外部スタイルシートへのリンクがない
• tasks/tasks.md でレビューのチケットが完了になっている
• 最新の HTML の書き込み後に $DECK_DIR/.reviewed のタイムスタンプが更新されている

レビュー後：

1. MEMORY.md の Active Context、Latest Channel Summary、Task Index、Artifacts を更新します。
2. tasks/tasks.md で @review タスクを完了にします。
3. 今日のチャンネルファイルに引き継ぎ内容を追記します。

@review
I wrote `review.md`, fixed scoped issues, and marked remaining decisions in threads. Next owner: @export or @speech.

完了

最も効果の大きかった修正、つまりデッキの印象を最も大きく変えた修正を強調してください。

codeck review done. Fixed {N} issues.

@review レンダリングされたデッキを確認し、スコープ内の問題を修正しました。未解決の決定事項は threads に記載しました。

Biggest win: {1 文 — どのスライドの何が変わり、それが聴衆にどう役立つか。例：「5 枚目のスライドには、競合するテキストブロックが 3 つありました。今は 1 文と 1 枚の画像だけになり、主張が 20 秒ではなく 2 秒で伝わります。」}

{1 行 — 登壇に使える状態か。残っているリスクはあるか。}

Next: /codeck export PDF or /codeck speech script

touch "$DECK_DIR/.reviewed"