アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-intake-kickoff
intake セッション起動直後にパターン・深度・痛点 3 軸を確定したいとき、run-skill-intake から phase 1 として呼ばれて kickoff.json を生成したいときに使う。
インストール方法を見る含まれるファイル(9)
- SKILL.md10.1 KB
- prompts/R1-main.md6.8 KB
- references/depth-criteria.md360 B
- references/pain-ranking-template.md594 B
- references/pattern-catalog.md503 B
- references/resource-map.yaml373 B
- schemas/output.schema.json1.7 KB
- scripts/validate-kickoff-json.py1.0 KB
- workflow-manifest.json3.2 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-intake-kickoff
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契約を継承する。
Purpose & Output Contract
intake セッションの最初の phase。ユーザー初期発話から 3 軸 (pattern A-E / depth / pain ranking) を AskUserQuestion で 1 問ずつ確定し、後続 phase の共通基盤となる kickoff.json を生成する。本スキルは「セッション起動・3 軸確定・kickoff.json emit」に責務を絞り、5 軸シート充足 (run-intake-interview)、深掘り (Phase 5)、可視化 (run-intake-visualize)、mode 判定 (run-intake-next-action) は行わない。
入力: 初期発話 (自由記述、orchestrator から渡される)
出力: output/<hint>/kickoff.json (schemas/output.schema.json 準拠)
完了条件: pattern / depth / skill_name_hint / pain_ranking 4 項目が揃い、scripts/validate-kickoff-json.py exit 0。
出力 JSON 形式
{
"pattern": "A|B|C|D|E",
"depth": "quick|standard|detailed",
"skill_name_hint": "<kebab-case>",
"pain_ranking": [{"task": "...", "frequency_per_week": 3, "minutes_per_run": 30}],
"initial_utterance": "...",
"timestamp": "ISO8601",
"qa_log": [{"question": "...", "answer": "..."}]
}
Key Rules
- 3 軸のみ確定: pattern / depth / pain ranking。仮説検証 (assumption-challenger)、6 軸プロファイル (user-profiler)、5 軸シート (
run-intake-interview) には踏み込まない。 - AskUserQuestion は 1 問ずつ: Q1 (pattern) → Q2 (depth) → Q3-N (pain) を順次。並列・束ね質問禁止。
- 語彙は beginner 既定: 初対面のため平易語を使用 (
vocabulary_tier確定は後続 phase の責務)。 - 口語→技術用語の整形は許可: 「定型作業」→「ルーチンタスク」など軽整形は可。本旨改変・要約は禁止 (生回答を
qa_log[]に保存)。 - skill_name_hint に固有名詞を直書きしない: 社名・個人名は variable_abstraction (Layer 1.2)。
- pattern E (不明) 許容: 確定不能時は E で進め、Phase 8 Gate A 時点で再判定する。
ゴールシーク実行
ゴール (Goal)
初期発話を起点に output/<hint>/kickoff.json が schemas/output.schema.json 準拠で生成され、scripts/validate-kickoff-json.py exit 0、4 項目 (pattern / depth / skill_name_hint / pain_ranking) すべて充足、qa_log[] に Q&A 時系列を保存した状態。
目的・背景 (Why)
3 軸が曖昧なまま後続 phase に進むと、interview の質問数が爆発し、profile / 5 軸シート / 可視化が手戻りする。固定手順では初期発話の粒度・ユーザーの語彙差・痛点列挙数に脆く、未充足軸を都度埋めるゴールシークが必要。本スキルは制御フェーズの第一歩として「最小 3 軸の合意」を機械検証可能な形で固定する。
完了チェックリスト (Checklist)
- 初期発話を改変・要約せず受領し、整形後文も本旨保持
- Q1 で
pattern∈ {A, B, C, D, E} を 1 つ選択 (E 許容、references/pattern-catalog.md提示後) - Q2 で
depth∈ {quick, standard, detailed} を確定 (references/depth-criteria.md提示後) - Q3-N で
pain_ranking[]を 1〜3 件、各要素にtask/frequency_per_week/minutes_per_runを充足 (references/pain-ranking-template.md準拠) -
skill_name_hintを pain 動詞 + 目的語から kebab-case で決定論的に生成 (固有名詞混入なし、同 qa_log なら sha256 一致) - AskUserQuestion を並列発行していない (完全直列)
-
output/<hint>/kickoff.jsonがschemas/output.schema.json準拠 -
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/skills/run-intake-kickoff/scripts/validate-kickoff-json.py output/<hint>/kickoff.jsonexit 0 -
qa_log[]に質問・回答ペアが時系列で保存され、ユーザー回答は生のまま - 本スキルの責務外 (5 軸シート充足・深掘り・mode 判定) に踏み込んでいない
ゴールシークループ
固定手順ではなく、上記チェックリストを唯一の停止条件とする。未充足軸を特定 → 次に出すべき AskUserQuestion (3 択 + 自由入力) を立案 → 回答取得 → qa_log[] 追記 → checklist 自己評価、を反復する (上限は prompts/R1-main.md Layer 4 反復回数)。workflow-manifest.json の phase 順 P1-pattern → P2-depth → P3-pain → P4-emit に従い、各 phase の fatal_exit_codes 検出時は即停止して未充足項目を stderr に列挙する。
Gotchas
- 責務逸脱禁止: 「真の課題は?」などの深掘りは Phase 5 (assumption-challenger)、5 軸シートは
run-intake-interviewの責務。本 phase で踏み込むと同意ループを誘発する。 - AskUserQuestion 3 連発禁止: 必ず 1 問ずつ。並列質問は認知負荷が高く回答品質が落ちる。
- pattern E は逃げではない: 確定不能時の正当な選択肢として扱い、Phase 8 Gate A で再判定する設計に従う。
- skill_name_hint 固有名詞: 社名・個人名を直書きすると後続成果物全体に漏洩する。variable_abstraction で抽象化。
- validate-kickoff-json.py 自動修正禁止: FAIL 時は不足項目をユーザー提示し、LLM 判断で勝手に埋めない。
Additional Resources
workflow-manifest.json— P1-P4 phase 定義・dependsOn・entryHook/exitHook・fatal_exit_codesprompts/R1-main.md— R1-pattern-depth-pain-confirm 7 層プロンプト (Layer 1-7)schemas/output.schema.json— kickoff.json 正本スキーマreferences/pattern-catalog.md— pattern A-E の選択肢と判定基準references/depth-criteria.md— quick / standard / detailed の判断基準references/pain-ranking-template.md— 痛点構造化フォーマットreferences/resource-map.yaml— machine-readable リソース一覧scripts/validate-kickoff-json.py— 出力 JSON の schema validate- 後続 phase:
run-intake-interview(5 軸シート),run-intake-visualize,run-intake-next-action,run-intake-finalize
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。