アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-intake-option-catalog
外部連携カタログを参照して候補を選択肢化したいとき、purpose.json を基に options.json を生成したいときに使う。
含まれるファイル(5)
- SKILL.md8.6 KB
- prompts/R1-search-summarize.md7.5 KB
- references/integration-catalog-pointer.md328 B
- references/resource-map.yaml274 B
- references/tier-criteria.md198 B
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-option-catalog
Purpose & Output Contract
Phase 6 担当の 連携選択肢生成 run skill。orchestrator (run-skill-intake) から Skill tool で委譲され、purpose.json の true_purpose.verb_object を起点に外部連携候補 (Slack / Notion / Gmail / Drive / Linear 等) を静的カタログから引き当て、ユーザー選択を経て options.json を生成する。カタログ自体は読み取り専用で、本 skill の write は options.json 生成に限る。
入力: purpose.json, references/integration-catalog-pointer.md 経由の integration カタログ
出力: output/<hint>/options.json (selected_integrations / rejected 配列)
任意フィールド (mode P 判定入力): plugin_scale (boolean: ヒアリング中に plugin 規模構想 (hook/command 等複数コンポーネント) が明示されたとき true) / component_requests[] (string[]: ユーザーが要望したコンポーネント種別 (skill/hook/command/agent/mcp 等))。Phase 11 run-intake-next-action の decide-mode.py が mode P 判定入力として読む。
完了条件: tier=required の連携が全て選択または除外 (reason 付き) で確定し、ユーザーが選択肢確認に応答済み。
性質: run kind。責務プロンプトは prompts/R1-search-summarize.md、参照カタログは references/ 配下に閉じる。カタログの書き換えは行わない (write は options.json のみ)。
Key Rules
- カタログ参照のみ: 新規連携の追加・カタログ書き換えは行わず、読み取り専用で振る舞う。
- 必須/任意 tier の明示: 各候補に
tier ∈ {required, optional}を必ず付与する。 - rejected の理由必須: ユーザーが除外した候補には
reasonを必ず記録する (空文字禁止)。 - 新規連携の提案禁止: カタログ外の連携が要るときは別 phase で skill 拡張を提起する (本 skill で勝手に拡張しない)。
ゴールシーク実行
Goal: purpose.json から導出した verb_object に対し、tier=required 連携が全て確定し reason 付きで rejected も埋まった options.json を生成する。
Why: Phase 6 で連携選択が漏れると後続 phase (実装計画・タスク仕様化) が空中分解し、orchestrator (run-skill-intake) 以降が options.json を消費できなくなるため。tier=required を必ず明示・確定させることで、後段の責務分離 (実装 skill / 評価 skill) が崩れない。
Checklist (上から順にチェックし、未充足があればその項目に戻る反復構造):
-
purpose.jsonのtrue_purpose.verb_objectとtime_freed_intentを抽出済み -
references/integration-catalog-pointer.md経由で plugin 共有references/integration-catalog.mdを読み、verb_object に親和する候補を列挙済み - 各候補に
tier,id,nameを付与し、tier=required の候補が漏れなく含まれているか確認済み - AskUserQuestion で候補をユーザー提示し、selected / rejected の判断を取得済み
- rejected 全項目に空でない
reasonが記録済み (tier=required を除外する場合も理由必須) -
output/<hint>/options.jsonを{ "selected_integrations": [...], "rejected": [...] }形式で書き出し済み - 出力が purpose.json の verb_object と整合し、新規連携 (カタログ外) を提案していないことを自己確認済み
期待出力例:
{
"selected_integrations": [{"id": "notion-publish", "name": "Notion 公開", "tier": "required"}],
"rejected": [{"id": "slack-notify", "reason": "通知不要"}]
}
Gotchas
- tier=required も除外可、ただし reason 必須: 必須連携は提示するが、ユーザーが明示的に除外する場合は理由を残し下流 skill に判断材料を渡す。
- カタログ外候補の誘惑: verb_object に近い連携がカタログに無い場合でも本 skill では補完せず、別 phase (skill 拡張要求) として上げる。
- pointer 経由の参照:
integration-catalog.mdは plugin 共有references/にあるため必ずintegration-catalog-pointer.mdを経由し、直接ハードコード参照しない。 - 責務の最小化: カタログ参照と
options.json生成のみを担い、連携の実行・認証・公開は他 phase に委譲する (write はoptions.jsonに限定)。
Additional Resources
references/integration-catalog-pointer.md— plugin 共有 references/integration-catalog.md への参照ガイドreferences/tier-criteria.md— required / optional の判定基準
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。