Create Issue From Issue Number

引数のIssue番号をもとに、対象Issueの既存 title/body を入力として再度コード分析を行い、description をリフレッシュするスキル。Instructionsの順に最後まで自律的に実行する。

自律実行原則: ユーザーへの確認は行わず、判断はすべて本スキル内のルールで自動決定する。確認したいことは最後にIssueへのコメントとして残す。中断条件に該当した場合のみ、理由を出力して終了する。

入力範囲: 引数は「Issue番号」のみ（数値のみ・#付き数値・Issue URL）。それ以外（自然言語のタスク説明など）は /create-issue を案内して終了する。

update-issue との違い: update-issue は対象Issueのコメント全件を入力として未反映事項を反映する。本スキルは既存の title/body そのものを入力として explore-agent でコード分析をやり直し、実装プラン・影響範囲・直近関連変更などを最新のコード状態に refresh する。コメントを取り込みたい場合は /update-issue を使う。

責務の分担: 本スキルは「既存Issue取得・タスク内容理解・コード再分析・元の依頼内容の保存と反映確認」までを担い、「本文整形・投稿前チェック・変更ログと依頼内容ブロックの verbatim 再掲・gh issue edit 実行」は post-issue-body スキルへ委譲する。本文テンプレート・変更ログ追記ルール・投稿前チェックリスト・heredoc 投稿コマンドは post-issue-body 側に集約されており、本スキル内では再記述しない。

「依頼内容」の保持: 再分析は 概要 要件 実装プラン を書き換える（title もリフレッシュ対象になり得る）ため、元のIssueに人が書いた「原文の依頼」（＝実行前の title と description）を <details><summary>依頼内容</summary> の折りたたみブロックとして verbatim で残す（Issueを開いた直後に見えるべきは再分析結果で、原文はデフォルト非表示・展開可能が実用的なため）。抽出・引き継ぎの詳細ロジックはステップ1.5（繰り返し実行されても初回の依頼原文＝title と body の両方が固定される）。

Instructions

GitHub アクセス

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

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の create-issue ワーカー（cc-triage-scope ラベル）から自動起動され、ワーカーはスキルプロセスの同期完了を根拠にラベル遷移（例: cc-issue-created 付与）を進める。処理が未完のままターンを終えると、description 更新前にラベルが遷移して triage 系スキルが古い状態で起動される、post-issue-body の投稿完了前に別ワーカーが動き出す、といった状態壊れが起きる。

生成する description のスコープと分量

description は人間がレビューし、後続の exec-issue が実装スコープとして読む成果物である。元の依頼にある要求を最新のコード状態へ翻訳するのが本スキルの仕事であり、要求を増やす場ではない。

• 依頼に無い要件・タスクを足さない: 再分析中に気づいた別の改善（周辺のリファクタ、テスト整備など）を要件や実装プランへ混ぜない。実装スコープが膨らみ、exec-issue が依頼外の変更を行う起点になる。書くとしても「確認事項」に1行で挙げるに留める
• 実装プランは3〜7ステップを目安に、各ステップ1〜2行で書く。コード断片の貼り付け・逐条の手順書化はしない（実装判断は exec-issue とサブエージェントの責務）
• 各セクションは内容がある分だけ書く: 「概要」は1〜3行、「影響範囲」は主要ファイル最大10件、「参照情報」「直近関連変更」は該当があるものだけ。埋めるための無内容な行・言い換えを書かない
• 確認事項は本当に判断できない点だけ: 本文の結論を裏付け直すだけの確認、Epic PR の未マージを理由にした確認（ステップ0-3参照）は起こさない。判定基準はステップ3の「確認事項の取捨選択」
• 最終報告は結論から1〜3行（詳細は「5. 最終報告」）

フェーズ0: 引数判定と事前チェック

0-1. 引数の妥当性確認

$0 が以下のいずれかに該当することを確認し、Issue番号を抽出する。判定は機械的に行う。

• 数値のみ（例: 123）
• #付き数値（例: #123）
• GitHubのIssue URL（.../issues/<番号>）

該当しない場合（自然言語のタスク説明など）は、「このスキルは既存Issueの再分析専用です。新規Issueを作成するには /create-issue <タスク内容> を使ってください」と出力して終了する。引数が空の場合も中断する。

0-2. 作業ディレクトリの確認

pwd を実行し判定する。worktreeを新たに作成しないこと。

• .claude/worktrees/ 配下にいる → そのworktree内で作業
• それ以外（リポジトリのルート等）→ その場で作業

0-3. リモート同期とベースブランチ（分析のターゲットブランチ）の確定

まずリモート同期を試行する。失敗しても中断せずスキップして続行する（本スキルはコード変更を伴わないため）。git rebase や git pull は実行しない（未コミット変更や conflict による中断を避けるため）。

次に分析の基準となるベースブランチ（BASE_BRANCH）を確定する。サブIssue（parent を持つIssue）の作業ブランチは cc-epic-<parent番号> から派生し、実装PRもそこへ向くため、デフォルトブランチではなく epic ブランチが分析のターゲットになる。デフォルトブランチをターゲットと見なすと、epic ブランチへマージ済みの兄弟サブIssueの変更が「未反映」に見え、「Epic PR が未マージだがどう扱うか」といった本来不要な検討事項・確認事項が混入する（exec-issue / create-pr のベースブランチ決定と同じ確定的導出を用いる）。

parent の取得は Issue Dependencies（sub-issue）系のフィールドであり、MCP 側の対応が不定のため gh に据え置く（対応表の「gh のまま残す操作」参照）。

git fetch --prune || true

BASE_BRANCH=""
PARENT=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh issue-parent "$0") || PARENT="__unresolved__"
if [ "${PARENT}" != "__unresolved__" ] && [ -n "${PARENT}" ] \
  && git rev-parse --verify --quiet "refs/remotes/origin/cc-epic-${PARENT}" >/dev/null; then
  BASE_BRANCH="cc-epic-${PARENT}"
fi

# parent が無い場合は upstream（ワーカーが worktree 作成時に --track で記録した分岐元）を使う
if [ -z "${BASE_BRANCH}" ]; then
  CURRENT=$(git rev-parse --abbrev-ref HEAD)
  UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' 2>/dev/null || true)
  UPSTREAM=${UPSTREAM#origin/}
  if [ -n "${UPSTREAM}" ] && [ "${UPSTREAM}" != "${CURRENT}" ] \
    && git rev-parse --verify --quiet "refs/remotes/origin/${UPSTREAM}" >/dev/null; then
    BASE_BRANCH="${UPSTREAM}"
  fi
fi

if [ -z "${BASE_BRANCH}" ]; then
  BASE_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
fi
echo "BASE_BRANCH=${BASE_BRANCH} PARENT=${PARENT}"

以降のすべてのステップ（ステップ2の参考情報収集・ステップ3のコード分析・確認事項の抽出）は BASE_BRANCH を分析のターゲットブランチとして扱う。

• 現在の作業ディレクトリのコード状態（＝BASE_BRANCH 由来）が分析対象。「この変更はデフォルトブランチにまだ入っていない」ことを問題として扱わない
• BASE_BRANCH が cc-epic-<N> の場合、Epic PR（cc-epic-<N> → デフォルトブランチ）が未マージであることは Epic フローの正常状態。これを根拠とした確認事項・リスク・検討事項（「先に Epic PR をマージすべきか」「マージされていないがどうするか」等）を一切生成しない
• epic ブランチへマージ済みの兄弟サブIssueの変更は「既に存在するコード」として扱い、実装プランで再実装しない
• parent の取得に失敗した場合（PARENT=__unresolved__）は parent 不明として続行するが、未マージPRを根拠とした確認事項は生成しない（epic フローの正常状態を誤って確認事項化しないための安全側の倒し方）。その旨は最終報告に1行残す

完了条件: Issue番号が確定し、作業ディレクトリと BASE_BRANCH が特定されていること。

---

1. 既存Issueの取得

引数から抽出したIssue番号で対象Issueを取得する。

GitHub MCP が使える場合は issue_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

gh issue view $0 --json number,title,state,labels,body,url

state が CLOSED の場合は更新せず、その旨を報告して終了する。

本文・コメントに画像や資料へのリンクがある場合は、リンク先を開いて内容を確認する（テキストだけでは伝わらない仕様 — UIの見た目・エラー画面・図など — が判断に必要なことがあるため、URLを見て終わりにしない）。手段は後述の「外部リンクの参照」に従う（一般URLは WebFetch、Google Drive はドライブ用の MCP、Figma は Figma MCP）。

画像は Issue へ直接添付せず、Drive 等へ上げたうえでリンクを貼る運用を前提とする。 GitHub の添付ファイル（user-images.githubusercontent.com / github.com/user-attachments/...）は認証付きの実体取得が必要で、クラウドセッションからは取得手段が無い。添付が直接貼られていて内容を読めない場合は、推測で補わず「添付 <URL> は取得不可（Issue への直接添付のため）。Drive 等へ上げ直してリンクを貼ってほしい」と報告に明記し、確認できた範囲で処理を続行する。

なお、変更ログの verbatim 再掲用の既存本文取得は post-issue-body が mode=edit で再度行うため、本ステップの body は分析用途で使い、post-issue-body へは Issue 番号だけを伝えればよい。

完了条件: 既存の title・body・labels が取得でき、state が OPEN であること。

1.5. 「依頼内容」の抽出と保持

ステップ1で取得した title と body から、次のリフレッシュにも引き継ぐ「依頼内容」（原文の title＋description）を確定させる。この内容をステップ4で post-issue-body の sections.依頼内容 にそのまま渡すと、本文の先頭に <details><summary>依頼内容</summary> の折りたたみブロックとして描画される。

判定ロジックは以下（機械的に判定する）:

1. 既存bodyに <details><summary>依頼内容</summary> ブロックが存在する場合（前回実行済み、新フォーマット）
   • <summary>依頼内容</summary> の閉じタグ直後から </details> の直前までを中身だけ verbatim で切り出し、「依頼内容」とする（タグ自体は含めない。post-issue-body 側で再付与される）。先頭・末尾の空行1つは正規化してよいが、内部の空白行はトリムしない（原文の保持を優先）。
   • このブロックには前回実行時の「タイトル」行と原文bodyの組が入っているため、そのまま再掲すれば初回の title が失われない。今回 title を書き換える場合でも、ブロック内の元タイトルは触らない。
2. 既存bodyに旧フォーマットの ## 依頼内容 見出しがある場合
   • 見出し直後から次の ## 見出しまたはEOFの直前までを中身だけ verbatim で切り出す。折りたたみブロックへの詰め替えは post-issue-body 側が行う。
3. どちらも存在しない場合（初回実行 or 完全な旧フォーマットの Issue）

   • 「元のタイトル」と「元のbody」の両方を verbatim で結合したものを「依頼内容」とする。フォーマットは次のとおり固定（次回抽出時に人が原文を判別しやすくするためと、post-issue-body の投稿前チェック（テンプレート外の ## 見出し禁止）に抵触させないため、## は使わず太字ラベルで表現する）:

     **元のタイトル**: <ステップ1で取得した title を verbatim>
     
     <ステップ1で取得した body（末尾の変更ログブロックがあれば除外）を verbatim>
     

     • title 行と body の間には必ず1行の空行を入れる（次回抽出時の「タイトル行 vs body 冒頭」の混同防止のため）。
     • body末尾の <details><summary>変更ログ</summary> ... </details> ブロックがある場合はそのブロックだけを除外する（変更ログは post-issue-body が別途 verbatim 再掲するため、二重掲載を防ぐ）。
     • body に他のセクション見出し（## 概要 等）が含まれていても構造には手を入れず、変更ログブロック以外はそのまま含める。初回のみセクションが重複し得るが、以降は 1 のパスに落ちて安定し、原文はデフォルト折りたたみで隠れる。
4. 抽出結果が空文字列になった場合（title が空文字で、かつ body も空 or 変更ログのみ、という極端なケース）— sections.依頼内容 は渡さない（post-issue-body は該当ブロックを本文から省略する）。

完了条件: 抽出済みの「依頼内容」文字列が確定していること（空でも可）。初回実行時は先頭行が **元のタイトル**: で始まり、その後に空行を挟んで原文bodyが続く形になっていること。

2. タスクの分析（参考情報の収集）

ステップ1で取得した既存の title/body をタスク説明として扱い、存在するもののみを読み込む。存在しないパスは黙ってスキップする。

• .claude/requirements/ 配下の要件ルール: 後述の「要件ルールの参照」に従って読み込む
• docs/ 配下のドキュメント: ls docs/ 2>/dev/null で存在確認した上で、タスクに関係しそうなファイルを読む
• design/ 配下の Pencil ファイル（.pen）: ls design/ 2>/dev/null で存在確認した上で、inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得して確認する。編集が必要と判明した場合の扱いは「注意事項」の .pen 規定に従う（本スキル内では編集しない）
• 既存Issueの title/body・上記ドキュメントに現れる外部リンク: 後述の「外部リンクの参照」に従って内容まで読む

外部リンクの参照（gh とローカルファイルで完結させない）

既存Issueの title/body・docs/・README・.claude/requirements/・コード内コメント・設定ファイルには、判断の根拠がリポジトリ外にあるリンク（仕様書・API仕様・ライブラリ公式ドキュメント・別リポジトリのIssue/PR・デザインURLなど）が置かれていることがある。gh とローカルファイルだけで調べて「不明」「確認事項」に倒すと、リンク先に答えが書いてあるのに人へ差し戻すことになる。リンク先の内容まで読んで結論を確定させる。

1. 収集: ステップ1で取得した Issue 本文（依頼内容ブロックの原文を含む）、ステップ2で読んだ範囲、ステップ3で explore-agent が返した対象ファイルに現れる URL を洗い出す
2. 取捨選択: 全部は開かない。今回の要件・実装プラン・確認事項の結論が変わりうるリンクだけを対象にする（バッジ画像・ライセンス・無関係な記事は開かない）
3. 取得: 種類ごとに手段を使い分ける
   • 一般のWebページ・仕様書・記事 → WebFetch
   • ライブラリ/フレームワークの公式ドキュメント → check-library スキル（Next.js / shadcn / context7 MCP を使い分ける）。バージョン差のあるAPI仕様を検索結果の要約で代用しない
   • GitHub上のIssue・PR → GitHub MCP が使える場合は issue_read / pull_request_read（method: get）を使う。利用不可なら gh issue view / gh pr view / gh api へフォールバック（GitHubのURLは WebFetch より確実）
   • GitHub上のファイル参照リンク（blob URL 等、別リポジトリ含む） → issue_read / pull_request_read はファイル内容を取得できないため使わない。GitHub MCP が使える場合は get_file_contents を使う。利用不可なら gh api repos/<owner>/<repo>/contents/<path> または WebFetch（raw URL）へフォールバック
   • Figma URL → Figma MCP（mcp__claude_ai_Figma__*）
   • Issue本文に貼られた画像・資料へのリンク → ステップ1のとおりリンク先を開いて内容を確認する
   • リンク切れ・URLが古い → WebSearch で現行の一次情報を探す（見つからなければ深追いしない）
4. 深さの上限: リンク先からさらに辿るのは1段まで。それ以上は追わず、必要なら確認事項に回す
5. 記録: 判断に使ったリンクは「参照情報」に <URL> — <参照した要点> の形で残す（後続の exec-issue / answer-issue-questions が同じ根拠を辿れるようにするため）
6. 取得失敗: 認証必須・404・タイムアウトは1回だけ再試行し、それでも読めなければ推測で埋めず「<URL> は取得不可（理由）」と参照情報に明記する。そのリンクでしか決まらない論点は確認事項に残す

要件ルールの参照

.claude/requirements/ には、過去のIssueで確定した仕様・要件レベルの判断ロジックが要件タイプ別に集約されている（update-requirement-rules スキルが生成・維持する）。再分析のたびに同じ判断をやり直して結論がブレたり、既に決着している論点を確認事項として人へ差し戻したりしないよう、再分析の前提として先に読む。

1. ls .claude/requirements/ 2>/dev/null で存在を確認する。無ければ黙ってスキップする
2. .claude/requirements/README.md（カテゴリ一覧）を読み、対象Issueに関係するカテゴリを選ぶ
3. 選んだカテゴリファイルだけを Read で読む（全ファイルを読まない。無関係なカテゴリは判断材料にならず、コンテキストを圧迫するだけ）

読み取った内容の使い方:

• 該当するルールがある論点は、ルールの結論を採用して description に反映し、確認事項として起こさない（ルールは既に人が決めた結論であり、再確認は着手を無駄に止める）
• ルールを判断根拠に使った場合は、「参照情報」に .claude/requirements/<file>.md の該当ルール名を1行添える
• Issue本文がルールと矛盾する場合はIssue本文を優先する。ルールは過去の一般解であり、このIssueで人が明示した方針を上書きしない。矛盾は確認事項にせず、description の該当箇所へ「本Issueでは〜のため既存ルール『〜』とは異なる扱いとする」と1行残す
• 本スキルは .claude/requirements/ を編集しない。ルールの追加・修正が要ると判明した場合もその旨を1行記すに留める（更新は update-requirement-rules の責務）

3. コードの分析（explore-agent サブエージェントを使用）

explore-agent サブエージェントを起動し、以下を取得する。スコープは「既存Issueの title/body に記述されている内容」を基準にする。サブエージェントへのプロンプトにはステップ0-3で確定した BASE_BRANCH をターゲットブランチとして明示し、「現在の作業ディレクトリのコード状態が基準であり、デフォルトブランチとの差分は論点にしない」ことを伝える。Agent ツールの effort は毎回指定する（explore-agent は定義に effort を持たない。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md）。影響範囲と類似実装の洗い出しは medium、Issue が複数モジュールにまたがる・呼び出し関係を複数段たどらないと影響範囲が決まらない場合は high。

• 影響範囲となる主要ファイル・ディレクトリ（最大10件）
• 既存の類似実装の参照先（最大5件、ファイルパスと役割の1行説明）
• タスク達成に必要な変更の概略（フェーズ分け可能なら3段階以内）
• E2Eテスト基盤の有無と所在（playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* 等の設定ファイル、e2e/ / tests/e2e/ / cypress/ 等のディレクトリ、package.json の test:e2e / e2e 系 scripts のいずれかが存在すれば「あり」と判定。関連する既存E2Eテストのパスも特定する）
• 不確実性・確認事項の候補リスト（推測で埋めない。ただしこのリストはそのまま Issue に載せず、後述の「確認事項の取捨選択」で絞り込む）

サブエージェントへのプロンプトには「ユーザーには質問せず、調査結果を返却して終了する」ことと、上記の出力フォーマットに加えて、対象コード・ドキュメント中に外部URLが現れ、それが結論を左右する場合は WebFetch 等でリンク先の内容まで確認し、URLと参照した要点を返すことを明示する。

確認事項の取捨選択（自明なものは載せない）

explore-agent が挙げた候補をそのまま confirmation_items へ流さない。確認事項コメントは人の回答待ち（cc-answer-issue-questions）を発生させ、調査で答えが出るものを混ぜると着手が無駄に止まる。投稿前に1件ずつ判定し、以下に該当するものは確認事項から外し、結論と根拠を description（要件・実装プラン・参照情報）側へ書く。

• コード・ドキュメント・git履歴・gh コマンドで調べれば一意に決まる（既存実装・既存パターン・設定値・命名規約から導ける）
• 本文・docs・コード中のリンク先（外部仕様書・ライブラリ公式ドキュメント・別リポジトリのIssue/PR など）を読めば一意に決まる — 「外部リンクの参照」に従って読みに行き、確認事項からは外す
• .claude/requirements/ の要件ルールが結論を与えている（過去に人が決着させた判断の再確認になる）
• 本文の結論を裏付け直すだけの確認（「〜という理解で合っているか」「〜の方針でよいか」）
• どちらを選んでも要求を満たす実装判断 — 既存実装に倣った安全側の既定を選び、選んだ理由を実装プランに1行書く
• BASE_BRANCH が cc-epic-<N> のときの Epic PR 未マージなど、フローの正常状態を根拠にした確認（ステップ0-3参照。そもそも生成しない）

残すのは「人の意思決定でしか決まらず、選択次第で成果物が変わる」項目だけ（仕様の分岐、スコープの線引き、外部要因の可否など）。判定に迷い、かつ調査で答えを出せるなら調べて確定させ、確認事項からは外す。

絞り込んだ結果0件なら confirmation_items をキーごと省略する（確認事項コメントは投稿されない）。

E2Eテストが存在し、かつIssueの内容がユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など）に影響する場合は、post-issue-body に渡す「実装プラン」に「該当フローのE2Eテストの追加・更新」ステップを含め、「影響範囲」に該当E2Eテストのパスを含める。E2Eテストが存在しない場合は、Issueが明示的に要求しない限りE2Eテスト基盤の新規導入をプランに含めない。

直近関連変更の確認（必須）

進行中・直近完了済みの関連作業を見落とし、既存実装と重複するゴーストタスクを含んだ Issue に更新しないため、explore-agent が特定した対象ファイル一覧について直近の commit 履歴と関連 PR を必ず確認する。

• 対象ファイルごとに git log --oneline -10 <file> を実行し、直近 commit のサマリを把握する

• 未マージの関連 PR は base が BASE_BRANCH のものだけを対象にする。base が異なる PR（BASE_BRANCH が epic ブランチのときの Epic PR 自身、他 epic 配下の PR など）は本Issueのマージ先に影響しないため除外する

  GitHub MCP が使える場合は list_pull_requests / search_pull_requests を使う。以下は MCP 利用不可時のフォールバック。

  gh pr list --search "<file>" --state open --json number,title,baseRefName,headRefName \
    --jq ".[] | select(.baseRefName == \"${BASE_BRANCH}\")"
  

• 直近 commit に大規模リファクタ・共通ヘルパー追加などの大きな変更が含まれる場合や、上記フィルタを通過した未マージ PR がある場合は、その内容を post-issue-body に渡す「直近関連変更」セクション（必要に応じて「参照情報」にも）に必ず記載し、実装プランが既存実装と重複していないか検証する

• 除外した PR（Epic PR 等）は「直近関連変更」にも「確認事項」にも書かない。Epic PR の未マージは Epic フローの正常状態であり、記載すると後続の answer-issue-questions / exec-issue が不要な検討事項として扱ってしまう

• git 履歴のない新規機能要求など確認が困難なケースでは「該当なし」と記載してスキップしてよい

完了条件: 上記5項目が揃い、対象ファイルの直近関連変更が把握できていること。揃わない場合でも追加調査せず、不足分は「不明」として次に進む。

参照デザインの特定（## UIデザイン セクションの要否）

依頼の時点で「どのデザインを参照して実装するか」が具体的に示されているUI変更タスクは、その参照を description の ## UIデザイン セクションとして残す。triage-created-issue のパターンE-1は、このセクションに .pen の実パス行があることだけを「デザイン確定済み」の根拠とし、無ければデザイン先行フロー（cc-create-ui-design）へ振り分けるため、確定しているのにここへ書かないと不要なデザインPRが1本挟まる。

書き出す条件（すべて満たす場合のみ）

1. 依頼本文（$ARGUMENTS / Issue本文 / 参照コメント）が、実装対象のデザインを具体的に指している（.pen のパス・デザインファイル名・デザインPR番号・「〇〇画面のデザインのとおり」など、対象を一意に特定できる記述）

2. 指されたデザインがリポジトリに実在する。git ls-files '*.pen' の出力と突き合わせて実パスを確定する

   git ls-files '*.pen'
   

3. 確定した実パスが < / > を含まない実在パスとして書ける（プレースホルダにならない）

満たす場合は、ステップの YAML に ui_design を含めて post-issue-body へ渡す（design_file は必須、スナップショット（snapshots/ 配下の対応PNG）とデザインPR番号は分かる場合のみ）。デザインの中身は inspect-pencil-node スキルで確認してよいが、.pen は編集しない。

書き出さない場合（ui_design ごと省略する）

• 依頼が「デザインを作って実装」「UIはいい感じに」などデザイン未確定
• 指されたデザインがリポジトリに見つからない（実パスを確定できない）。この場合は「参照情報」に「依頼が参照するデザイン <名称> はリポジトリに見つからなかった」旨を1行残す
• そもそもUIを変更しないタスク

省略すればトリアージがデザイン先行フローへ振り分けるため、推測でパスを書かない（誤ったパスを書くと、存在しないデザインを参照したまま実装へ進む）。

既存Issueの description に既に ## UIデザイン セクションがある場合（apply-ui-design が書き戻したデザイン参照など）は、post-issue-body が既存を verbatim 保持して ui_design で上書きしないため、合意済みの参照が壊れる心配はない。

4. post-issue-body スキルで Issue を更新

ステップ1〜3の分析結果を 以下の YAML ブロックの形でそのまま args として Skill tool で post-issue-body を起動する（post-issue-body は args を YAML として機械的にパースする規約）。

mode: edit
issue_number: <ステップ1で確定した番号>
title: <更新後タイトル — 変えない場合はステップ1で取得した既存タイトルを再掲>
sections:
  依頼内容: |
    <ステップ1.5で抽出した依頼内容（原文）を verbatim。抽出結果が空ならキーごと省略>
  概要: |
    （1-3行、再分析結果を反映）
  要件: |
    - ...
    （無ければ "なし"）
  参照情報: |
    - ドキュメント: `<path>` — <説明>
    - 外部: <URL> — <参照した要点>
    （ステップ2で読んだ参照・辿った外部リンク、無ければ "なし"）
  直近関連変更: |
    - `<commit hash>` <subject> — <影響>
    （ステップ3で確認した結果、無ければ "該当なし"）
  実装プラン: |
    1. （再分析後の最新版）
  影響範囲: |
    - `<path>` — <概略>
ui_design:  # 任意。「参照デザインの特定」で実パスまで確定できた場合のみ。確定できなければキーごと省略する
  design_file: <リポジトリに実在する `.pen` の実パス>
  snapshots:  # 任意。対応する snapshots/ 配下のPNGが分かる場合のみ
    - <PNG パス>
  design_pr: <デザインPR番号>  # 任意。分かる場合のみ
new_changelog_entry: explore-agent再分析で実装プランと影響範囲を更新  # 再分析で変えた点を1行
confirmation_items:  # 「確認事項の取捨選択」を通過した項目のみ。0件ならキーごと省略
  - <人の意思決定でしか決まらない未確認事項>

sections.依頼内容 にはステップ1.5で抽出した文字列をそのまま渡す。改行やインデントを含む場合は YAML の | ブロックスカラーで表現し、勝手に整形・要約しないこと（原文の verbatim 保持が目的）。

Skill tool 呼び出しは Skill(skill='post-issue-body', args=<上記YAML文字列>)（必要なら plugin namespace 付きで claude-task-worker:post-issue-body）。args は改行を含む複数行文字列としてそのまま渡す。post-issue-body の責務範囲（既存本文の再取得と変更ログの verbatim 再掲・テンプレートに沿った本文組み立てと投稿前チェック・gh issue edit・確認事項のコメント投稿）は本スキルから重複して実行しない。完了後、Issue URL と確認事項コメントの有無が返ってくる。

4.5. 「依頼内容」反映の事後検証

post-issue-body は本文全体を heredoc で上書きするため、整形ミスや YAML パース時の脱字で「依頼内容」が更新後のIssueに正しく載っていない可能性がある。原文が失われないよう、投稿完了直後に機械的に検証する:

1. gh issue view <issue_number> --json body -q .body で更新後の body を取得する（GitHub MCP が使える場合は issue_read（method: get）を使う。以下は MCP 利用不可時のフォールバック）。
2. body から <summary>依頼内容</summary> で識別した <details> ブロックの内側（<summary> の閉じタグ直後から </details> の直前まで、先頭・末尾の空行1つは正規化してよい）を切り出す。<details> は依頼内容と変更ログの2つ存在し得るので、必ず summary で識別する。
3. ステップ1.5で確定した「依頼内容」文字列と比較する。
   • ステップ1.5で「依頼内容」が空だった場合 — 更新後bodyに依頼内容ブロックが存在しないこと（存在すれば異常）。
   • 非空だった場合 — 抽出した中身が、渡した文字列と改行・空白まで含めて完全一致すること。前後の空行1つ程度の差は許容してよいが、内容の欠落・改変は不可。特に初回実行時は **元のタイトル**: <原文タイトル> の1行、空行、body本体がそのまま並んでいることを確認する（title 行の脱落は「原文が失われた」に相当する重大な逸脱なので必ず検出する）。
   • 折りたたみブロックで書き出されていること — 裸の ## 依頼内容 見出しのままなら逸脱として扱う（post-issue-body は必ず折りたたみで書き出す規約）。
4. 一致しない場合は次の順で復旧を試みる:
   • もう一度 post-issue-body を同じ args で呼び直す（一過性の投稿エラーの可能性）。
   • 再実行後も一致しない場合は、gh issue view --json body で取得した現在の body に対して「## 概要 の直前に <details>\n<summary>依頼内容</summary>\n\n<抽出した原文>\n\n</details>\n\n を差し込んだ本文」を組み立て、gh issue edit <issue_number> --body-file - <<'EOF' ... EOF で直接上書きする。既存bodyに旧フォーマットの ## 依頼内容 見出しや別の依頼内容ブロックが残っていれば、その部分は取り除いてから差し込む。
   • どちらでも解消しなければ、Issue URL と失敗理由を最終報告に含めて終了する（サイレント失敗させない）。
5. 検証が通れば、次のステップに進む。

完了条件: 更新後Issueの <details><summary>依頼内容</summary> ブロックの中身が、ステップ1.5で確定した原文と一致していること（または双方が空であること）。

5. 最終報告

post-issue-body から返ってきた Issue URL、確認事項コメントの有無、およびステップ4.5の依頼内容反映検証結果（一致 / 復旧して一致 / 未一致（要手動確認） のいずれか）を1-3行で報告して終了する。

---

中断条件

以下のいずれかに該当する場合のみ、理由を出力して即中断する。それ以外は自律的に判断して続行する。

• 引数が空、または Issue 番号として解釈できない（自然言語のタスク説明など）→ /create-issue を案内して終了
• gh issue view で対象 Issue が見つからない
• gh issue view の結果が CLOSED
• post-issue-body が失敗し、再試行しても解消しない
• ステップ4.5の依頼内容反映検証で、post-issue-body 再実行と直接 gh issue edit によるフォールバックの両方に失敗した場合 → Issue URL・失敗理由・想定される「依頼内容」原文を出力して終了（サイレントに終わらせない）

注意事項

• このスキルはコードを一切変更しない。Issue の更新・コメントは原則 post-issue-body 経由で行う（本スキル内で直接 gh issue edit を呼ぶのはステップ4.5のフォールバック用途に限る）
• 確認事項として渡すのは「確認事項の取捨選択」を通過した項目のみ（0件ならコメントは投稿しない）
• 依頼内容は必ず <details><summary>依頼内容</summary> の折りたたみで書き出す。裸の ## 依頼内容 見出しは使わない。中身は「原文の verbatim 保持」が目的なので、要約・整形しない。再分析の結果は必ず 概要 要件 実装プラン 側に反映する
• 依頼内容ブロック先頭の **元のタイトル**: <原文> 行は、Issue の title 自体を書き換えても絶対に書き換えない（「人が最初に書いた依頼」の保存領域）
• .pen の読み込みは inspect-pencil-node スキル経由のみ（暗号化バイナリのため Read/Grep は使えない）。編集は本スキルでは絶対に行わず、cc-create-ui-design のデザイン先行フロー（create-ui-design → デザインPRのマージ → apply-ui-design）で対応する旨を post-issue-body 経由で「実装プラン」に明記する。既に実在するデザインを参照して実装する依頼の場合は、「参照デザインの特定」に従って ui_design を渡し、description に ## UIデザイン セクションを残す（デザイン先行フローを挟まずに実装へ進める唯一の経路）。.pen の新規作成・編集は同フローの専任であり、実装PR（exec-issue）では行わないため、「実装と同じPRで .pen を更新する」「pencil-design-updater エージェントで更新する」といった実装セッション向けの指示は書かない
• 入力は既存の title/body のみ。コメント由来の更新は /update-issue の責務であり、本スキルでは取り込まない
• .claude/requirements/ の要件ルールは再分析の前提として読み込むが、編集はしない（「要件ルールの参照」参照）
• 結論を左右する外部リンクは「外部リンクの参照」に従って中身まで読み、使ったURLと要点を「参照情報」に残す
• 分析のターゲットブランチは常にステップ0-3で確定した BASE_BRANCH（ステップ0-3の3点規定に従う）