Post Scope Issue Body

呼び出し元スキル（breakdown-issues）から委譲され、スコープIssue本文の整形と投稿を担う共有スキル。親スキルのタスク分解結果を受け取り、「スコープIssue」の正規フォーマットへの整形・投稿前チェック・gh issue create を一括実行する。

親スキル内のステップから Skill tool 経由で起動される想定。直接ユーザーから呼ばれ、入力 YAML が args に無い場合は、親スキル（breakdown-issues）の使用を促して終了する。

親Project紐付けや複数Issueの作成順序・依存関係Issue番号の確定は呼び出し側の責務。本スキルは1回の呼び出しで1つのIssueを作成して URL を返すのみ。複数作成したい場合は呼び出し側がループする。

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

入力（args 経由の YAML ブロック）

呼び出し規約

呼び出し元の親スキル（breakdown-issues）は、本スキル起動時の args に以下の YAML ブロックを文字列として渡すこと。本スキルは受け取った入力を YAML として機械的にパースして扱う。

mode: create  # 現状 create のみサポート
title: <Issueタイトル>
sections:
  概要: |
    （1-3行の概要）
  要件: |
    - 要件1
    - 要件2
  参照情報: |
    - ドキュメント: `<path>` — <説明>
    （無ければ "なし"）
  優先度: High  # High / Medium / Low のいずれか
  見積もり規模: M  # S / M / L / XL のいずれか
# 以下は GitHub ネイティブ relationships 用のオプション項目。
# 不要なら省略する（空配列や null を入れない＝そのまま書かない）。
parent: <親Issueの番号>           # 省略可。指定時は --parent で sub-issue として作成される
blocked_by: [<Issue番号>, ...]   # 省略可。指定時は --blocked-by で blocked-by relationship が貼られる
blocking: [<Issue番号>, ...]     # 省略可。指定時は --blocking で blocking relationship が貼られる

args に渡す YAML は上記の通りトップレベルから直接書く（ラッパキーなし）。

取り扱い規約

• 空セクションを省略しない。「なし」で埋める（後続スキルが「未記入」と区別できなくなるため）。
• parent / blocked_by / blocking の Issue 番号は呼び出し側で確定済みのものが前提。本スキルは渡された値をそのまま gh issue create のオプションに渡す。先行Issueの番号確定を待つ順序制御は呼び出し側の責務。
• 入力の YAML が壊れていたり項目が欠けている場合は、mode 以外であれば最低限の推定で埋める（例: 優先度・見積もり規模が空なら Medium / M）。mode だけは推定不可なので欠けていたら中断する。
• args から入力 YAML を取得できない場合（直接ユーザー起動など）は、親スキル（breakdown-issues）の使用を促して中断する。

Issueフォーマット（厳守）

このスキルが投稿するのは「コード分析前のスコープIssue」（ラベル cc-triage-scope）であり、本文は必ず以下の正規フォーマットに従う。後続の Issue ライフサイクルスキルは本文を読んでラベリング・タスク分解を行うため、セクションの過不足・順序の入れ替え・見出し名のゆらぎは後続スキルの判断と人のレビュー可読性を損なう。独自のアレンジは加えない。

依存関係は GitHub の relationships（blocked-by / blocking）と sub-issue 関係でネイティブに表現する方針のため、本文側に ## 依存関係 セクションは持たず、gh issue create の --parent / --blocked-by / --blocking オプションで貼る（GitHub UI で関係性が表示されるため本文での重複記述は不要、かつ二重管理によるズレを避けられる）。

本文テンプレート

## 概要
（このタスクが達成すべきゴールを1-3行で記述）

## 要件
- （機能要件・非機能要件を箇条書き。1項目1行）

## 参照情報
- ドキュメント: `<path>` — <関連箇所の説明>
- デザイン: `<path>` — <関連箇所の説明>
（該当する参照情報がなければ `- なし` の1行だけ書く）

## 優先度
High / Medium / Low のいずれか1つ

## 見積もり規模
S / M / L / XL のいずれか1つ

投稿前チェック（gh issue create 実行の直前に必ず確認）

本文を gh に渡す直前に以下を確認し、1つでも満たさない場合は本文を直してから実行する。

• 見出しが ## 概要 → ## 要件 → ## 参照情報 → ## 優先度 → ## 見積もり規模 の順で、過不足なく並んでいる
• テンプレート外の見出しを追加していない（特に ## 依存関係 は GitHub relationships に移行済みなので本文に書かない）
• 優先度・見積もり規模は規定の選択肢から1つだけ選んでいる
• 空になるセクションを省略せず「なし」で埋めている

実行ステップ

1. 入力 YAML の取得とパース

下記の args 入力スロットに呼び出し時の args が展開される。中身を YAML として解釈し、入力とする。

args 入力スロット:

<args-input> $ARGUMENTS </args-input>

確定した入力 YAML から mode / title / sections / parent / blocked_by / blocking を取り出す。mode が読み取れない、もしくは args から入力が得られないならば中断条件に従って終了する。

2. 本文の組み立てと投稿前チェック

「本文テンプレート」に従って本文を組み立て、必ず「投稿前チェック」の項目を1つずつ確認する。1つでも満たさない場合は本文を直してから次へ進む。

3. gh issue create で投稿

--body "..." 形式は使わない。本文中のバッククォート・$・!・改行でエスケープが頻繁に壊れるため、必ず --body-file - + heredoc（<<'EOF' でクォート、シェル展開を抑止）を使う。

YAML 入力に parent / blocked_by / blocking が含まれていれば、それぞれ --parent <番号> / --blocked-by <番号,番号,...> / --blocking <番号,番号,...> としてフラグに追加する。値が無い項目はフラグごと省略する（空文字列を渡すと gh が引数エラーで落ちるため、配列が空 / null の場合は組み立て時点で除外する）。--blocked-by / --blocking はカンマ区切りで複数番号を1つのフラグにまとめる。

GitHub MCP が使える場合はログインユーザー取得に get_me を使う。以下は MCP 利用不可時のフォールバック。

ME=$(gh api user --jq '.login')

# YAML 入力から組み立てた追加フラグを EXTRA_FLAGS 配列に詰める。
# 例: parent=42, blocked_by=[10,11] のとき EXTRA_FLAGS=(--parent 42 --blocked-by 10,11)
# 値が無い項目は何も push しない。
EXTRA_FLAGS=()
# [parent があるとき]     EXTRA_FLAGS+=(--parent "$PARENT_NUMBER")
# [blocked_by があるとき] EXTRA_FLAGS+=(--blocked-by "$(IFS=,; echo "${BLOCKED_BY[*]}")")
# [blocking があるとき]   EXTRA_FLAGS+=(--blocking "$(IFS=,; echo "${BLOCKING[*]}")")

NEW_ISSUE_URL=$(gh issue create \
  --title "<タイトル>" \
  --assignee "$ME" \
  --label "cc-triage-scope" \
  "${EXTRA_FLAGS[@]}" \
  --body-file - <<'EOF'
## 概要
...

## 要件
- ...

## 参照情報
- ...

## 優先度
...

## 見積もり規模
...
EOF
)

成功時、コマンドが標準出力に返す Issue URL を保持する。

--parent / --blocked-by / --blocking の検証エラー（存在しない Issue 番号、権限不足 等）はコマンドを非0で終わらせるが、Issue の作成自体は先に完了している（gh 2.98.0 実測: createIssue mutation → relationship 解決の順。以前ここに「その場合 Issue も作成されない」と書いていたのは誤り）。したがって失敗時は Issue が relationship なしで残る。失敗を呼び出し元に伝えて中断し、作成済みの Issue 番号も併せて報告する（呼び出し元が重複作成せずリンクだけ貼り直せるように）（後追いの best-effort リンクが必要な場合は、呼び出し元側で parent を渡さず作成し、別途 bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh add-sub-issue <親> <子> でリンクするフローを使うこと）。

本スキルはクラウドセッションでは成立しない。gh issue create は GraphQL の createIssue mutation を使い、--parent / --blocked-by / --blocking の解決も GraphQL 経由なので、クラウドの GraphQL ゲートで 403 になる（gh 2.98.0 で GH_DEBUG=api により確認。gh を新しくしても解決しない）。ただし唯一の呼び出し元である breakdown-issues は AskUserQuestion を使う対話専用スキルで、ワーカーから自動起動されることが無い（＝クラウド実行の対象外）ため、ローカルで1コマンドに収まる利点を捨ててまで2フェーズ化しない。呼び出し元が増えてクラウドで走るようになったら、post-issue-body と同じ「MCP の issue_write で作成 → gh-compat.sh でリンク」の2フェーズへ寄せること。

4. 呼び出し元への返却

以下を出力して、呼び出し元の親スキルが「最終報告」「親Project紐付け」「次のIssue作成」で使えるようにする（親Project紐付けや複数Issue作成のループは呼び出し側が続きを処理する）。

• 作成された Issue の URL
• 作成された Issue の番号（後続Issueの blocked_by 入力に使える）

中断条件

以下のいずれかに該当する場合のみ、理由を1-2行で出力して即中断する。

• mode が create 以外（現状 edit はサポートしない）
• args から入力 YAML を取得できない（空・YAML 解釈不能）
• gh issue create が失敗し、再試行しても解消しない

注意事項

• 本スキルはコードを一切変更しない。Issue の作成のみを行う
• cc-triage-scope ラベルは Issue ライフサイクル上の重要ラベル。本スキルは付与のみ行い、削除は一切行わない（呼び出し側でも gh issue edit --remove-label の対象に含めてはならない）
• このスキルを編集する際は、フォーマットの変更が breakdown-issues に効くことを意識する（このスキルが breakdown-issues の唯一の format source）