アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-briefing-book
検査を通した文書とボード PNG を目次つきの 1 ファイル HTML にまとめたいとき、版の一致と古い PNG や外部参照の有無を確かめてから渡したいときに使う。
含まれるファイル(2)
- SKILL.md9.3 KB
- workflow-manifest.json2.8 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Pre-choice usable artifact execution
execution-contract.md の「6. 通常生成と確認の選択所有」に従う。L1 が確認点の選択を所有し、L2 は通常生成と既存検査を選択前から実行する。
Post-choice selected improvement execution
light / standard / detailed が記録されて semantic_evaluator_started へ進んだ確認点だけ、独立レビューとその指摘に基づく改善を行う。release / exhaustive は別の明示 event を要する。
まとめ HTML
Runtime root contract
実行場所は execution-contract.md の「1. どちらのホストでも同じ呼び方」を正本とし、要点は次のとおり。
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
資料フォルダの文書とボード PNG を、先方に渡す 1 ファイルの HTML にまとめる。配色の受け渡しと欠落時の扱いは design-contract.md に従う。
- 先方に渡すのはこの 1 ファイルだけ。画像ははめ込み済みなので、素材フォルダやボードの PNG を一緒に送らなくてよい。ファイルや外部への参照が残ると LOCAL-REF・EXTERNAL-REF で止まり、書かない。
- 左の目次で選んだページが出る。前へ/次へ、拡大、印刷 (1 ボード 1 ページ横向き) に対応し、JavaScript が動かなくても全ページを縦に読める。
- 文書のページ (要件定義・仕様書・ヒアリング・変更点) は、カードや区切りを使ったレポートの形で描く。正本は Markdown のままで、変わるのはまとめ HTML の見た目だけ (validate と /build-app は Markdown を読む)。
- 書くファイルと中身の順は build-briefing-book.mjs の先頭の説明を読む。このスキルはスクリプトを呼ぶだけで、ほかのファイルを書かない。
- 確認の深さを選ぶのと独立レビューは、呼び出し元の run-briefing が持つ。単独で呼ばれたときは結果を見せて終わる。
手順
- まとめる。
node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/build-briefing-book.mjs" --dir "<資料フォルダ>"
- 終了コードで分ける。コードの意味とすることは execution-contract.md の「3. 終了コード」を読む。このスキルで違うのは exit 1 だけ。自分では直さず、
_check/book.jsonの errors を読み、下の表で直す担当を伝えて止まる。
| book.json の errors | 直す担当 |
|---|---|
| BRIEFING-JSON (briefing.json が読めない) | 壊れた鍵を書いた担当。pages は run-briefing-boards、palette と data_policy は run-briefing (workflow.md の「出力フォルダ」にある書いてよいスキルの表) |
| TOKENS-MISSING、TOKENS-INVALID | run-briefing (palette を確かめて init を --refresh-css で回し直し、tokens.css を作り直す。そのあと run-briefing-boards の「3. PNG にして検査する」から通し直す。design-contract.md) |
| TEMPLATE-PLACEHOLDER (まとめの雛形が壊れている) | 直さずに plugin の入れ直しを伝えて止まる |
| VERSION-MISMATCH (版が 要件定義.md と 仕様書.md でずれている)、VERSION-MISSING (「版:」の行が無い) | run-briefing-docs (version-up) |
| DOC-MISSING (要件定義.md か 仕様書.md が無い) | run-briefing-docs |
| DOC-MISSING (book.include_hearing が true なのに ヒアリング.md が無い) | run-briefing-hearing |
| PAGES-EMPTY、PAGE-FORMAT、BOARD-MISSING | run-briefing-boards (pages とボード HTML をそろえる) |
| STALE-PNG、PNG-MISSING、PNG-READ、PNG-SIZE、PNG-HASH、BOARD-CHECK-NG | run-briefing-boards (--only で該当ボードの render を通し直す) |
| EXTERNAL-REF (http や // で始まる参照)、LOCAL-REF (ファイルへの参照) | file が head なら _src/tokens.css の参照で run-briefing-boards。ページの id (bNN など) なら、そのページの元を書いたスキル。どちらも参照を消すか data: にする |
--allow-stale は利用者が「古い PNG のままでよい」と言ったときだけ付ける。付けたら報告に必ず書く。
- 報告する。
- まとめ HTML の場所 (先方に渡すのはこれ 1 つ)
- 版、ページ数 (ボードの枚数)、ファイルの大きさ
- 古い PNG と外部参照の結果 (どちらも 0 件のはず)
- ブラウザで開く方法。書き方は execution-contract.md の「ファイル名とパス」を読む (Windows は PowerShell とコマンドプロンプトで違う)
Gotchas
- 先方にこの HTML を渡すのはよい。公開リンクを作るサービスや、関係のない外部のサービスへ上げない。素材の名前と数字をそのまま載せているか (briefing.json の
data_policy) は、表紙の 1 文で分かる。 - まとめ HTML を直接書き換えない。直すのは元の文書かボードで、もう一度まとめる。
- 報告では、スクリプトが返した場所 (stdout の
out) をそのまま使う。
Additional Resources
- workflow.md: 版の決まりと出力フォルダ
- execution-contract.md: 終了コード、必要なツールの入れ方、まとめ HTML の開き方
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。