القائمة
ghost-fable-harnessを別モデル(Sonnet5等)に適用した出力を固定シナリオで生成し、voice_lint+バイナリチェックで採点する評価スキル。「fable-eval実行」「ハーネスの効き目を測って」「sonnetでテスト」と言われたら使う。ハーネスやexamples.mdを改修した後の回帰確認にも使う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
ghost-fable-harnessの対比例バンク(references/examples.md)を実セッションから育てる採集スキル。「この応答よかった/ダメだった、例に追加して」「examples更新」「対比例に採集」と言われた時、またはfable-evalで不合格場面が出た時に使う。
ghost-fable-harness適用時の送信前推敲を明示的な工程として強制するスキル。一稿目を書き、8問診断とvoice_lintで照合し、二稿目を送信する。「推敲して」「polish」「fable品質で出して」と言われた時、およびghost-fable-harness適用セッションで実質的な文章応答(3段落以上、または対話的な返信)を出す前に使う。単発の事実回答・コマンド実行報告には不要。
Claude Fable 5の思考様式・判断基準・対話の温度を別モデル上で再現する行動ハーネス。「fableとして」「fableらしく」「fableモード」「ゴーストハーネス」と言われたら必ず使用。他にも深いユーザー理解、誠実さと温かさの両立、root cause思考、繊細な対話、長い反復作業、モバイルUI/UXなど「良い仕事の仕方」が問われる場面全般で使う。
| name | fable-eval |
| description | ghost-fable-harnessを別モデル(Sonnet5等)に適用した出力を固定シナリオで生成し、voice_lint+バイナリチェックで採点する評価スキル。「fable-eval実行」「ハーネスの効き目を測って」「sonnetでテスト」と言われたら使う。ハーネスやexamples.mdを改修した後の回帰確認にも使う。 |
改善の効き目は測らないと分からない。固定シナリオ14本(scenarios.json)に対してホストモデル+ハーネスの出力を生成し、機械検査(voice_lint)とバイナリチェック採点で「どの場面の・どの項目」が落ちるかを特定する。01〜07が基本場面、08〜10はドリフトが起きやすい種別(感情的対話・哲学的問い・多ターン疲労)、11〜12は技術判断の質(root cause・計測と最小差分)、13はクリエイティブ判断(creative.md)、14は実多ターンでの声の持続(--resumeで実セッションを継ぎ、後半ターンの劣化を測る)——コーディング場面だけで合格しても声は保証されない。逆も同じ。
python .claude/skills/fable-eval/scripts/eval_runner.py --model claude-sonnet-5
claude -p が走る(1本あたり数十秒、全本で数分〜十数分)eval-results/<model>-<timestamp>/ に1シナリオ1ファイルで保存され、voice_lintの結果とチェック項目が併記される--only 01,04。--baseline を付けるとハーネスなしの素の出力も並走生成され <id>-baseline.md に保存される(ハーネスの寄与を差分で見る用)eval-results/<runid>/scores.md に書く。不合格場面は fable-examples スキルの採集素材になるLikertの1〜5点は隣接点の解釈が主観的で中央に退避しやすく、冗長な出力にゲームされやすい。各シナリオの checks に定義されたyes/no項目で採点する。
声と判断は別パスで採点する。 LLM採点者の最大のバイアスは style-over-substance——「fableっぽい文飾」に引かれて判断の質まで高く見積もる(逆も起きる)。対策として:
判定の書式は理由→判定の順(reason-then-verdict)。項目ごとに「出力のどの箇所がどうだから」を先に書き、YES/NOは理由の後に付ける。判定に迷う項目は、見つけた所見を全部列挙してから判定する——Sonnet系の採点者は「重要なものだけ報告」と指示すると見つけた違反を黙って捨てるので、列挙が先、フィルタは後。
合格線: シナリオ合格 = NG項目ゼロ。NG1つは条件付き(リフレクト対象)、NG2つ以上は不合格。 集計は「voice通過率」「judgment通過率」を別々に出す(全シナリオのチェック項目通過数/総数)。
甘いジャッジの上で最適化しても無意味(過受容ジャッジはTPR>96%/TNR<25%になり得る——合格率で見ると優秀に見えるのが罠)。手順:
eval-results/<runid>/author-labels.md)eval-results/calibration.md に記録するスコアは症状であって診断ではない。不合格シナリオごとに:
--only <id> で再実行するHoldout(過適合の防波堤): 03・09・12はholdoutとして凍結——リフレクトのパッチ判断の根拠に使わない(診断・パッチ設計時にこの3本の出力を見ない)。ハーネス改修が一巡した後の回帰確認でだけ採点する。holdoutだけ通過率が下がっていたら、残り11本に過適合している。
--baseline の素出力との比較は「ハーネスが何を直し、何を壊していないか」の確認用。ベースラインに勝っていない項目があれば、その規則は害になっている疑い--model を変えて同時刻に回す