القائمة
積み上げブランチ（stacked PR、A→B→C のように前の PR の先に次のブランチを切る運用）で push・マージするときに使う。「stacked PR」「積み上げ PR」「PR を分割」「ブランチを積む」 と言われたとき、または複数 PR が依存関係（base 違い）を持つ状況で該当する。 単発の独立ブランチ・PR には使わない。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 が「前提の事実検証（執筆前）」なのに対し、 これは「読み手の受け止め検証（執筆後）」。誤字脱字や体裁の校正、単一観点のレビューには使わない。
| name | stacked-pr |
| description | 積み上げブランチ（stacked PR、A→B→C のように前の PR の先に次のブランチを切る運用）で push・マージするときに使う。「stacked PR」「積み上げ PR」「PR を分割」「ブランチを積む」 と言われたとき、または複数 PR が依存関係（base 違い）を持つ状況で該当する。 単発の独立ブランチ・PR には使わない。 |
他ブランチを基点に切ったブランチの push 事故と、マージ順序を誤ったときの PR 自動クローズ事故。どちらも一度起きると force push なしでは戻せない。
git checkout -b new-branch origin/other-branch のように他ブランチ基点で切ると、
upstream が origin/other-branch に向く。この状態で git push -u origin new-branch
すると、環境の push 設定によっては other-branch 側に push されてしまうことがある
（意図した new-branch ではなく、基点にした方の remote ブランチにコミットが乗る）。
対策:
git push origin <branch>:refs/heads/<branch>git branch --unset-upstream してから push -u事故った場合、force push は（ガード環境では）通らない前提で復旧する:
stacked PR（A→B→C）を下から順にマージするとき、先に子 PR の base を付け替えてから 親をマージする。
理由: gh pr merge --delete-branch で base ブランチを削除すると、それを base にしていた
open PR は自動クローズされ、再オープン不能になる（base 変更も closed PR には効かない）。
自動クローズされた PR は同じブランチから作り直すしかない（PR 番号は変わる）。
正しい手順:
gh pr edit <child> --base main（子の base を先に main へ付け替え）gh pr merge <parent> --merge --delete-branch一般化: 「削除される側に依存している open な何か」がないか、削除・クローズ系の 操作の前に必ず確認する。