素材フォルダと要望から業務システムの打ち合わせ資料一式を同じ工程で作りたいとき、打ち合わせメモから変更点をまとめて影響する工程だけ直し版を上げたいときに使う。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
execution-contract.md の「6. 通常生成と確認の選択所有」に従う。L1 が確認点の選択を所有し、L2 は通常生成と既存検査を選択前から実行する。
light / standard / detailed が記録されて semantic_evaluator_started へ進んだ確認点だけ、独立レビューとその指摘に基づく改善を行う。release / exhaustive は別の明示 event を要する。
実行場所は execution-contract.md の「1. どちらのホストでも同じ呼び方」を正本とし、要点は次のとおり。
runtime_root_policy: host-skill-path を適用する。CLAUDE_PLUGIN_ROOT をplugin rootとして使用する。SKILL.md のabsolute pathから、plugin manifestを持つ祖先を上方探索して論理 PLUGIN_ROOT を解決する。cwd からplugin rootを推測せず、literal placeholderをshellへ渡さない。各shell invocation内で解決済みabsolute pathを PLUGIN_ROOT に設定する。prompts/ 配下はこのowner Skill契約を継承する。素材と要望と短いヒアリングから、業務システムの打ち合わせ資料一式を毎回同じ工程・型・品質で作る。 打ち合わせのあとは、メモから変更点を起こし、影響する工程だけをやり直して版を上げる。
| 入口 | 引数 | できあがるもの |
|---|---|---|
| new | <素材フォルダ> [要望] | <素材フォルダ>/打ち合わせ資料/ 一式 (v0.1) |
| revise | <資料フォルダ> <打ち合わせメモ> | 同じフォルダで版を上げた一式と 変更点.md |
_check/choices.json、_check/review-<確認点>.json だけ。ほかのファイルは担当スキルに任せる。構造比較と高再現の受入は workflow.md の「再現の測り方」を正本とする。お手本は4画面の型の例で、6画面参考の再現ではない。参考を再現する場合は、その版・全機能の対応・初版範囲・画像比較の結果を既存の確認点と最終報告に残す。profile.status=same だけで高再現と判定しない。
| 工程 | 担当 | 止まるか | 通す検査 |
|---|---|---|---|
| 0 データの方針と雛形 | このスキル | データの方針を聞く 1 回 | scaffold が exit0 |
| 1 ヒアリング | run-briefing-hearing | 質問のたび | --stage hearing |
| 2 要件定義書 | run-briefing-docs | 確認点1 | --stage requirements |
| 3 仕様書 | run-briefing-docs | 確認点2 | --stage spec |
| 4 ページ構成 | run-briefing-boards | 確認点3 | --stage pages |
| 5 ボードと PNG | run-briefing-boards | error と warn が 0 なら止まらない | render が exit0、目視 |
| 6 まとめ | run-briefing-book | exit0 なら止まらない | --stage all と book が exit0 |
タイトルは要望と素材の名前から短く決める (例: 「配車表の読み取り」)。読む人の既定は 現場の担当者・発注側の責任者・開発する人。
素材の名前と値を資料にそのまま載せるかを、AskUserQuestion で 1 回だけ聞く (header: 「データ」)。briefing.json がもうある (続きから再開する) ときは聞かない。
| 表示 | 記録する値 | 中身 |
|---|---|---|
| 素材のまま (おすすめ) | source | 素材をくれた先方と、作る側だけで見る |
| 伏せる | masked | それ以外の人にも見せる |
効き目は quality-rules.md の「名前と値の扱い (data_policy)」。あとで変えるときは briefing.json の data_policy を直し、ボードの札を合わせる。
雛形を作る。
node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/build-briefing-scaffold.mjs" init \
--materials "<素材フォルダ>" --title "<タイトル>" --data-policy <source|masked>
_check/materials.json を読み、素材の一覧を種類ごとに 1 行ずつ見せる。
needs_csv: true の Excel があれば、CSV に書き出してもらうよう頼む。読めない素材は「読めない」と書き、推測で埋めない。
既存ファイルは上書きされない (skipped に出る)。続きから再開するときは skipped を見て工程を選ぶ。
Skill run-briefing-hearing に 資料フォルダ と 要望 を渡す。聞き方と回の数は run-briefing-hearing が決める。
ヒアリング.md が --stage hearing を通ったら次へ。
Skill run-briefing-docs に requirements を渡す。要件定義.md が --stage requirements を通ったら 確認点1 へ。
Skill run-briefing-docs に spec を渡す。仕様書.md が --stage spec を通ったら 確認点2 へ。
Skill run-briefing-boards に pages を渡す。briefing.json の pages と表が --stage pages を通ったら 確認点3 へ。
仕様書の「ボード:」行と番号がずれたと返ってきたら、Skill run-briefing-docs にその行だけ直してもらう。
Skill run-briefing-boards に boards を渡す。render-board-png.mjs が exit0 (error も warn も 0) になり、PNG を目で見て崩れがなければ、止まらずに工程6 へ進む。文字の量の報告 (notices の TEXT-LONG・NOTES-MANY) では止まらない。
boards が 3 回直しても error か warn が残って返ってきたら、残った検査コードとボード番号を見せて利用者に相談する。
boards が 9 章に無い 決めること を返したら、Skill run-briefing-docs に 9 章へその Q だけ足してもらい (工程4 の「ボード:」行と同じ頼み方)、boards を通し直す。確認点は過ぎているので、その Q は打ち合わせで聞く。
boards が仕様書の足りない章と画面番号を返したら、Skill run-briefing-docs にその箇所だけ書き足してもらい、boards を通し直す。
確認点3 で light / standard / detailed が選ばれていたら、ここで同じ深さのまま boards を見てもらう (確認点の手順 5 と同じ。保存先は _check/review-boards.json)。
--stage all を通す。error が出たら、そのファイルを書いてよいスキル (workflow.md の「出力フォルダ」の表) に直してもらう。変更点.md はこのスキルが revise の手順 4 と同じく直す。exit0 になってから Skill run-briefing-book を呼ぶ。
book が exit1 なら、book が示した担当スキルへその行を渡して直し、book を通し直す。担当スキルが無い行 (plugin の入れ直し) は、通し直さずに利用者へ伝える。2 回目も exit1 なら利用者に相談する。exit0 なら報告へ。
確認点1〜3 は同じ手順で進める。 確認点ごとの選択と次の工程への遷移は、共通の execution-contract.md 6節に従う。
検査を通した現物を見せる。
確認点1: 要件定義.md の場所、最初の版でやること、まだ決まっていない 決めること の件数と一覧。
確認点2: 仕様書.md の場所、画面一覧の表、しくみと基盤の表、最初の版に入れないもの。
確認点3: ページ構成の表 (番号・型・タイトル・主な読み手・伝えること)。ボードにならない画面 (要件定義 6 章で あとで に回した画面) と、あとで に回した 要望 の機能 (9 章の Q と、mechanism で描くか) を添える。下のコマンドで差の表を作り、「ページの型の並び」「画面のボードの数」「あとで に回した要望のしくみ」の 3 行を見せる (ほかの行はボードを作ってから埋まるので、報告で見せる)。
node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/compare-briefing-profile.mjs" --dir "<資料フォルダ>"
どの確認点でも validate の warn があれば件数と中身を添える。
確認点1・2 では、この工程で 決めること に増えた Q があれば聞き足す。無ければ飛ばす。確認点3 は飛ばす (工程4 は docs を呼ばないので Q が増えない)。
run-briefing-hearing を followup <資料フォルダ> <Q 番号の並び> で呼ぶ。何をどう聞くかは run-briefing-hearing が決める。run-briefing-docs に answers <資料フォルダ> <組> で渡して反映し、その工程の --stage を通し直す。AskUserQuestion で次の 4 つから 1 つを記録する (header: 「確認点1」など)。
| 表示 | 記録する値 | 中身 |
|---|---|---|
| 標準で見る (おすすめ) | standard | 正確さ・言葉・見た目・シンプルさを見る |
| このまま進める | accept-as-is | 見ないで次の工程へ |
| 軽く見る | light | 検査結果と、確認点ごとに決めた観点 1 つだけ |
| 詳しく見る | detailed | 4 観点に加えて素材との突き合わせを全部 |
確認点ごとに見る観点は assign-briefing-evaluator の SKILL.md の「深さ」を読む。
利用者が自由入力で直したい点を書いたら、その点を担当スキルで直し、検査を通し直して同じ確認点をもう一度見せる。
選んだ値は _check/choices.json に確認点ごとに書く (例 {"requirements": "accept-as-is", "spec": "standard", "pages": "light"})。同じ確認点を見直したら上書きする。
accept-as-is なら、次の工程へ進む。
light / standard / detailed なら、Skill assign-briefing-evaluator に 確認点 (requirements / spec / pages)、深さ、資料フォルダ、素材フォルダ を渡す。
_check/review-<確認点>.json に保存する (保存はこのスキルの役目)。資料フォルダの 要件定義.md・仕様書.md・briefing.json と打ち合わせメモを読む。
メモの中身を 1 件 1 行に分け、影響する工程を決める。
| 変わったもの | やり直す工程 |
|---|---|
| 目的・範囲・できること・決めることの答え | 2 要件定義書 → 3 → 4 → 5 → 6 |
| 画面の項目・動き・ルール・しくみ・権限 | 3 仕様書 → 5 (該当ボード) → 6 |
| ページの並び・増減 | 4 ページ構成 → 5 → 6 |
| ボードの見た目・言い回しだけ | 5 (該当ボードだけ --only) → 6 |
変更点.md の先頭 (タイトルの直後) に新しい版の節を足す。版を上げる前に書く。docs の版上げは 変更点.md の一番上の版と 要件定義.md の版が同じかを検査するので、後に書くと必ず止まる。 書き方は document-structure.md の「変更点.md」を、お手本は examples/sample-haisha/打ち合わせ資料/変更点.md を読む。
Skill run-briefing-docs に「版を 1 つ上げる」と伝え (例: v0.1 → v0.2)、手順 3 で書いた節の行を変更の一覧として渡す。要件定義.md と 仕様書.md の「版:」行はこのスキルでは書かない。
file が 変更点.md の error が返ってきたら、手順 3 の節をその行だけ直してから、同じ版でもう一度頼む。2 回目も返ってきたら、止めて利用者に相談する。
やり直す工程だけを順に進める。やり直した工程の確認点だけで止まる。確認点では、前の版の _check/choices.json の値を添えてから聞く。
工程 2・3 は version-up で直した文書を確認点で見せるだけにし、requirements と spec は呼び直さない。確認点の手順 2 の Q は、version-up の 見せるもの の「増えた 決めること」のうち、まだ聞いていないものから取る。
確認点の手順 2 で答えが出た Q も、answers が exit0 で返ってから、変更点.md の今の版の節に続きの C 番号で足し (書き方は手順 3 と同じ)、--stage requirements を通す。error はその行を直す。
この版で 決めること の Q が増えたか閉じたら、工程5 ではその Q の話が出てくるボードを直す (雛形からの作り直しではなく、そのボードだけの更新)。
最後に 工程6 を通す (工程6 の決まりのとおり)。版がずれていると book が止まる。
最後に次を短く伝える。ファイルの中身は貼らない。
_check/profile.json。構造の差・無効な材料・未計測。参考再現時は参考版・意味と範囲の対応・視覚照合の受入結果も別に報告。参考がない通常生成では高再現を「対象外」、参考が未提供なら「未検証」と書く)/briefing-revise <資料フォルダ> <メモ>)まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
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 基準で機械検証したいときに使う。