القائمة
Issue作成の規約を適用する。Issue作成、gh issue create 時に使用する。Issueタイトル（CCプレフィックスなし）、テンプレート選択、Epic時のラベル、CLI制約を含む。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | issue-conventions |
| description | Issue作成の規約を適用する。Issue作成、gh issue create 時に使用する。Issueタイトル（CCプレフィックスなし）、テンプレート選択、Epic時のラベル、CLI制約を含む。 |
--assignee @me で自分をアサインする (MUST)PR タイトル（Conventional Commits 形）と混同しないよう、次に揃える (MUST)。
feat: / fix: / chore: 等の CC 型プレフィックスは付けない（種別はラベル・テンプレート・本文で表す）。PR 作成時にエージェントが type を付与する[WIP] は使わない（必要なら本文で状態を書く）Issue から PR を作るときの対応: Issue タイトルは「何の作業か」が分かればよく、PR タイトルは pr-conventions の CC 形に 別途 整形する（Issue タイトルのコピペを PR タイトルにしない）。
会話で「Epic として作成」「親 Issue」「大項目の Issue」など、Epic 扱いで作成する指示がある場合:
Epic ラベルが存在するなら、gh issue create に --label Epic を付ける (MUST)gh label list（または gh api repos/:owner/:repo/labels）で Epic の有無を確認する。存在しない場合はラベル付与をスキップし、ユーザーにラベル未整備である旨を伝える（誤って gh が失敗しないようにする）epic, type:epic）に統一されている場合は、そのリポジトリの慣習を優先する.github/ISSUE_TEMPLATE/ が存在する場合、適切なテンプレートを選択する:
| テンプレート | 用途 |
|---|---|
bug_report.md | 動作不具合、実装ミス |
feature_request.md | 新機能追加・改修 |
other_task.md | 上記以外（技術的対応、基盤作業等） |
ls .github/ISSUE_TEMPLATE/ でテンプレート一覧確認cat で確認gh issue create --body-file で作成テンプレートが存在しない場合は、目的・作業内容を本文に記述する。
「サブ Issue」「子 Issue」「Epic のサブ」等の指示がある場合、GitHub ネイティブの sub-issue 機能を使う (MUST)。本文中の Refs #N やテキストテーブルだけでは親子関係は成立しない。
gh issue create で作成（通常どおり）gh api で親 Issue に紐づける:# 子 Issue の ID を取得
CHILD_ID=$(gh api repos/:owner/:repo/issues/<child_number> --jq '.id')
# 親 Issue に sub-issue として追加
gh api repos/:owner/:repo/issues/<parent_number>/sub_issues \
--method POST \
--field sub_issue_id="$CHILD_ID"
Refs #<parent> を本文に書くのは参照リンクとしては有用だが、ネイティブ sub-issue 関係は作らない--body に複数行のマークダウンを直接渡さない/tmp/issue_body.md）に書き出して --body-file を使用write ツールで作成するgh issue create --assignee @me --body-file /tmp/issue_body.md --title "ログインエラー時にメッセージを表示する"
# Epic 指示があり、ラベル Epic が存在する場合
gh issue create --assignee @me --body-file /tmp/issue_body.md --title "ログインエラー時にメッセージを表示する" --label Epic
# サブ Issue を親に紐づける
CHILD_ID=$(gh api repos/:owner/:repo/issues/76 --jq '.id')
gh api repos/:owner/:repo/issues/35/sub_issues --method POST --field sub_issue_id="$CHILD_ID"
親子 Claude Code セッション間の委譲操作を行う。delegate（子を起動してキック）、send（既存ペインへ1行/キックオフ送信・誤送信防止つき）、list（宛先確認）、report（子→親の申し送り）を自然言語の意図から判断して実行する。tmux 環境前提。
oe-* オーケストレーションツール群（engine 本体 / 親子委譲 / SO ゲート / 選択・観測）と駆動層規律の統合概観。複数エージェント委譲・設計SO/実装SO・read-only 観測・engine 1 サイクルを使うとき、ツール群の全体像をリポジトリ走査でなく一貫した形で把握したいときに使用する。
エラー/バグ調査で、入力→出力のコードパスに未読区間がある限り外部要因（インフラ差異等）の仮説に進まない。外部要因に飛ぼうとするとき、原因が再現しないと判断しそうなときに使用する。仮説を tmp/hypothesis-NNN.md に外部化し、コードパスの read-state を可視化する。
プランをKickoff Document形式に変換する。セカンドオピニオン投入・リポジトリアーカイブ・ピアレビュー共有時に使用する。命名規約・frontmatter・セクション構造をKickoff形式に整える。
設計判断を確定する前に、ゼロベースで未探索の代替案を最低1回引き出し、その証跡を確定前に残してから確定する。複数の選択肢を A/B 等で確定しかけたとき、ADR / Decision / kickoff の設計判断（DJ-N）を確定・記録するときに使用する。so-compare 選択肢拡張・探索木の外部化を含む。
so-compare.shでセカンドオピニオン（Codex/Claude/Cursor）を取得し、結果を比較する。ピアレビュー、修正方針の検証、設計判断の反証に使用する。**弱 SO**（1周可・partial=disclose・0はなし）。プロンプト設計原則、結果読み込み手順、合意判定基準を含む。