アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
build-app
新しいWebアプリを要件整理から設計・実装・Cloudflare公開・品質確認まで一貫して構築する。Codexで「アプリを作って」「業務ツールを新規開発」「$build-app」と依頼されたときに使用する。
インストール方法を見る含まれるファイル(1)
- SKILL.md3.0 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Build app
$build-appと同じメッセージに書かれた内容をアプリ要件として扱う。$app-excellenceの成果物先行契約を適用する。要件が短くても質問で止めず、リポジトリ名、既存資料、データ、業務慣習から最有力仮説を選ぶ。- catalog-default入口契約: 描画されるWeb UIを持つ新規アプリは、カラー指定や「デザインして」という文言の有無にかかわらず
jp-web-designのreferences/catalog-default-contract.mdを適用対象として委譲する。API・バッチなど可視UIを一切作らない場合だけNON_VISUAL(理由)を渡す。適用・証跡・検査の詳細は同契約だけを正本とし、この入口へ複製しない。 - Cloudflare MCP の user scope 登録と wrangler 実行はエージェントが代行する。OAuth 認証と git 管理外の
.mcp.jsonだけ本人が行う(INV-11)。codex mcp get <name> --jsonでdocs/bindings/observabilityを確認し、未登録・不通・明示的な legacytype:sseだけをcodex mcp remove <name>の後codex mcp add <name> --url https://<name の製品名>.mcp.cloudflare.com/mcpで登録し直す。/mcpを推奨するが、/sseURLがStreamable HTTP互換aliasとして動作しているだけなら移行しない。現在の要件がbindings変更またはobservability調査を必要とし、その対象が認証待ちのときだけ、利用者本人へ対象1件のブラウザ認可(codex mcp login <name>)を1行で依頼する。未使用MCPの認証は求めず、承認を待たずに次へ進む。 app_orchestratorカスタムエージェントへ、成果物先行・事前質問ゼロで要件とcatalog-default判定を委譲し、完了まで待つ。カスタムエージェントを利用できないクライアントでは、現在のスレッドで$app-orchestratorを使用して同じ手順を完遂する。- 最初の返却物は空欄の質問票ではなく、仮説入りT1/T2、最頻業務を通すWalking Skeleton、操作可能な代表画面のいずれかにする。本人しか決められない秘密・課金・公開・破壊操作があっても、ローカル成果物またはdry-runまでは先に作る。
- 最終報告の先頭に、公開したURLと現在の段階(v0=関係者向け / v1=本番)、試してほしい操作、今できないこと(残課題)を書く。その後に採用案の根拠、実施テスト、品質監査結果を記載する。可視UIを含む場合はcatalog-defaultの段階別判定結果だけを1行添える。非エンジニアが一度で理解できる言葉を使う。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。