Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
runtime_root_policy: host-skill-path を適用する。CLAUDE_PLUGIN_ROOT をplugin rootとして使用する。SKILL.md のabsolute pathから、plugin manifestを持つ祖先を上方探索して論理 PLUGIN_ROOT を解決する。cwd からplugin rootを推測せず、literal placeholderをshellへ渡さない。各shell invocation内で解決済みabsolute pathを PLUGIN_ROOT に設定する。prompts/ 配下はこのowner Skill契約を継承する。intake-final-context.json を Notion へ描画する前後に、info-collector-agent (Notion page_id=35195d6503b781788e31f59b4e05e705) と同等の構造粒度・再現性が保たれているかを機械検証する fidelity ガード。Notion API を叩かず、references/canonical-page-snapshot.json との JSON 構造比較のみで公開前 (pre-publish) / 公開後 (post-publish 差分) の双方を判定する。
intake-final-context.json + references/canonical-page-snapshot.json (派生元として references/section_canonical_map.json を参照)output/<hint>/fidelity-report.json … sections[].present/granularity_score/missing_slots/excess_slots と overall_score, verdict ∈ {pass, warn, fail}output/<hint>/fidelity-report.md (R3 delta-report, 人間可読)verdict=pass のときのみ呼び出し元 (render_notion_page.py) が公開を許可する。fail は exit 2、warn は exit 1、pass は exit 0。fail でも JSON/MD は必ず書き出す (fail-fast ≠ silent-fail)。run-skill-intake に、スキーマ存在検査は intake.schema.json に、Notion API 経由公開は run-notion-intake-publish / render_notion_page.py に委譲する。required_fields / char_bounds / viz_slots は aggregator 配下を一次正本とし、本スキルは 派生スナップショット (references/canonical-page-snapshot.json) を保持する (DRY)。手で snapshot を書かない。verdict=fail で exit 2、呼び出し元は即停止すること。scripts/*.py (Python 3, jsonschema/jinja2 許容) で決定論実行。references/ に分割し、when_to_read で誘導 (Progressive Disclosure)。references/granularity-rubric.md、verdict 閾値 (pass≥0.85 / warn≥0.70 / fail<0.70) は references/fidelity-check-rules.md。mandatory=false は missing でも減点しない (warn 列にのみ記録)。intake-final-context.json が canonical-page-snapshot.json と同等粒度を保ち、output/<hint>/fidelity-report.json (verdict ∈ {pass, warn, fail}, overall_score, section 別 missing/excess) と fidelity-report.md (delta-report) が生成され、公開直前 (pre-publish) フックおよび公開後 (post-publish) 差分検証で verdict=pass のみ呼び出し元へ通過させた状態になっている。
Notion 公開パイプラインは API 経由で行われるため、intake-final-context.json と canonical ページの section 粒度がずれると、後段の人間レビューで「再現性が無い」「情報が欠落した」と判明し戻り工数が発生する。Notion API 認証を伴わずに JSON 構造比較のみで決定論的に判定することで、公開前のフェイルファスト停止と、公開後の差分検知 (canonical 更新時の追従漏れ検出) を低コストで両立させる。固定手順では canonical 更新タイミング・char_bounds の計測対象差異・viz_slots の mandatory 区分など実行時文脈で揺れるため、未達観点を都度埋める。
section_canonical_map.json (v2 以降) が変更された場合、scripts/extract-canonical-snapshot.py を再走させ references/canonical-page-snapshot.json が最新派生に更新されている (手書き禁止)scripts/validate-notion-fidelity.py <intake-final-context.json> が exit 0/1/2 のいずれかで完了し、output/<hint>/fidelity-report.json が生成されている (fail でも JSON/MD 出力必須)fidelity-report.json が sections[].present / granularity_score / missing_slots / excess_slots と overall_score, verdict を保持し、schemas/output.schema.json 準拠であるscripts/validate-notion-fidelity.py 内 section_text_length() で計測した本文相当文字数を使用 (json.dumps 長ではない)mandatory=true のみで減点判定、mandatory=false 欠落は warn 列に記録のみreferences/fidelity-check-rules.md の閾値 (pass≥0.85 / warn≥0.70 / fail<0.70) と一致し、pass のみ呼び出し元 (render_notion_page.py) が公開許可verdict=fail で exit 2、warn で exit 1、pass で exit 0 が返り、fail/warn でも fidelity-report.md (R3 delta-report) が人間可読で書き出されているscripts/extract-granularity-score.py で overall_score (0-100) を取得し CI メトリクスに記録 (optional だが canonical 更新追従漏れ検知の根拠となる)prompts/R1.md / R2.md / R3.md) と整合した出力になっているreferences/fidelity-check-rules.md と references/granularity-rubric.md の評価観点に従い、未達観点をゲートとみなして都度埋める。本スキル固有の差分:
granularity_score を算出し、overall_score 未達なら不足 section の R3 delta-report を根拠に context.json 側を埋めて再走する。verdict=fail (exit 2) で呼び出し元を即停止。warn (exit 1) は呼び出し元判断に委ねるが、fidelity-report.md の改善示唆を必ず提示する。section_canonical_map.json が更新されたら必ず extract-canonical-snapshot.py を再走 (template-change audit-trigger)。snapshot 手書き禁止。run-notion-intake-publish 側に委譲。# canonical snapshot 再生成 (template-change trigger 時のみ)
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/skills/assign-notion-fidelity-evaluator/scripts/extract-canonical-snapshot.py \
--source plugins/skill-intake/references/section_canonical_map.json \
--out plugins/skill-intake/skills/assign-notion-fidelity-evaluator/references/canonical-page-snapshot.json
# fidelity check (公開直前フック)
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/skills/assign-notion-fidelity-evaluator/scripts/validate-notion-fidelity.py <intake-final-context.json>
# exit 0 = pass / 1 = warn / 2 = fail
# 粒度スコア単体取得 (CI メトリクス用)
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/skills/assign-notion-fidelity-evaluator/scripts/extract-granularity-score.py <intake-final-context.json>
section_canonical_map.json (v2) が変わったら本スキルの extract-canonical-snapshot.py を再走させる。手で snapshot を書かない。scripts/validate-notion-fidelity.py 内の section_text_length() を使用)。mandatory=false は missing でも減点しない (warn 列にのみ記録)。run-notion-intake-publish 側へ。本スキルは構造比較のみ。intake.schema.json に委譲。本スキルは粒度差分のみ。| 用途 | パス | when_to_read |
|---|---|---|
| 責務別 prompt (R1: canonical-snapshot-extraction) | prompts/R1.md | aggregator の section_canonical_map.json から派生スナップショットを生成する手順を確認するとき |
| 責務別 prompt (R2: fidelity-check) | prompts/R2.md | context と canonical の section 粒度比較・verdict 判定ロジックを確認するとき |
| 責務別 prompt (R3: delta-report) | prompts/R3.md | missing/excess/granularity_warnings を Markdown と exit code に変換するとき |
| 正本構造マップ | references/canonical-page-snapshot.json | 各 section の required_fields / char_bounds / viz_slots を参照するとき |
| スコア算出ルール | references/granularity-rubric.md | 0-100 score の重み付け (char_bounds 30% / required 40% / viz 30%) を確認するとき |
| verdict 閾値 | references/fidelity-check-rules.md | pass/warn/fail の境界とエスカレーション規約を確認するとき |
| 量産規約 | references/abstraction-contract.md | canonical_page_id / canonical_snapshot_path / fidelity_threshold_pass / fidelity_threshold_warn 等のテンプレ変数を差し替えるとき |
| Progressive Disclosure 地図 | references/resource-map.yaml | references 全体の読み順を確認するとき |
| 機械可読フロー定義 | workflow-manifest.json | Step/Gate/Phase の entryHook/exitHook/dependsOn を確認するとき |
| 出力スキーマ | schemas/output.schema.json | fidelity-report.json の必須キーを確認するとき |
run-skill-intake — canonical SoT (references/section_canonical_map.json) の所有者run-notion-intake-publish — 本スキルを公開直前フックとして呼ぶ sibling (API 経由公開を担当)まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
36章 PKG-002〜008 / PKG-014 sub-check を実行したいとき、plugin package の静的検査結果を findings JSON で得たいときに使う。