Menu
[2] design を実装単位に分解し、複数の [3] impl issue を起票する ([2]→[3] のブレイクダウン)。[2] を review + needs-human に遷移する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | breakdown-design |
| description | [2] design を実装単位に分解し、複数の [3] impl issue を起票する ([2]→[3] のブレイクダウン)。[2] を review + needs-human に遷移する。 |
issue-protocol.md の遷移 X2。design-issue が
仕上げた設計を、実装可能な単位の type:impl issue 群に分解する。
入力: 設計本文が完成した（status:in-progress）の type:design issue N。
.env の IMPL_AGENT（既定 claude）で
決める — Step 1 は claude、Codex 導入後 (Step 2) は codex。env var は永続しない
ため .env の source は同一ブロックで行う（protocol §9）:
set -a; . ./.env; set +a
gh issue create --repo "$TARGET_REPO" \
--title "<impl issue title>" \
--label "type:impl" --label "status:triage" \
--label "agent:${IMPL_AGENT:-claude}" \
--body "$(cat <<'EOF'
親: #<[2]の番号> 由来: #<[2]の番号>
<変更する範囲>
<実装指示>
<検証方法>
PR が open + CI green EOF )"
`IMPL_AGENT` が実行機構の切り替え点（protocol §5-2 のハイブリッド）。Step 1 では
`claude` なので、起票された [3] を `/orchestrate-once` がそのまま拾える（人手での
`agent:` 貼り替えは不要）。特定の [3] だけ担当を変えたいときは人間が貼り替える。
3. 起票した [3] 番号を [2] にコメントで一覧記録する:
```bash
set -a; . ./.env; set +a
gh issue comment <[2]の番号> --repo "$TARGET_REPO" --body "子 [3]: #<n1> #<n2> ..."
in-progress→review + needs-human に遷移する（issue-transition）。
設計方針の承認（G3）と [2] の close は人間が行う。status:triage 起票。ready 化は人間（G2 相当）。親: / 由来: を必ず書く（protocol §7）。Markdown を共通テーマの HTML（画面ダーク / 印刷は A4 ライトテーマ）に変換する。「HTML 化して」「HTML 版を作って」「PDF にしたい」で起動。調査/設計/レポート md の配布・印刷用途に。素早く出すなら scripts/render-html.sh、リッチな card/box レイアウトが要るときは LLM 整形。
調査/レポート md を発表スライド (Marp) に昇華する。report.md を要約・分割して slides.md を作り、HTML/PDF/PPTX に書き出す。「スライドにして」「発表資料を作って」「Marp で」で起動。文書とスライドは編集距離があるため別ファイル (slides.md) として作る。
Markdown を「人が読みやすく、かつ機械が HTML/スライドへ変換しやすい」構造に執筆・整形する。新規に調査/設計 md を書くときや、既存 md を昇華 (md→HTML→slide) の前に整えるときに使う。「読みやすい md にして」「昇華しやすく整形して」「調査 md を書いて」で起動。
生成した HTML / スライドが「見た目 human friendly」か、ノンデザイナーズ・デザインブックの C.R.A.P. (Contrast/Repetition/Alignment/Proximity) + タイポグラフィで品質レビューする。「デザインを見て」「読みやすい見た目か」「レイアウトをレビュー」で起動。機械監査 (design-audit.sh) を先に走らせ、静的に測れない整列・近接・視覚的印象を補う。
[1] request を入力に [2] design issue を起票する ([1]→[2] のブレイクダウン)。元の [1] は close する。
status:ready の issue を claim する。遷移直前に ready を再確認してから in-progress へ atomic 遷移し、二重取得のレース窓を最小化する。issue を処理開始する直前に必ず使う。