アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
assign-handout-readability-evaluator
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
インストール方法を見る含まれるファイル(2)
- SKILL.md6.1 KB
- prompts/R1-review-readability.md6.9 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
assign-handout-readability-evaluator
Purpose & Output Contract
資料が初心者に伝わるかは意味の判断であり、決定論ゲートでは測れない。本 skill はその 判断を独立 context の sub-agent handout-readability-reviewer (C06) へ委譲し、返った verdict を呼び出し元 (C01 run-handout-build) へ運ぶ。委譲する理由は品質の上乗せでは なく、生成した本人が自作を採点する構図 (proposer≠approver の崩れ) を構造で塞ぐこと にある。
本 skill は判定基準を持たない。読みやすさの良し悪しを本 skill が判定しないこと、 そして資料を書き換えないことが境界である。修正は C01 の責務。
委譲入力 (本 skill が組み立てて渡すもの)
| キー | 内容 |
|---|---|
html_path | 判定対象の生成 HTML 1 ファイルのパス |
config_path | 出力先へ同梱された正規化済み構成データ JSON のパス |
gate_reports | 決定論ゲート (C16 / C17 / C18 / C22) の json-report のパス一覧と各 exit code |
reader_profile | 構成データの reader / prior_knowledge_level / usage_scene。誰の立場で読むかの指定 |
scope | 任意。読む範囲を絞るときの section id 一覧。省略時は資料全体。指すのは「どこを読むか」だけで、どの軸をどれだけ厳しく見るかは変えない。節をまたぐ軸は C06 が scope に関わらず全体で見る |
gate_reports は本 skill が収集する。verify-handout-language.py は
--json-report つきで実行し、出力されたレポートのパスと exit code をそのまま載せる。
収集はするが中身の合否を本 skill が解釈し直すことはしない。
回収する出力 (C06 の戻り値をそのまま返す)
トップレベルは status / verdict / reviewed_as / findings / strengths /
not_reviewed / blocked_reason。verdict の値域は PASS と FAIL。
findings[] の各要素は severity / axis / location (section_id と逐語引用) /
why_not_understood (根拠) / suggestion (改善案) / machine_gate_overlap。
項目が欠けた戻り値は不完全な verdict として扱う。本 skill が補完も要約もせず、 欠落を欠落のまま呼び出し元へ報告する。
Key Rules
- 決定論ゲート C16 / C17 / C18 / C22 が全て exit0 であることが委譲の前提である。FAIL が
残る状態では意味レビューへ進まない。この状態で起動された場合 C06 は
status=blockedとblocked_reasonを返すので、握りつぶさずそのまま呼び出し元へ差し戻す。 - ゲート結果の集約規則 (未実行を通過と読まないことを含む) の正本は
/handout-verify(C09) の CR-GATE-AGG である。本 skill は集約規則を持たず、C09 の結果を運ぶだけ。 - verdict の決め方 (severity=high の扱いを含む) は handout-readability-reviewer (C06) 側の規則であり、本 skill は再判定しない。回収した verdict を書き換えない。
- 独立 context の価値は「親会話に載っている情報が載っていないこと」で決まる。次のもの は委譲入力に含めず渡さない: 構成データの設計意図や狙いの説明、ヒアリングの生ログ、 参照 HTML の文面、これが何周目の loop かという情報、過去に C06 が出した findings。
- 再レビューの起動と打ち切りは C01 のゴールシークが持つ。本 skill は 1 回の委譲と 1 回の回収で終わる。
Gotchas
- verdict を要約して短くしない。
locationの逐語引用は C01 が修正箇所を特定する唯一の 手掛かりであり、落とすと修正が当て推量になる。 findingsが空でもstrengthsとnot_reviewedは落とさない。次の修正で壊しては ならない箇所と、そもそも読んでいない面が分からなくなる。- レビュアーへ「前回ここを直した」と伝えたくなるが、それが最も独立 context を壊す。 伝えた瞬間、直した箇所だけを見る Goodhart 化が起きる。
Additional Resources
../../agents/handout-readability-reviewer.md— 委譲先 (C06) の判定規範と出力契約prompts/R1-review-readability.md— R1-assign の責務プロンプト (7layer)../../scripts/verify-handout-language.py— 言語と日付の決定論ゲート (C18)ref-handout-design-system— 文章設計の型 (レビューの評価規範の正本)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。
36章 PKG-002〜008 / PKG-014 sub-check を実行したいとき、plugin package の静的検査結果を findings JSON で得たいときに使う。