dotfiles

Claude Desktop を deep link（claude:// URL スキーム）で開く・リンクを作る。 「Desktop で開いて」「この続きを Desktop の Claude Code で」「このディレクトリで Desktop セッションを立てて」「chat / Cowork への引き継ぎリンクを作って」と言われたとき、 またはドキュメントに Claude 起動リンクを埋め込みたいときに使う。 ターミナルで新しい claude CLI セッションを開くだけの場合には使わない（それは cmux や ターミナル側の操作）。

経営層・意思決定者向けの情報密度の高い HTML 資料 (経営会議/合宿/役員提案/戦略ドキュメント/投影用 1 ページ資料) を、parts 分割 + build script のパイプラインで作る。投影・配布・PDF を単一 HTML ファイルで兼ね、PPTX を経由しない。 経営資料・ボード資料・役員プレゼン・意思決定ドキュメント・社内戦略資料・合宿資料を「作る/構成する/作り替える」ときは、ユーザーが "deck" や "HTML" と明示しなくても必ずこの skill を使う。特に「複数セクションある」「投影もするし配布もしたい」「情報量が多い」資料で効く。 組織ブランドのトンマナ (色・フォント) が要る場合は、この skill の上に組織のブランド skill (トンマナを定義した skill) を重ねる — この skill 自体は中立トークンで動く。 使わない場面: PPTX/Google Slides の生成、単発の 1 枚 HTML、ブログ記事や README などの長文ドキュメント、定例の進捗報告・軽い社内共有スライド (経営レビューや意思決定を伴わないもの)。

エージェント協働開発の「進め方」のポストモーテム。日次は軽く、週次はフルで、その期間の開発プロセス・委譲・レビュー・アーキテクチャ判断を振り返り、仕組み化まで落とす。`/process-retro [daily|weekly]` のほか「今日の進め方を振り返って」「ポストモーテムして」でも起動。成果物そのものの振り返り（何を作ったか）ではなく進め方が対象。

初めて向き合うコードベース（または久しぶりに戻る repo）の全体検査。repo-scout / code-archaeologist / risk-surveyor の 3 subagent を並列で偵察に出し、メインは 5 つのレンズ（前提を疑う / ゼロベース設計 / 設計の考古学 / Think Big / 計算されたリスク) で判断と Top Findings の選定に専念する。「grand review」「コードベースを検査して」 「この repo の全体像とリスクを見て」「初回レビュー」で起動。個別 PR のレビュー （/review 系）や単発のバグ調査には使わない。

Mermaid 図（mermaid.js、特に 11.x 系）を作成・編集するときに使う。構文エラーで レンダリングが崩れる・図が表示されないトラブルの調査にも使う。表で足りる単純な 数値比較や統計提示には Mermaid を使わず Markdown 表を優先する判断も含む。

経営資料・提案書・戦略ドキュメントを、その文書の実在ステークホルダーから構成した複数ペルソナ （意思決定者・競合/敵対者・影響を受ける現場）で独立に敵対レビューし、複数ペルソナが独立に 突き当たる「横断 gap」を抽出する手法。ドラフトが固まってきた段階（後半〜配布前）で 「レビューして」「穴を見つけて」「経営陣にどう見えるか」と言われたとき、または重要資料の 配布前チェックとして使う。fan-out-research が「前提の事実検証（執筆前）」なのに対し、 これは「読み手の受け止め検証（執筆後）」。誤字脱字や体裁の校正、単一観点のレビューには使わない。

積み上げブランチ（stacked PR、A→B→C のように前の PR の先に次のブランチを切る運用）で push・マージするときに使う。「stacked PR」「積み上げ PR」「PR を分割」「ブランチを積む」 と言われたとき、または複数 PR が依存関係（base 違い）を持つ状況で該当する。 単発の独立ブランチ・PR には使わない。

オーナー（私）の執筆を駆動する自分用 writing スキル。テーマ・下書き・リサーチ依頼を受け取り、媒体（blog / 社内向け / techblog / essay / slide）に合わせた私の声で一緒に書き上げる。「書きたい」「記事にしたい」「下書きを見てほしい」「ブログを書く」「社内に投稿したい」「登壇資料を作りたい」などの執筆意図が見えたら使う。リサーチ・引用・フック改善・アウトライン反復・セクション単位のフィードバックも含む。

静的 HTML / 単一ファイルのサイトを、Google アカウント認証で範囲限定 (組織ドメイン + 個人メール/Google グループの allowlist) して Google Apps Script (GAS) Web Apps で共有する。サーバ不要・無料・共有通知メールが飛ばない・URL を変えずに中身を更新できる。 社内・チーム限定で資料/ダッシュボード/レポート/ツールを Web で配りたい、特定の人だけに見せたい、でも Drive 共有の招待通知は飛ばしたくない、ホスティングは立てたくない、というときは必ずこの skill を使う。exec-deck の配信層にも使う。 使わない場面: 一般公開 (ANYONE) してよい静的サイト (Pages/Vercel 等の方が速い)、Google Workspace 組織がない場合、動的な永続データストアが要るアプリ。

経営会議・役員会・経営合宿など「経営に何かを決めてもらう」資料の論理構造を設計する方法論。背骨の問い 1 本 + 決定項目リスト N 個を初日に凍結し、各決定を (選択肢 / 推奨 / やる理由 / 先行指標 / 撤退ライン / 退室時の状態) のセットで設計する。 意思決定資料・ボード資料・合宿資料・投資判断資料・戦略提案を「構成する/章立てする/作り直す」とき、特に「経営に決めてほしいことがある」「論点が複数ある」資料では、本文を書き始める前に必ずこの skill を使う。資料が発散する・何を決める会議か曖昧・決定がフォローされない、を防ぐ。 実際の HTML 化は exec-deck skill、一次情報の確定度管理は source-fact-intake、当日の進行は meeting-run-design に渡す。単なる情報共有資料・報告書には使わない (決定がないなら不要)。

経営判断・戦略・投資の中心命題を、執筆前に「反証テスト」にかける方法論。資料の主張を 3-5 個の検証可能な claim に分解し、deep-research や複数 subagent でファンアウトして各 claim を敵対的に (反証を探す形で) 検証し、refuted / caveat を確定させてから執筆に入る。 戦略資料・投資判断・経営提案を作る前、または「この前提は本当に正しいのか」「市場・競合・トレンドは実際どうなっているか」を確かめたいときは必ずこの skill を使う。資料を書き上げてから前提が崩れて作り直す事故を防ぐ。 実行エンジンは deep-research skill や Workflow / 複数 subagent — この skill は「いつ・何を・どう割って・どう検証するか」の設計を担う。単純な一次情報の取り込み (社内資料の読み込み) は source-fact-intake、軽い事実確認 1 件には使わない。

GitHub Actions から GCP へ最小権限でデプロイする CI（Workload Identity 連携 + gcloud builds submit + gcloud run deploy）を構築・デバッグするときに使う。 特に「forbidden from accessing the bucket」「caller does not have permission to act as service account」「artifactregistry.repositories.downloadArtifacts denied」 などの gcloud 権限エラーの調査、WIF の Terraform 構成、デプロイ SA / ビルド SA の 権限設計が対象。エラーメッセージは真因を指さないことが多いので、推測でロールを 足す前にこの skill を読む。GCP 以外の CI/CD や、サービスアカウント鍵を使う レガシー構成には使わない。

public repo に push する前に、gitleaks で secret・既知の機密パターンを機械的・確定的に スキャンする層。API キー / トークン / 秘密鍵に加え、個人・社内固有のマーカー (会社ドメインの メール、絶対ホームパス、機密表示、社名のべた書き) を共通 config で検出する。任意の public repo で使える (repo 固有の設定に依存しない)。「leak check」「gitleaks かけて」「公開前に secret チェック」、あるいは新しい public repo に pre-push ガードを仕込みたいときに使う。 意味的な「これ公開して平気か」判断は safe-to-publish skill が担う — この skill はその下の 機械的レイヤー。

経営会議・役員会・経営合宿の「当日の進行」を、資料と同格の成果物として設計する。分単位のタイムボックス、ファシリテーション進行台本、決定キャプチャシート (空欄を資料に同梱)、決定後の追跡受け皿 (宿題表・次のゲート) を作る。 経営会議・合宿・役員会・ワークショップの資料を作るとき、または「当日どう進めるか」「時間配分」「ファシリ」「決まったことをどう残すか」を考えるときは必ずこの skill を使う。「立派な資料はできたが、当日の議論が時間内に終わらない / 何が決まったか残らない / 決定がその後フォローされない」を防ぐ。 資料の論理構造は decision-deck-architecture、HTML 化は exec-deck に渡す。1on1 や定例の軽い打ち合わせには使わない (重い意思決定の場が対象)。

任意の public repo に push しようとしている差分が「公開して大丈夫か」を意味的にレビューする。 機械的な secret・既知パターン検出 (leak-scan skill / gitleaks) が拾えない穴を埋める層で、 正規表現には引っかからないが公開すべきでない「内部の文脈・知識・固有名・個人情報」を 文章として読んで気づく。public repo へ commit/push する前、あるいは「これ公開して平気?」 「safe to publish か見て」と問われたときに使う。出力は OK か、懸念箇所のリスト (箇所・理由・対処案) で、最終判断はユーザーに委ねる。

経営資料・戦略資料に一次情報 (社内資料・財務数値・固有名詞・人物・ヒアリング内容) を取り込むときの規律。各事実に確定度 (確定 / 合意済 / 議論中 / 案 / PoC / 未確認) を判定して日付つきで記録し、確定したものだけを断定文・数値ビジュアルにする。機密は隔離する。 資料に数字・固有名詞・人の発言・社内ドキュメントの内容を持ち込むとき、またヒアリングや一次資料を整理して memory/notes に蓄積するときは必ずこの skill を使う。「断定形で書いてあったから確定だと思って資料に載せたら、実はまだ議論中だった」という訂正の連鎖を防ぐ。 資料の論理構造は decision-deck-architecture、中心命題の蓋然性検証は fan-out-research に渡す。一般的な Web リサーチ (社外の事実調査) は fan-out-research / deep-research の領分。