| name | scenario-quality-review |
| description | シナリオの「魅力」と「読者体験」を検証するセルフレビュースキル。
lintが捕捉する構造的問題（会話比率、ナレーション連続等）の上位レイヤーとして、
「読者が自然に読めるか」「引き込まれるか」「疑問を持たないか」を検査する。
「レビューして」「セルフレビュー」「品質チェック」「読者視点で確認して」
「唐突感がないか見て」「魅力的か確認して」といった依頼で発動。
シナリオ執筆後のセルフレビューフェーズで必ず使うこと。
|
シナリオ品質レビュースキル — 読者の目で検査する
lintは「壊れていないか」を検査する。このスキルは「魅力的か」を検査する。
両方通って初めて、シナリオは出荷可能になる。
レビューの実行手順
Step 0: 前提確認
レビュー対象の章を読む前に、以下を準備する:
- 対象章のファイルを全文読む
- 前章のファイルを全文読む（接続の自然さを検証するため）
- characters.mbt の該当キャラ設定を確認する
- lint結果を確認する（
npm run lint:scenario で構造的問題を先に潰す）
Step 1: 7つの検査軸でレビューする
以下の7軸それぞれについて、問題箇所を具体的な行番号とともに報告する。
検査軸 1: 唐突感検出
読者が「え？」と思った瞬間、物語への没入が切れる。
チェック項目
判定基準
OK: 読者が立ち止まらずに読み進められる
WARN: 一瞬「ん？」となるが、前後の文脈で補完できる
NG: 読者が戻って読み直す必要がある、または理解できない
検査軸 2: 読者の疑問検出
読者が「なんで？」と思って答えが見つからない箇所は、没入の穴になる。
チェック項目
報告フォーマット
[疑問] L{行番号}: {読者が持つであろう疑問}
→ 原因: {なぜこの疑問が生じるか}
→ 対策: {どう修正すれば疑問が解消されるか}
検査軸 3: 「初めて」矛盾検出
「初めて〜した」は強い表現。前のシーンで同等の出来事があると即座に矛盾する。
チェック項目
よくあるパターン
| 表現 | よくある矛盾 | 修正例 |
|---|
| 「初めて声を聞いた」 | 前シーンで同じキャラが話している | 「初めて、近くで声を聞いた」 |
| 「初めて目が合った」 | 前シーンで視線が交差している | 「初めて、ちゃんと目が合った」 |
| 「初めて名前を知った」 | 前シーンで名前が出ている | 削除するか、別の表現に |
検査軸 4: 反復演出の前提確認
「ページがめくれなかった」のような反復演出は、オリジナルが先にないと機能しない。
チェック項目
判定基準
OK: オリジナルが1-3章前にあり、印象的な場面で使われている
WARN: オリジナルが5章以上前。読者が覚えているか不安
NG: オリジナルが存在しない、または同じ章内で反復（近すぎて演出効果なし）
検査軸 5: キャラの魅力度チェック
character-appeal スキルの簡易版。この章でキャラが「愛される」方向に動いているか。
チェック項目
魅力の3指標
| 指標 | 定義 | チェック方法 |
|---|
| 共感性 | 読者が「分かる」と思える言動があるか | モノローグが「俺もそう思う」と思えるか |
| 意外性 | 「この人こういう面もあるんだ」がこの章にあるか | キャラの新しい一面が1つ以上あるか |
| 一貫性 | 前章までの言動と矛盾しない範囲の変化か | characters.mbt の設定と照合 |
検査軸 6: テンポとペーシング
読者の「ページをめくる手」が止まらないか。
チェック項目
テンポの波形チェック
章全体を5等分し、各区間の「動き」を判定する:
理想: 静→動→動→静→余韻
危険: 静→静→静→動→ぶつ切り（序盤が退屈）
危険: 動→動→動→動→動（休む間がなく疲れる）
検査軸 7: サブテキスト（言外の意味）の豊かさ
ADVの魅力は「書かれていないこと」にある。読者が行間を読める余白があるか。
チェック項目
Step 2: レビュー結果の出力フォーマット
以下の形式で報告する:
## シナリオ品質レビュー: {章タイトル}
### サマリー
- 総合評価: {S/A/B/C}
- 最重要の問題: {1行で}
- 最大の強み: {1行で}
### 問題一覧（重要度順）
| # | 検査軸 | 行 | 重要度 | 問題 | 対策 |
|---|--------|-----|--------|------|------|
| 1 | ... | L{n} | HIGH/MED/LOW | ... | ... |
### 良い点
- {具体的な行番号とともに、なぜ良いかを説明}
### 修正優先度
1. {最優先で直すべきもの}
2. {次に直すべきもの}
3. ...
総合評価基準
S: HIGH問題なし。そのまま出荷可能
A: HIGH問題なし。MED問題が1-2個。軽微な修正で出荷可能
B: HIGH問題が1-2個。修正が必要だが構造は健全
C: HIGH問題が3個以上、または構造的な書き直しが必要
Step 3: lint との連携
レビュー実行前に必ず npm run lint:scenario を実行し、構造的問題を先に解消する。
lint が WARN/ERROR を出している状態でこのレビューを実行しても、
lint で捕捉される問題が結果に混ざってノイズになる。
実行順序:
npm run lint:scenario → 構造的問題を修正- このスキルでレビュー → 品質問題を修正
- 再度
npm run lint:scenario → 修正が新しい構造問題を生んでいないか確認
補足: 検査軸の拡張方法
新しい検査軸を追加する場合:
- 「この問題は決定的にlintできるか？」を先に判断する
- YES →
src/lint/lint.mbt にルールを追加する（harness-engineering スキル参照）
- NO → このスキルに検査軸を追加する
- 追加後、既存の全章に適用して問題がないか確認する
