アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-prompt-elicit
プロンプト要望を対話でヒアリングして prompt-brief.json を生成するとき、target_skill と responsibility_id の確定または skill 非紐付け (standalone) の汎用プロンプト要望を構造化するときに使う。
含まれるファイル(5)
- SKILL.md13.0 KB
- prompts/R1-interview.md5.8 KB
- references/elicit-question-bank.md3.0 KB
- references/resource-map.yaml1.1 KB
- schemas/hearing-result.schema.json3.1 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-prompt-elicit
ユーザー要望から
prompt-brief.jsonを構築するヒアリング skill。prompt-creator-interview-useragent を context:fork で起動する。単独起動と run-prompt-create (Step 1) / run-prompt-creator-7layer (Phase 1) からの委譲呼出の両対応で、ヒアリング経路の正本を本 skill に一本化する。
Purpose & Output Contract
入力: topic (任意) / target_skill (任意。未指定 = standalone モード) / responsibility_id (任意) / batch flag 出力:
eval-log/prompt-brief.json(../run-prompt-create/schemas/prompt-brief.schema.json準拠)eval-log/hearing-result.json(schemas/hearing-result.schema.json準拠、中間生データ。goals / checklist / evaluation_priorities を必須搭載)
完了条件: 下記「完了チェックリスト」全充足 (schema validation PASS + 呼出モード別整合)。
Key Rules
- AskUserQuestion 集約: 質問は 1 セッション 3-5 問 + 評価優先度に絞る (doc/prompt-creator/ 由来の核心原則)。
- 導出確認: AI の推定・解釈は必ずユーザーに透明化して承認を得る。推測を事実として埋めない。
- 質ベース判定: 「この回答で次に何をすべきか迷わないか?」で十分性を判断。数量カウント禁止。
- R-id 1:1 (skill 紐付け時): responsibility_id は target_skill の responsibilities[].id と必ず一致。不在なら open_questions に記録。
- standalone モード (skill 非紐付け): target_skill 未指定の汎用プロンプト要望を公認。R-id 突合は skip し、出力先 (brief.output_path) をユーザー指定で確定する。brief の埋め方 (機械正本 = brief schema の if/then/else):
target_skill/responsibility_id: キーごと省く (R-id は skill 紐付け専用。混入は schema FAIL)output_path: 必須。生成物出力先をユーザー指定 (導出確認済み) の値で格納する (規約パス自動解決に依存しない)owner_agent_or_skill: 実行主体の識別子。該当 agent / skill が無ければstandaloneと記載する- 共通必須 (prompt_name / layers_required / trigger_conditions / goals / checklist / output_contract / boundary / output_language): 両モード同一に埋める (IN1 criteria の standalone 代替条項 = output_path 確定と 1:1)
- goals / checklist 必須収集: 達成ゴール (成果状態文) と完了チェックリスト (YES/NO 判定文) を hearing-result → brief へ必ず載せる (Layer 5 宣言型材料。固定手順は収集しない)。
- 評価優先度 SSOT:
schemas/hearing-result.schema.jsonの enum 5 値・最大 2 が正本。enum 外回答は open_questions へ fail-visible。 - batch モード:
--batch指定時は AskUserQuestion 不使用。topic / target_skill / responsibility_id 全指定必須。 - 言語: 出力本文は日本語、パラメーター名と JSON キーは英語のまま。
ゴールシーク実行
本 Skill は固定手順ではなく、下記ゴールへ向けて完了チェックリストの未達項目を埋める手順を都度生成して反復する。下記「局面カタログ」は順序固定の手順ではなく、未達項目に応じてループが選ぶ局面メニュー。正本: harness-creator
run-build-skill/references/goal-seek-paradigm.md。
ゴール (Goal)
後続 build/evaluate が迷いなく依拠できる eval-log/prompt-brief.json と eval-log/hearing-result.json が、最小質問数 (3-5 問 + 評価優先度) と導出確認済みの状態で確定している。
目的・背景 (Why)
網羅ヒアリングはユーザー負担を増やし、AI の無断推定は brief の信頼を毀損する。ゴールと停止条件を固定し、質問設計・補完・突合の手順は要望と文脈から都度導出することで、単独起動・委譲呼出のどちらでも同一品質の brief を確定できる。
完了チェックリスト (ゴール到達の停止条件)
- hearing-result.json が
schemas/hearing-result.schema.jsonvalidation を通過している (goals / checklist / evaluation_priorities 必須搭載) - prompt-brief.json が
../run-prompt-create/schemas/prompt-brief.schema.jsonvalidation を通過している - goals が成果状態文・checklist が第三者 YES/NO 判定文で非空である
- evaluation_priorities が schema enum 内の値のみ・最大 2 で、enum 外回答は open_questions に記録されている
- skill 紐付け時は responsibility_id が target_skill の responsibilities[].id に実在し、standalone 時は brief.output_path がユーザー指定で確定している
- AI 推定値 (
ai_derived: true) が全て導出確認済み (user_confirmed: true) で、未確認推定の confirm 化が 0 件である - 既知項目 (既存 brief) への再質問が 0 件で、発行質問が 3-5 問 + 評価優先度 1 セットに収まっている
- batch モード時は AskUserQuestion 0 回で、必須引数欠落時は fail している
ゴールシークループ
正本 goal-seek-paradigm.md の 6 ステップ (現状評価→手順生成→実行→検証→Anchor Step→反復/差し戻し) に従う。反復上限は feedback_contract.max_iterations (3)。超過時は残項目を open_questions に記録し呼出元 (ユーザー / orchestrator) へ差し戻す。
局面カタログ (順序は都度判断)
- 既存 brief 差分確認:
eval-log/prompt-brief.jsonが存在すれば既知項目を抽出し、差分のみをヒアリング対象化する。 - target_skill 突合:
plugins/*/skills/<target_skill>/SKILL.mdからresponsibilities[]を抽出し boundary / layers_required を推定 (導出確認必須)。standalone では skip。 - 対話ヒアリング:
Task(subagent_type=prompt-creator-interview-user)で fork 起動。質問設計はreferences/elicit-question-bank.md(schema enum 従属) に従う。 - brief 構築: hearing-result を brief へ正規化する (goals / checklist / evaluation_priorities を脱落させない)。standalone は Key Rule 5 の brief 契約に従い output_path をユーザー指定値で埋め、target_skill / responsibility_id をキーごと省く。
- 検証: 完了チェックリストを schema validation と responsibilities[] 突合で再評価し、未達項目の局面へ戻る。
Gotchas
- 既存 brief がある場合は差分のみ。既知項目を再質問しない。
- responsibility_id 不在で target_skill 側の更新が必要なら open_questions に保持。
- AI 推定値は導出確認 (ユーザー承認) を経ずに confirm 扱いしない。補完は AI 最尤仮説 + 仮定記録で行い、人間差し戻しマーカーは生成しない。
- doc/prompt-creator/ の writing-style-principles に従い「目的+背景」併記。
- 委譲呼出 (run-prompt-create / 7layer) 時は呼出元の対話予算に従い、brief 供給済み項目の再ヒアリングをしない。
Additional Resources
references/elicit-question-bank.md— 質問テンプレ集 (evaluation_priorities は schema enum 従属)schemas/hearing-result.schema.json— 中間スキーマ = evaluation_priorities enum / goals / checklist の SSOT../run-prompt-create/schemas/prompt-brief.schema.json— brief 出力スキーマ- caller:
run-prompt-create(Step 1) /run-prompt-creator-7layer(Phase 1 委譲) - delegate agent:
prompt-creator-interview-user
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。