메뉴
シナリオの「魅力」と「読者体験」を検証するセルフレビュースキル。 lintが捕捉する構造的問題（会話比率、ナレーション連続等）の上位レイヤーとして、 「読者が自然に読めるか」「引き込まれるか」「疑問を持たないか」を検査する。 「レビューして」「セルフレビュー」「品質チェック」「読者視点で確認して」 「唐突感がないか見て」「魅力的か確認して」といった依頼で発動。 シナリオ執筆後のセルフレビューフェーズで必ず使うこと。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
キャラクターが読者に愛されるかどうかを検証するスキル。 「このキャラ好きになれない」「なんか不快」「魅力が見えない」「読者が離れそう」 という問題を事前に防ぐ。シナリオ執筆・レビュー時に適用すること。 「キャラの魅力を上げて」「好感度が足りない」「読者がつくか不安」 「キャラが不快」「もっと愛されるキャラにして」で発動。 scenario-writingスキルと併用する。会話の内容がスキル、構造がハーネス。
ADVゲーム「月灯り」のシナリオテキストを執筆・改善するためのスキル。 自然な会話、環境描写、感情表現、ペーシングに関する包括的なガイドライン。 「シナリオを書いて」「テキストを改善して」「会話を自然にして」「シーンを追加して」 「ストーリーを書いて」「台詞を直して」「場面を膨らませて」といった依頼で発動。 唐突さを排除し、読者が行間を読める余白のあるテキストを目指す。
ハーネスエンジニアリングの原則に基づき、エージェントのミスを構造的に防止するスキル。 「同じミスを二度としない」ためのフィードバックループを回す。 ミスを発見した時、リンタールール追加、知識タイムライン更新、hookの改善など 決定的な検証レイヤーを強化する作業で使う。 「ハーネスを改善して」「リンタールールを追加して」「知識タイムラインを更新して」 「hookを追加して」「検証を自動化して」「同じミスが起きないようにして」で発動。 シナリオの整合性問題を修正した後にも自動的に適用すること。
シナリオの論理的整合性・因果関係・物理的矛盾を防ぐためのスキル。 「なぜこの人は今ここにいる？」「なぜこの行動をとった？」「前の場面と矛盾していないか？」 といった違和感を事前に潰す。シナリオ執筆・修正時に必ず適用すること。 scenario-writing（テキスト表現）、narrative-design（構造設計）の下位で機能する 「物理法則レイヤー」のスキル。
物語の前提・キャラクター導入・関係性構築を体系的に設計するスキル。 「設定が不自然」「キャラの登場が唐突」「関係性が浅い」「もっと読みたくならない」 「キャラに深みがない」「前提に違和感がある」「動機が弱い」といった問題に対処する。 シナリオの構造設計、キャラクター設計、プロット設計の段階で使うこと。 scenario-writing スキル（テキスト表現レベル）の上位に位置する構造設計スキル。
ソーシャルゲーム・カフェ経営ゲームのシステム設計を改善・拡張するためのスキル。 ゲームメカニクスの追加・変更、バランス調整、新システムの提案時に使う。 「システムを改善して」「深みを出して」「バランスを調整して」「新しい仕組みを追加して」 「エンゲージメントを上げたい」「リテンションを改善したい」といった依頼で発動。 搾取的でなくプレイヤーを尊重する設計哲学に基づく。
| name | scenario-quality-review |
| description | シナリオの「魅力」と「読者体験」を検証するセルフレビュースキル。 lintが捕捉する構造的問題（会話比率、ナレーション連続等）の上位レイヤーとして、 「読者が自然に読めるか」「引き込まれるか」「疑問を持たないか」を検査する。 「レビューして」「セルフレビュー」「品質チェック」「読者視点で確認して」 「唐突感がないか見て」「魅力的か確認して」といった依頼で発動。 シナリオ執筆後のセルフレビューフェーズで必ず使うこと。 |
lintは「壊れていないか」を検査する。このスキルは「魅力的か」を検査する。 両方通って初めて、シナリオは出荷可能になる。
レビュー対象の章を読む前に、以下を準備する:
npm run lint:scenario で構造的問題を先に潰す）以下の7軸それぞれについて、問題箇所を具体的な行番号とともに報告する。
読者が「え？」と思った瞬間、物語への没入が切れる。
OK: 読者が立ち止まらずに読み進められる
WARN: 一瞬「ん？」となるが、前後の文脈で補完できる
NG: 読者が戻って読み直す必要がある、または理解できない
読者が「なんで？」と思って答えが見つからない箇所は、没入の穴になる。
[疑問] L{行番号}: {読者が持つであろう疑問}
→ 原因: {なぜこの疑問が生じるか}
→ 対策: {どう修正すれば疑問が解消されるか}
「初めて〜した」は強い表現。前のシーンで同等の出来事があると即座に矛盾する。
| 表現 | よくある矛盾 | 修正例 |
|---|---|---|
| 「初めて声を聞いた」 | 前シーンで同じキャラが話している | 「初めて、近くで声を聞いた」 |
| 「初めて目が合った」 | 前シーンで視線が交差している | 「初めて、ちゃんと目が合った」 |
| 「初めて名前を知った」 | 前シーンで名前が出ている | 削除するか、別の表現に |
「ページがめくれなかった」のような反復演出は、オリジナルが先にないと機能しない。
OK: オリジナルが1-3章前にあり、印象的な場面で使われている
WARN: オリジナルが5章以上前。読者が覚えているか不安
NG: オリジナルが存在しない、または同じ章内で反復（近すぎて演出効果なし）
character-appeal スキルの簡易版。この章でキャラが「愛される」方向に動いているか。
| 指標 | 定義 | チェック方法 |
|---|---|---|
| 共感性 | 読者が「分かる」と思える言動があるか | モノローグが「俺もそう思う」と思えるか |
| 意外性 | 「この人こういう面もあるんだ」がこの章にあるか | キャラの新しい一面が1つ以上あるか |
| 一貫性 | 前章までの言動と矛盾しない範囲の変化か | characters.mbt の設定と照合 |
読者の「ページをめくる手」が止まらないか。
章全体を5等分し、各区間の「動き」を判定する:
理想: 静→動→動→静→余韻
危険: 静→静→静→動→ぶつ切り（序盤が退屈）
危険: 動→動→動→動→動（休む間がなく疲れる）
ADVの魅力は「書かれていないこと」にある。読者が行間を読める余白があるか。
以下の形式で報告する:
## シナリオ品質レビュー: {章タイトル}
### サマリー
- 総合評価: {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個以上、または構造的な書き直しが必要
レビュー実行前に必ず npm run lint:scenario を実行し、構造的問題を先に解消する。
lint が WARN/ERROR を出している状態でこのレビューを実行しても、
lint で捕捉される問題が結果に混ざってノイズになる。
実行順序:
npm run lint:scenario → 構造的問題を修正npm run lint:scenario → 修正が新しい構造問題を生んでいないか確認新しい検査軸を追加する場合:
src/lint/lint.mbt にルールを追加する（harness-engineering スキル参照）