アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
assign-plugin-package-evaluator
36章 PKG-002〜008 / PKG-014 sub-check を実行したいとき、plugin package の静的検査結果を findings JSON で得たいときに使う。
インストール方法を見る含まれるファイル(6)
- SKILL.md8.4 KB
- prompts/R1-run-pkg-check.md8.9 KB
- references/evaluator-contract.md2.2 KB
- schemas/findings.schema.json3.1 KB
- scripts/render-pkg-findings.py1.6 KB
- scripts/validate-plugin-package.py30.9 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
assign-plugin-package-evaluator
Purpose & Output Contract
36章 Plugin Package Harness Contract の PKG-002〜008 / PKG-014 sub-check を実装する worker skill。run-plugin-package-check(B)から呼ばれ、plugins/<plugin>/ を入力に findings JSON を返す。PKG-001(公式 CLI ラッパー)/ PKG-009(外部参照)/ PKG-010〜013 / PKG-015 は B が直接実装し、本 skill は静的に検証可能な 8 件に責務を絞る。
入力:
target_plugin: "harness-creator" # 必須。plugins/<name>/ の name
pkg_ids: ["PKG-002", "PKG-003", "PKG-004", "PKG-005", "PKG-006", "PKG-007", "PKG-008", "PKG-014"]
options:
fail_fast: false # true なら最初の FAIL で停止
output_path: "eval-log/<plugin>/pkg-<id>/<date>-<run>.json"
render: markdown # 任意。指定時のみ render-pkg-findings.py で markdown サマリも出力
出力: schemas/findings.schema.json 準拠の findings 配列 + verdict サマリ
完了条件: 全 PKG ID で status ∈ {pass, fail, skip, not_applicable} が確定し、eval-log に保存されること
Key Rules
- PKG ID 定義は ref-pkg-contract 経由: 本 skill 内で PKG ID 表を再定義しない(DRY、33章準拠)
- findings の thought_method フィールドは不要: 本 skill は規範的静的検査であり、思考法多視点レビュー(run-elegant-review)とは責務直交
- package_mode による適用判定:
skill-onlyplugin に対しては PKG-003/005/006/007/008/014 をnot_applicableとして返す(PKG-002/004 のみ実行) - fail_fast=false 既定: 全 PKG ID を走らせて findings を網羅収集
- eval-log パスは 27章 §3.1: 本 skill で再定義しない
- schema 違反は exit 2: validator スクリプト自体の入力 schema 違反は P0 として即停止
- context: fork 必須: 親 context の sycophancy 排除(assign-skill-design-evaluator と同じポリシー)
ゴールシーク実行
evaluator は一度の採点で完結する read-only 工程。ループは回さず、採点の網羅性をチェックリストで担保する。正本: ../run-build-skill/references/goal-seek-paradigm.md(§評価系の扱い)。
ゴール (Goal)
指定された全 PKG ID(既定 PKG-002〜008 / PKG-014)を採点し、各 finding にエビデンスと severity を付与、全件の status ∈ {pass, fail, skip, not_applicable} が確定して schemas/findings.schema.json 準拠の findings JSON + verdict サマリが eval-log に返された状態になっている。
目的・背景 (Why)
契約適合(PKG check)の中核 8 件を静的検査する worker。採点漏れがあると親 orchestrator の verdict が偽陽性 PASS になるため、規範採点や思考法レビューと直交した「全 rubric 項目の網羅採点」が要る。context: fork で親 context の sycophancy を排除する。
完了チェックリスト (Checklist)
- 入力
pkg_idsの全項目を採点した(未採点 ID が 0 件) -
package_mode=skill-onlyの場合 PKG-003/005/006/007/008/014 をnot_applicable判定にした - 各 finding に
locationとevidence(観測根拠)とseverityが付与されている - 全 PKG ID で
statusが確定し、verdict カウント(total/pass/fail/skip/not_applicable)が算出済み - 出力が
schemas/findings.schema.jsonに準拠する(schema 違反は exit 2) -
exit_code != 0でも findings JSON は stdout へ必ず出力した
採点フロー
Step N: の固定連番は使わない。チェックリストの未充足項目に応じ、scripts/validate-plugin-package.py --check pkg-<id> --plugin <name> を必要な PKG ID 分だけ実行し findings を集約、最後に verdict を算出して schema 検証で締める。
PKG-002〜008 / PKG-014 sub-check 詳細
| PKG ID | 検査関数 | fail 条件例 |
|---|---|---|
| PKG-002 | validate_plugin_json_frontmatter + validate_package_contract | 公式 plugin.json の name/version/description、または references/package-contract.json の package_mode/entry_points のいずれか欠落 |
| PKG-003 | validate_namespace_conflict | 同一 marketplace 内で skill/agent/hook/permission 名が重複 |
| PKG-004 | validate_skill_frontmatter | 03章必須キー欠落、responsibility_refs/schema_refs/manifest 不在 |
| PKG-005 | validate_agent_definition | agents/*.md の name と subagent_refs 不一致 |
| PKG-006 | validate_hook_registration | hook ファイル未登録、または登録だけあって実ファイル不在 |
| PKG-007 | validate_script_present_executable | 参照 script が存在しない、shebang 欠落、+x ビットなし |
| PKG-008 | validate_settings_fragment | 34a 章 INV-1〜12 違反、Layer3 衝突 |
| PKG-014 | validate_runtime_contract | kind / combinator 宣言と goal-seek / feedback runtime 設定・本文配線が不一致 |
各検査は scripts/validate-plugin-package.py --check pkg-<id> --plugin <name> 単独実行可能。B からは sub-process でまとめて呼ばれる。
findings 出力フォーマット
{
"run_id": "pkg-validate-harness-creator-20260523-001",
"target_plugin": "harness-creator",
"package_mode": "bundle",
"pkg_checks": {
"PKG-002": {
"status": "pass",
"findings": [],
"last_run_at": "2026-05-23T12:00:00Z"
},
"PKG-006": {
"status": "fail",
"findings": [
{
"id": "F-PKG006-001",
"pkg_id": "PKG-006",
"severity": "P0",
"location": "plugins/harness-creator/hooks/pre-commit.sh",
"evidence": "hook ファイル実体は存在するが settings 断片の hooks 配列に未登録",
"suggested_fix": "plugins/harness-creator/settings/hooks.json の hooks 配列に追加"
}
],
"last_run_at": "2026-05-23T12:00:01Z"
}
},
"verdict": {
"total": 8,
"pass": 7,
"fail": 1,
"skip": 0,
"not_applicable": 0
}
}
Gotchas
scripts/validate-plugin-completeness.pyとの関係: 既存スクリプトは plugin 完全性の総合検査。本 skill のvalidate-plugin-package.pyは PKG ID 別 sub-command で findings 形式を返す点が異なる。既存をラップせず別実装にする(責務分離)- PKG-001/009 は本 skill 対象外: B 側で直接実装。本 skill に投げられたら
unsupported_pkg_idエラーを返す - PKG-010〜013 / PKG-015 は対象外: smoke/permission/rubric 検査は別 skill(B が直接 or 専用 assign)
skill-onlyplugin への PKG-003 適用は禁止: 名前空間検査は bundle のみ。skill-only に投げられたらnot_applicableを返すexit_code != 0でも findings は必ず JSON 出力: stderr に進捗ログ、stdout に findings JSON 厳守
Additional Resources
scripts/validate-plugin-package.py— PKG-002〜008 / PKG-014 sub-command 実装scripts/render-pkg-findings.py— findings JSON → 人間可読 markdown レポートschemas/findings.schema.json— findings JSON 出力 schemaprompts/R1-run-pkg-check.md— R1 単発検査時の応答テンプレref-pkg-contract— PKG ID 表・package-contract schema の正本参照- 設計書: 36章(正本)、34a §4(PKG-003 共有名前空間)、03章(PKG-004 frontmatter 必須キー)
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。