アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
assign-prompt-design-evaluator
生成済みプロンプトを C1-C4 と 4 パスで評価したいとき、context:fork で独立評価結果 findings.json を取得したいときに使う。
含まれるファイル(5)
- SKILL.md6.6 KB
- prompts/R1-evaluate.md5.7 KB
- references/c1-c4-criteria.md4.0 KB
- references/prompt-rubric.json4.8 KB
- references/resource-map.yaml1.3 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
assign-prompt-design-evaluator
生成プロンプトを C1-C4 + 4 パス で評価し
findings.jsonを返す independent evaluator。context:forkで起動して Sycophancy を防ぐ。
Purpose & Output Contract
入力: prompt_path (評価対象 .md/.yaml) / brief (eval-log/prompt-brief.json) / output (省略時 eval-log/docs/<NN>-<timestamp>.json)
出力: eval-log/docs/<NN>-<timestamp>.json (../run-prompt-create/schemas/findings.schema.json 準拠)
完了条件: C1-C4 verdict 全付与 + findings[] に高/中/低の severity 配列。
C1-C4 評価軸
| Gate | 観点 | 合格条件 |
|---|---|---|
| C1 | Layer 整合 | L1-L7 が seven-layer-format.md と整合、Layer 番号と役割の対応が崩れていない |
| C2 | 依存方向 | L7→L1 の単方向参照のみ。Layer N が Layer N-1 以外を参照していない |
| C3 | 再現性 | reproducible=true。再現性根拠 (output_schema / script_refs / 検証可能な完了チェックリスト) が揃い、5.2 ゴール定義が成果状態で固定手順列挙を含まない (l5-contract v2.0.0) |
| C4 | Self-Evaluation 充足 | L5.3 完了チェックリスト (停止条件) が非空で、全項目が第三者に YES/NO 判定可能 (数量レンジは l5-contract v2.0.0 で廃止) |
4 パスレビュー (Pass 0-4)
../run-prompt-creator-7layer/references/quality-criteria.md §7 由来:
- Pass 0 動的評価基準生成:
evaluation_prioritiesから重み付けし以下 Pass を調整 - Pass 1 網羅性: 必須フィールド漏れがないか
- Pass 2 整合性: Layer 間/メタ/responsibility_id が矛盾しないか
- Pass 3 深度: 意味的に十分か (抽象的な空文句に終わっていないか)
- Pass 4 実用性: そのまま実行/注入できるか (placeholder 残存ゼロ)
Key Rules
- context:fork 必須: 親 context から評価対象の解釈バイアスを引き継がない。
- 客観判定優先: スクリプト検証可能な項目は必ずスクリプトで判定し、LLM は意味判定のみ。
- findings 必出: severity ∈ {high, medium, low, info}、bucket は C1-C4 か rubric id (PR-001 等)。
- suggested_fix 明示: high/medium には修正方針を 1-2 文で明記。
- 空 findings 禁止: PASS でも info severity で「確認した観点」を 1 件以上残す。
- mass_production_risk: 同型 prompt 量産でリスクが高い設計欠陥は high を付ける。
ゴール駆動評価 (固定手順なし)
正本責務は
prompts/R1-evaluate.mdLayer 5 (l5-contract v2.0.0)。単発評価 (read-only、runtime loop なし。goal-seek-paradigm 適用マトリクス:assign-*はループ非対象) で、検査の実施内容と順序は下記局面カタログから都度導出する。
ゴール: C1-C4 verdict + 4 パス結果が findings.schema.json 準拠 JSON として保存され、呼出元が global_thresholds で auto-approve 可否を機械判定できる状態。
完了条件 (停止条件の正本 = prompts/R1-evaluate.md 5.3): verdicts 全付与 / scripted checks の実行証跡 / findings 非空 (PASS 時も info) / high・medium への suggested_fix / schema 検証通過 / 評価対象への書換 0 件。
局面カタログ (順序は都度判断):
- 客観検証 (script):
verify-completeness.py --input ${PROMPT_PATH}/validate-prompt.py --input ${PROMPT_PATH} --phase promptを実行し exit code を証跡化。 - C1-C4 機械評価:
references/prompt-rubric.jsonの scripted checks (regex_match / regex_absent) を prompt_path の Layer 構造と突合。 - 意味判定 (LLM): non-scripted checks と Pass 0-4 (
references/c1-c4-criteria.md/ quality-criteria.md §7 準拠) を評価し findings に集約。 - findings 出力:
schemas/findings.schema.json準拠で Write。verdicts に C1-C4 PASS/FAIL/N/A、findings に severity-bucket-observations。
Gotchas
- C1 と C2 を混同しない (Layer 整合 vs 依存方向)。
- Pass 3 深度判定は「具体例があるか」「checklist が客観条件か」が基準。
- evaluation_priorities が空なら Pass 0 で標準重み (1.0) を全 Pass に付与。
- high severity が 1 件でもあれば全体は FAIL。
Additional Resources
references/prompt-rubric.json— C1-C4 機械判定ルールreferences/c1-c4-criteria.md— 人間向け詳細基準../run-prompt-create/schemas/findings.schema.json— 出力スキーマ- caller:
run-prompt-create(Step 3b)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。