アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-system-spec-elicit
システム仕様のヒアリングを開始するとき、システム構築の要件をカテゴリ×プラットフォームの収集マトリクスで往復ヒアリングして spec-state.json に確定させたいときに使う。
インストール方法を見る含まれるファイル(19)
- SKILL.md22.7 KB
- fixtures/expected-final-spec-state.json12.2 KB
- fixtures/expected-resume-spec-state.json8.9 KB
- fixtures/hearing-turns.json9.0 KB
- prompts/R0-foundation.md10.4 KB
- prompts/R1-init.md4.9 KB
- prompts/R2-interview.md10.2 KB
- prompts/R3-reask.md6.3 KB
- prompts/R4-reopen.md7.7 KB
- prompts/R5-decision-guide.md11.3 KB
- prompts/R6-audit-hearing.md12.9 KB
- prompts/R7-audit-matrix.md18.3 KB
- references/elicit-question-bank.md5.4 KB
- references/neutral-question-criteria.md7.2 KB
- references/required-info-catalog.json9.7 KB
- references/resource-map.yaml2.2 KB
- references/spec-state-contract.md31.2 KB
- scripts/apply-spec-transition.py83.5 KB
- tests/test_spec_transition.py41.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Pre-choice usable artifact execution
Purpose & Output Contractの最小の実成果物をmain contextで作成する。effect別のparse/open・secret・irreversible・corrupt guardだけを実行し、現物path・digest・開き方を提示してからaccept-as-is/light/standard/detailedを記録する。accept-as-isはその場でhandoff完了とし、後続sectionを実行しない。
Post-choice selected improvement execution
以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。
run-system-spec-elicit
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契約を継承する。
システム構築の仕様を、まず 上位概念 (本質的目的/背景/ゴール/目標/成功基準/具体的やりたいこと U1-U9) を深掘りヒアリングで確定し (R0-foundation)、その上で カテゴリ×canonical platform id の収集マトリクスを往復ヒアリングで終端化する L1 skill。ユーザーが決めきれない項目は R5 が最新公式根拠付き2〜3案(無料/低コスト案を含む)を目的適合で比較し、AI推奨・理由・注意点を示してユーザー確認へ導く。foundation / decisions / matrix の書込は本 skill 所有の単一 transition writerのみ。
上位概念 anchor (要件 C9・spec drift 防止)
上位概念がブレると、仕様が整ってもブレる。技術マトリクス (下位概念) の手前で上位概念 (U1-U9) を最初にしっかり抽出して
requirements_foundationに固定し、各技術決定 (確定セル) をserves_goalsでそこへトレース (anchor) する。どのゴールにも資さない収集は drift として検出する。
- bootstrap サブコマンドが空のstate envelope (
$CLAUDE_PROJECT_DIR/system-spec/spec-state.json) を作り、R0-foundation がset-foundationop でrequirements_foundation(U1-U9) を確定してから R1-init (initサブコマンド) がtaxonomyをpopulateする。R1は既存foundation/decisionsを保持し、上位概念が曖昧なまま技術ヒアリングへ進まない。 - 各
確定セルにserves_goals: [<goal_id>, ...]を付与 (confirm 同時付与 orset-servesop) し、どの上位概念に資するかを明示する。 - C03 (
run-system-spec-compile) はrequirements_foundationをsystem-spec/00-requirements-definition.md(要件定義書=憲法) として先頭章に生成し、各技術章 frontmatter にserves_goalsを持たせて全章を貫通させる。 - 検証:
python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-coverage-matrix.py" --require-foundationが U1-U9 (U1/U2/U3 は値必須、他は値または理由付きの明示 N/A)・decisions 契約・各確定セルの serves_goals トレース・drift 候補を機械検証する (opt-in)。
Purpose & Output Contract
入力: ヒアリング応答 (対話) / 既存 spec-state.json (resume 時) / C04 taxonomy。
出力: spec-state.json (references/spec-state-contract.md の形状。plugin 共有データ契約。上位概念 requirements_foundation を含む)。
完了条件: requirements_foundation が確定 (U1-U9 が値または明示 N/A+理由・ただし U1/U2/U3 は値必須で N/A 不可・U1-U9 要約のユーザー承認 approval_ref 付き・confirmed: true) し、全セルが 確定(qa_ref 付き) か 対象外(reason か approval_ref 付き) で、未収集0。validate-coverage-matrix.py --require-complete --require-basis --require-foundation が exit0 (--require-basis は確定セルごとに、根拠 qa_ref と qa_refs のうち少なくとも 1 件が basis を宣言していることを課す。宣言された basis がすべて推定 agent-inference のセルは、このフラグが無くても違反になる)。加えて python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-knowledge-graph.py" --profile required-info --input "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/run-system-spec-elicit/references/required-info-catalog.json" --state "$CLAUDE_PROJECT_DIR/system-spec/spec-state.json" の coverage_certificate.ungrounded_blocking_items が空 (missing_effect=block の必須情報が全て確定に接地) である。
- platforms (6):
web/mobile/tablet/desktop-windows/desktop-linux/desktop-macos。 - cell states (3値, loop 中):
未収集/対象外/確定。最終時は未収集を0にする。 - category_aggregate (4値): 真理値表から導出 (直接指定しない)。全セル未収集=未着手 / 未収集混在=収集中 / 全セル対象外=対象外 / それ以外で未収集0=確定。
- カテゴリ初期集合の正本: C04
plugins/system-spec-harness/skills/ref-system-design-knowledge/references/system-category-taxonomy.jsonを Read して得る (prompt へ直書き禁止)。
単一 transition writer 防御 (SSOT)
spec-state.json への状態書込は scripts/apply-spec-transition.py の一経路のみ。本 writer は以下を機械的に強制する:
- 確定巻き戻しの拒否:
確定セルをconfirm/excludeで直接変更しようとするとTransitionErrorで拒否する。Bash や別 script から CLI を叩いても同じく拒否される (single-writer 防御)。 - R4-reopen 経由のみ確定変更:
確定セルの状態を動かせるのはaction=reopen(要 reason) だけ。reopen は当該セルを未収集へ戻しreopen_logに根拠を残す。その後confirm/excludeで再遷移できる。 - 確定/対象外の付帯必須:
confirmはqa_ref(qa_log entry 参照) 必須、excludeはreasonかapproval_ref(approval_log 参照) 必須。 - 集約は導出のみ:
category_aggregateは真理値表から再計算する。手書き代入を認めない。 - 根拠参照と置き換えの整合:
add-qa-refは確定セルにだけ追記でき、qa_logに実在する id だけを受ける。supersede-qaは旧 entry への write-once の追記で、旧 entry が確定セルの主たる接地根拠 (qa_ref) の間は拒否する。置き換え済みの entry をqa_refにしたconfirmも拒否する。
本文・prompt・CLI いずれの経路でも、マトリクスの状態遷移は上記 writer を経由すること。直接 JSON 編集で
確定→未収集を書くのは契約違反。
責務 (prompts/)
| id | prompt | 責務 |
|---|---|---|
| R0-foundation | prompts/R0-foundation.md | マトリクス収集の手前で上位概念 (U1-U9) を深掘りヒアリング (5 Whys で U1・JTBD で U6) し set-foundation で requirements_foundation を確定。未確定は再質問し放置しない。 |
| R1-init | prompts/R1-init.md | C04 taxonomy を Read し、カテゴリ×6必須platform の全存在(対象外は理由付き)を検証して初期化。カテゴリ軸の拡張発見もここ。 |
| R2-interview | prompts/R2-interview.md | 未収集セルを対象に 質問→回答→仕様反映 の往復で各セルを 確定 か 対象外+理由 へ遷移。 |
| R3-reask | prompts/R3-reask.md | 未確定セルを再質問。1 invocation の 5 loop 到達時は未完了状態と next_question を保存し resumable な結果を返す。未収集を完了扱いしない。 |
| R4-reopen | prompts/R4-reopen.md | 確定済みセルを根拠付きで再オープンし追加質問サイクルへ戻す。reopen 非経由の確定直接変更は writer が遮断する。 |
| R5-decision-guide | prompts/R5-decision-guide.md | needs_guidance を最新公式情報とC04 deep knowledgeから2〜3案へ展開し、無料/低コスト案を含めgoal fit/TCO/security/operations/lock-inで比較。AI推奨はrecommended_pending_confirmation、ユーザー選択だけをconfirmedにする。推奨は問に入れず、比較の後の別の段で「参考」として示し、最後に中立な問で選択を求める (N1-N4 と推奨の示し方の正本は references/neutral-question-criteria.md)。加えて python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-knowledge-graph.py" --profile required-info --input "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/run-system-spec-elicit/references/required-info-catalog.json" --state "$CLAUDE_PROJECT_DIR/system-spec/spec-state.json" の coverage_certificate.ungrounded_blocking_items (missing_effect=block の未接地 item) が空になるまで当該 domain の確定セルの confirmed を禁じる収集ゲートを課し、--profile knowledge --order の topo_order (上位概念→下位概念) 順で知識を消費する。 |
ゴールシーク実行
- engine=inline / fork=subagent / max_loops=5 / loop_semantics = per-invocation chunk limit。
- 1 invocation で最大 5 loop (質問→回答→反映) を回す。5 loop 到達で未収集が残れば
hearing_progress.complete=falseとnext_questionを保存し、resumable に返す (--resumeで続行)。 - 未収集0を満たしたときだけ
complete=true・next_question=null。未収集セルを完了扱いしない。 - ループの各周回は「未達 = 未収集セル」を最小化する手順を都度立案→ writer で適用→
validate-coverage-matrix.pyで検証、を繰り返す (固定手順を持たない)。
feedback-contract (with-feedback-contract)
- IN1 (inner / script):
python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-coverage-matrix.py" --matrix spec-state.jsonが exit0 (loop 中の網羅性)。R0-foundation 完了後は--require-foundationを付けてpython3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-coverage-matrix.py" --matrix spec-state.json --require-foundationも exit0 とし、上位概念 U1-U9・decisions 契約・serves_goals トレースを段階的に課す (foundation 未確定の R0 完了前には課さない)。確定セルを作った後は--require-basisも付け、確定セルごとに根拠 (qa_ref/qa_refs) の少なくとも 1 件にbasis宣言を課す。 - OUT1 (outer / test): 最終
spec-state.jsonを--require-complete --require-basis --require-foundationが exit0 で受理し (未収集0・全確定セルのbasis宣言・U1-U9 と serves_goals トレースを最終条件に含める)、下の収集ゲートもungrounded_blocking_itemsが空で通る。受入テスト (tests/) が resume 保存を含めてこの最終状態を再現する。 - 収集ゲート (C16 / IN1 補完):
python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-knowledge-graph.py" --profile required-info --input "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/run-system-spec-elicit/references/required-info-catalog.json" --state "$CLAUDE_PROJECT_DIR/system-spec/spec-state.json"が exit0 かつcoverage_certificate.ungrounded_blocking_itemsが空。missing_effect=blockの必須情報 (product-goal / context-of-use / target-platforms / domain-model / auth-model / security-posture) が確定に接地するまで当該 domain の確定セルのconfirmedを許さない (接地の判定は qa_log entry のrequired_info_itemsと決着済みセル (確定または対象外) のqa_ref/qa_refsを辿って--stateが決定論検査する。除外もまた「収集した結論」であり、たとえば target-platforms は何を外すかという答えそのものが根拠になるため対象外も接地元に数える — 詳細はreferences/spec-state-contract.md)。R2 の各 turn にはbasisとrequired_info_itemsを付けて writer へ渡す (付けない回答はどの item も接地させない)。 - 情報優先度の責務境界 (ui-ux /
information-priorityitem): 本 skill が確定させるのは方針まで — 表現物ごとに何を残し・落とし・加工するか、束の順位とその根拠 (task 頻度 × 失敗コスト) — であり、spec-state.jsonの該当セルへ qa_ref 付きで記録する (missing_effect=degrade。非適用なら理由を記録する)。この方針をinformation-priority-map.jsonとして具体化しvalidate-information-priority.pyで機械検証するのは下流の生成工程の責務であり、要件段階で成果物の生成は求めない。下流の現状は 2 系統に分かれる — map ゲートまで実装済みなのは slide-report-generator の構成設計 (structure-designer/report-structure-designerが構成着手前に exit 0 を要求) のみ。C03 仕様書生成は原理カードの注入までで、../run-system-spec-compile/scripts/compile-spec-doc.pyのcategory_design_refs()が C04resource-map.yamlのread_whenから ui-ux / frontend 章へinformation-design.mdを自動で引く (map ゲートの C03 への組込は follow-up)。原理の正本は C04../ref-system-design-knowledge/references/information-design.md。
使い方 (ゴールへ向けた反復)
spec-state.jsonの正本位置は$CLAUDE_PROJECT_DIR/system-spec/spec-state.json。以下のパス例はこの正本を指す (別ディレクトリに二重生成しない)。
- bootstrap:
python3 "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/run-system-spec-elicit/scripts/apply-spec-transition.py" bootstrap --out $CLAUDE_PROJECT_DIR/system-spec/spec-state.jsonで空foundation/decisions/targets/logsを持つstate envelopeを用意する (initは taxonomy から matrix を初期化する別subコマンドで、envelope 生成はbootstrap)。 - R0-foundation: 技術ヒアリングの手前で上位概念 U1-U9 を深掘りし、U1/U2/U3 は値必須・U4-U9 は値または明示N/A理由で埋め、U1-U9 要約をユーザーへ提示して承認
approval_refを得て確定する。 - R1-init: taxonomy を Readしてmatrixをpopulateする。既存foundation/decisionsを保持する。
- R2/R3/R5: 未収集セルをヒアリングし、不明・未決定ならR5で根拠付き候補と推奨を提示する。問は
references/neutral-question-criteria.mdの N1-N4 に従い、推奨は問と別の段に置く。確定セル/decisionはgoalへトレースし、5 loop超でresume保存。 - R4-reopen: 確定セルの見直しが要るときのみ reopen。
- 検証: 各周回でvalidator、最終で
--require-complete --require-basis --require-foundation。
Gotchas
- カテゴリを prompt へ直書きしない。必ず C04 taxonomy が正本。
確定→未収集の直接書換は禁止 (reopen を使う)。- 5 loop 到達で未収集が残るなら未完了として保存する。未収集を勝手に確定/対象外にしない。
category_aggregateは writer が真理値表から再計算する (手書きしない)。- platform id は canonical 6 種のみ (別名を作らない)。
- 問は
references/neutral-question-criteria.mdの N1-N4 に従う。凍結済みの問に違反が見つかったら、同じ論点を中立に問い直して回答を取り直し、supersede-qaop で旧 entry に置き換えを記録する (本文は書き換えない)。旧 entry が確定セルのqa_refなら、R4-reopen で reopen → 問い直し → 新しい qa で再確定してからsupersede-qaを記録する (旧 entry が主根拠のままだと writer が拒否し、置き換え済みの entry をqa_refにしたconfirmも拒否する)。
Additional Resources
references/spec-state-contract.md— spec-state.json 形状 + 真理値表 + writer 契約の正本。references/elicit-question-bank.md— カテゴリ×platform で確認する論点の一覧 (聞き漏れを確かめるチェックリスト。問の文面の雛形ではない)。references/resource-map.yaml— Progressive Disclosure 索引。references/neutral-question-criteria.md— 中立な問の基準 N1-N4 と推奨の示し方の正本 (問を作る R0/R2/R3/R4/R5 と監査する R6/C06 が共有)。prompts/R6-audit-hearing.md— 往復ヒアリング監査 (C06system-spec-hearing-auditor) の判定観点の正本。C06 が読む監査 SSOT で、本 skill の実行責務ではない。scripts/apply-spec-transition.py— 単一 transition writer (init/apply/chunk/aggregate)。../../scripts/validate-coverage-matrix.py— 網羅性の決定論ゲート (IN1/OUT1)。references/required-info-catalog.json— C16 必須情報カタログ (domain 別 block/degrade/warn item・収集順序 depends_on・coverage certificate の正本)。../../scripts/validate-knowledge-graph.py— 知識グラフ / required-info の決定論ゲート (--profile required-infoが domain 被覆・item 形状・blocking_items を (--state併用で block item の確定接地も)、--profile knowledge --orderが topo_order を検証)。- C04:
../ref-system-design-knowledge/references/system-category-taxonomy.json— カテゴリ初期集合の正本。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。