アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
assign-plugin-plan-evaluator
生成済み plan を4条件と決定論ゲートで評価したいとき、context:fork で独立評価結果 plan-findings.json を取得したいときに使う。
インストール方法を見る含まれるファイル(9)
- SKILL.md9.2 KB
- prompts/R1-evaluate.md14.1 KB
- references/four-condition-criteria.md5.3 KB
- references/plan-rubric.json9.2 KB
- references/resource-map.yaml2.9 KB
- schemas/plan-findings.schema.json4.4 KB
- scripts/evaluate-plan.py15.9 KB
- tests/test_evaluate_plan.py5.5 KB
- tests/test_gate_parity.py15.8 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
assign-plugin-plan-evaluator
生成 plan を 4条件 + 決定論ゲート で評価し
plan-findings.jsonを返す independent evaluator。context:forkで起動して Sycophancy (親への迎合) を防ぐ。生成者 (run-plugin-dev-planの architect) と評価者を分離し、proposer ≠ approver を構造で保証する。
Purpose & Output Contract
入力: plan_dir (評価対象 plan ディレクトリ = index.md + 13 phase files (phase-01-*.md … phase-13-*.md) + component-inventory.json 機械SSOT + handoff-run-plugin-dev-plan.json) / output (省略時 <PLAN_DIR>/plan-findings.json)
出力: <PLAN_DIR>/plan-findings.json (schemas/plan-findings.schema.json 準拠)
完了条件: 4条件 verdict 全付与 + findings[] に severity 配列 + plan-scoped 決定論ゲート (io-contract §11 の plan-scoped 集合) の gate_results。
4条件 評価軸 (R4 の独立 skill 昇格)
| Gate | 観点 | 一次根拠 (決定論ゲート) |
|---|---|---|
| C1 矛盾なし | component_kind / handoff / manifest / harness の契約が衝突しない | 意味判定 (script では捕捉不能、契約間突合) |
| C2 漏れなし | 5 種 component_kind × N 実体 + plugin-level surface を必要性ベースで全確認 (同一 kind 複数実体可・各 component が ≥1 phase の entities_covered に出現)・単一 skill 退化なし | detect-unassigned / check-spec-frontmatter / check-spec-gates / check-surface-inventory / check-requirements-coverage exit0 |
| C3 整合性あり | 用語 / frontmatter / plugin_meta / quality_gates が同一語彙・マトリクス全行被覆 (行数正本=harness-creator-spec-reflection.md) | check-spec-matrix-coverage --self-test / PLAN exit0 |
| C4 依存関係整合 | index が P01..P13 を phase_number 昇順で全列挙・inventory component DAG 非循環・orphan 0 | verify-index-topsort / detect-unassigned / check-build-handoff / check-runtime-portability exit0 |
C1-C4 ラベルの二層性 (語彙 disambiguate): 本 skill の C1-C4 は inner の機械ゲート (plan-scoped 決定論ゲート (io-contract §11 の plan-scoped 集合) による plan の構造検証)。
run-plugin-dev-planが昇格前に通すrun-elegant-reviewの C1-C4 は outer の設計レビュー (30 思考法による elegance lint)。両者は同じ 4 概念 (矛盾なし/漏れなし/整合性あり/依存関係整合) を別 loop-scope・別手法で二段検証する意図的な階層であり、冗長ではない。同一ラベルが指すゲートは文脈で異なる (本 skill=inner / elegant-review=outer)。
Key Rules
- context:fork 必須: 親 (architect/orchestrator) から plan の解釈バイアスを引き継がない。
- 決定論ゲート優先: スクリプト検証可能な項目は必ず exit code で判定し、LLM は契約間の意味判定のみ。
- findings 必出: severity ∈ {high, medium, low, info}、bucket は C1-C4 か rubric id (PLAN-001 等)。
- 単一 skill 退化の検出: sub-agent / slash-command / hook / script component を不要とした根拠が goal-spec constraints または index の受入確認に無ければ C2 を high で FAIL。plugin-level surface の不要理由は
plugin_level_surfaces.<surface>.omitted_reason(正本キー一本) で見る。 - suggested_fix 明示: high/medium には差し戻し方針を 1-2 文で明記し architect (R3) へ返す。
- 空 findings 禁止: PASS でも info severity で「確認した観点」を 1 件以上残す。
- plan を書き換えない: read-only 評価 (Edit を持たない)。Bash は検証スクリプト実行のみ。
- 鮮度台帳と証拠再利用を分離:
scripts/evaluate-plan.pyは plan 配下の安定 artifact (直下 +envelope-draft/**/task-specs/**等の nested) を再帰収集したevaluated_inputs[]を鮮度台帳として emit する。この台帳は semantic 再評価範囲を決めず、verdict 再利用を認可しない。semantic 証拠の再利用はplugins/harness-creator/skills/run-build-skill/references/verification-obligation-protocol.mdの exact obligation fingerprint + current PASS receipt DAG だけを正本とする。
Steps
正本責務は prompts/R1-evaluate.md。要約:
Step 1: 決定論ゲート (script、一次根拠)
EVALUATOR_DIR=plugins/plugin-dev-planner/skills/assign-plugin-plan-evaluator
# 全 plan-scoped 決定論ゲート (G1-G10) を束ねて実行し plan-findings.json を出力
# (個別ゲート一覧の可読正本は run-plugin-dev-plan/references/io-contract.md §11 表)
python3 "$EVALUATOR_DIR/scripts/evaluate-plan.py" --plan-dir "$PLAN_DIR"
Step 2: 4条件機械評価
references/plan-rubric.json を Read し、各 exit code を C1-C4 へ写像する。
Step 3: 意味判定 (LLM、契約間突合のみ)
scripts/evaluate-plan.py は決定論ゲートと plugin-level surface 明示性だけを機械判定する。C1 の契約衝突や単一 skill 退化の意味判定は、本 assign skill の LLM 評価レイヤーで plan-rubric.json の semantic_checks を読んで追加 finding として扱う。
Step 4: findings 出力
schemas/plan-findings.schema.json 準拠で <PLAN_DIR>/plan-findings.json を Write。verdict に 4 条件 PASS/FAIL、gate_results に plan-scoped 決定論ゲート (io-contract §11 の plan-scoped 集合) の exit code。
Gotchas
- C2 と C4 を混同しない (漏れ = surface 網羅性 vs 依存 = top-sort 健全性)。両者とも detect-unassigned が関与するが観点が違う。
- 決定論ゲートが exit0 でも、単一 skill 退化の根拠欠落は LLM 意味判定で C2 FAIL にしうる。
- high severity が 1 件でもあれば全体 FAIL。
- Bash 背景権限で停止する場合は caller (run-plugin-dev-plan の親セッション) が exit code を渡す。
- 本 skill は kind=assign のため feedback_contract.criteria は N/A (評価器自身は評価基準を携帯しない)。
Additional Resources
references/plan-rubric.json— 4条件機械判定ルール (C1-C4 × checks)references/four-condition-criteria.md— 人間向け詳細基準schemas/plan-findings.schema.json— 出力スキーマprompts/R1-evaluate.md— R1 (evaluate) 責務正本- 実行 fork 先 agent:
../../agents/plugin-dev-plan-evaluator.md - caller:
run-plugin-dev-plan(R4 verify-traceability)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。