表形式の数値データを、記述・比較・分解・可視化・意思決定支援の単一 HTML レポートにするスキル。数値はコードで再現し、根拠の強さと限界を示す。レポートの打ち手を、ユーザーへのヒアリングを往復して、現場で動く人向けの「目的・ゴール・やること」の資料にもする。因果推論や高度な予測は対象外。「レポートを作って」「分析して」「データから何が言えるか」「月次レポート」「現場向けの資料」「実行部隊に渡す」「アクションプランにして」などで使う。アプリの画面には使わない。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
読み手が、結論の数字→大きい要因→根拠と限界→次の判断を1本の流れで追える単一 HTML を作る。扱えるのは、手元データから決定的に再計算できる記述・比較・分解・可視化と、それに基づく意思決定支援である。
背景の説明は証拠の強さに合わせて「データで確認」「公表資料」「想定」を分ける。相関や時間的な前後だけで因果を断定しない。根拠が足りない場合は、主張を弱め、限界と次に必要なデータを示す。
通常は init → build で終了する。build は計算、HTML生成、数値・依存関係の検査まで行い、ブラウザや別 context を起動しない。ユーザーが厳格検証を明示しない限り、verify、独立 review、done を追加しない。
R=<スキルの場所>/scripts/report.mjs
node $R init <出力ルート> <YYYY-MM> <slug> <データ...>
node $R build <フォルダ>
profile.json、入力欄つきの brief.json、analysis.mjs を作る。情報量の初期値は 標準。既存フォルダで失敗したら、表示された回復手順に従う。prompts/analyst.md に従って brief.json を埋め、analysis.mjs に計算・判定・文言・図を集約する。途中で早く誤りを見たいときだけ report.mjs check <フォルダ> を使う。外部の背景が本当に必要な場合だけ調査する。<name>.html を成果物として渡せる。ユーザーが厳格レビューを明示した場合だけ使う。verify は build を内包するため、先に build を実行しなくてよい。
node $R verify <フォルダ> # build + 4幅の実描画 + 証跡記録
# 別 context で prompts/review.md を実行
node $R done <フォルダ>
review 後に must を修正した、または HTML を変えたときは、再度 verify し、別 context が最終成果物を再 review する。done は実描画済み証跡、最終HTMLのSHA-256、4条件PASS、未解決must 0件に加え、担当・期限が未確定の pending 打ち手が残っていないことを確認する。通常 build は意思決定ドラフトとして pending を警告に留める。
レポートの打ち手を、現場で動く人向けの「目的・ゴール・やること」の資料にする。数字の根拠や統計は載せない。AI が hearing.md に下書きを書き、ユーザーには決めてほしいことだけを聞く。手順は prompts/handout.md。
node $R hearing <フォルダ> # 下書きを作る / AI が直すことと聞くことを出す (回答待ちは終了コード 3)
node $R handout <フォルダ> # 了承済みのシートから <フォルダ名>-handout.html を作る
| 工程 | 読むもの |
|---|---|
| 設計・build | prompts/analyst.md、references/statistics.md、references/thinking.md。背景を説明するときだけ references/causes.md |
| 図を選ぶ | references/charts.md |
| 外部調査 | 別の調査役が prompts/research.md |
| 厳格検証の独立 review | 別 context が prompts/review.md。初回と再 review のどちらも同じ |
| 実行部隊向け資料 | prompts/handout.md |
| スキル自体の保守 | references/maintenance.md |
上限・列挙値が prompt の記述と report.mjs の診断で食い違って見えたら、診断を優先する。
analysis.mjs で再現する。?)、「この図の読み方」、末尾の用語集は build が自動で付けるので、ソースに説明文を書き足さない。文言を直すときは scripts/glossary.mjs を直す。要点・標準・詳細 から選べる。指定がなければ 標準 で完成させ、情報量の確認だけで生成を止めない。背景データ*.csv からだけ使う。覚えている数字は書かない。brief.json と analysis.mjs に集約し、生成された .src.html と .html は手で直さない。caution に留める。セクションは1つずつ枠で囲んだパネルにし、上端の見出し帯 (種類のチップ + h2) と種類ごとの色で区切る。見出し帯と色は build が付けるので、ソースには書かない。出力は「結論→要因」を必須とし、ユーザーが求めた場合、または判断に必要な場合だけ末尾に「打ち手」を置く。打ち手を置く場合は、根拠の強さに応じて業務上の行動、検証、または追加データ取得の指示にする。要因は影響の大きい順に絞り、根拠の強さ、判断への意味、図、統計の要約、計算元を結び付ける。
専門知識が無くても読めるように、説明は3段に分けて「触ったときだけ」出す。(1) 本文の専門用語には点線と小さな ? だけを付ける、(2) カーソルを合わせる・キーボードで移る・押すと、その場に「何の値か / どう読むか」の2行が出る、(3) 図には閉じた「この図の読み方」を、文書の末尾には使った用語だけの用語集を置く。JS が無い環境では (1) は用語集へのリンクとして働き、(2) の代わりに用語集へ飛んで同じ説明が読める。印刷時は (3) がすべて開いた状態で出る。
report.mjs build が合格し、<name>.html が生成されている。report.mjs handout が合格し、<フォルダ名>-handout.html が生成されている。verify、独立 review、done が合格している。references/maintenance.md の検査 (smoke-test、必要なら selftest) が合格している。まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・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 基準で機械検証したいときに使う。