アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
assign-system-dev-plan-evaluator
exact-13 staging planを独立評価したいとき、4条件とdigestに束縛したplan-findings.jsonを生成したいときに使う。
インストール方法を見る含まれるファイル(4)
- SKILL.md3.2 KB
- prompts/R4-evaluate.md14.7 KB
- references/evaluation-rubric.md4.0 KB
- workflow-manifest.json1.5 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Independent system plan evaluation
Runtime root contract
runtime_root_policy: host-skill-pathを適用する。- Claude Codeでは
CLAUDE_PLUGIN_ROOTをplugin rootとして使用する。 - Codexではホストが提示したこの
SKILL.mdのabsolute pathから、plugin manifestを持つ祖先を上方探索して論理PLUGIN_ROOTを解決する。 cwdからplugin rootを推測せず、literal placeholderをshellへ渡さない。各shell invocation内で解決済みabsolute pathをPLUGIN_ROOTに設定する。prompts/配下はこのowner Skill契約を継承する。
- C09 repo context を解決し、staging が caller repository 内であることを確認する。
system-dev-plan-evaluatorを fork context で起動する。生成時の推論・期待 verdict は渡さない。python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-system-plan.py" --repo-root <root> --staging <relative>の stdout/exit code を機械根拠として渡す。- C1 矛盾なし / C2 漏れなし / C3 整合性あり / C4 依存関係整合をそれぞれ PASS|FAIL で評価する。C14
system-build-handoff.jsonの source exact-set、manifest digest包含、promotion/registration receipt owner 境界も必須根拠に含める。 evaluated_digestに validator のvalidated_digestをそのまま固定し、evaluator.context=forkのplan-findings.jsonを staging 外の repo-local state へ出力する。- 1条件でも FAIL、validator 非0、digest 不在、high finding があれば総合 verdict を FAIL にする。対象成果物は修正しない。
1回の evaluator 起動は read-only の1評価で終える。修正後の package を再評価する外側の goal-seek は component-inventory.json の goal_seek.max_loops=5 に従い、5周で未達なら自動継続せず findings と staging path を返す。
出力 schema は ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/schemas/plan-findings.schema.json、評価対象契約は ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/references/feature-execution-package-contract.md を正本とする。これらは plugin の道具・契約であり、評価対象と出力状態は caller repository 内に限定する。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。