create-issue-from-issue-number

name	create-issue-from-issue-number
description	Re-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the Explore-based analysis. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
argument-hint	[Issue番号]

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 でコード分析をやり直し、実装プラン・影響範囲・直近関連変更などを最新のコード状態に refresh する。コメントを取り込みたい場合は /update-issue を使う。

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

「依頼内容」の保持: 本スキルは Explore 再分析で 概要 要件 実装プラン などを最新のコード状態に合わせて書き換える（title もリフレッシュ対象になり得る）。このとき、元のIssueに人が書いた「原文の依頼」（＝実行前の title と description）が失われないよう、<details><summary>依頼内容</summary> の折りたたみブロックとして verbatim で残す（Issue を開いた直後に見えるべきは Explore 再分析結果で、原文はデフォルト非表示・展開可能が実用的なため）。すでに依頼内容ブロックが存在する Issue では、その中身を verbatim で再掲して次のリフレッシュに引き継ぐ（繰り返し実行されても初回の依頼原文＝ title と body の両方が固定される）。旧フォーマット（裸の ## 依頼内容 見出し）の場合も post-issue-body 側が読み込み時に折りたたみブロックへ詰め替えるため、本スキルは中身の抽出だけを担当する。

Instructions

実行モードの制約: サブエージェント・サブスキル・Bashをバックグラウンド実行しないこと

本スキルは claude-task-worker の create-issue ワーカー（cc-triage-scope ラベル）から自動起動される想定で、ワーカーはスキルプロセスの同期完了を根拠にラベル遷移（例: cc-issue-created 付与）を進める。本スキル内部で呼び出す Agent / Skill / Bash を絶対にバックグラウンド実行しないこと。

• Agent ツールは既定が run_in_background: true（バックグラウンド）。呼び出しごとに 必ず run_in_background: false を明示指定 し、フォアグラウンドで同期的に結果を受け取ってから次の処理に進む。指定を省略した場合はバックグラウンドで走り、本スキルが未完のまま終了する
• Skill に run_in_background: true を指定しない（既定は同期）。特に post-issue-body は投稿完了を受け取ってから次のフェーズに進む
• 同一メッセージ内で複数の Agent / Skill を並列に投げるのは「並列実行」であって「バックグラウンド実行」ではないため許容される（各サブエージェントの完了はその場で同期的に待つ）
• Bash にも run_in_background: true を指定しない。コマンド末尾に & を付けたり、nohup / disown / setsid でデタッチしたりしない
• ScheduleWakeup などで処理を後回しにしない

理由: バックグラウンド化すると子処理の完了前に本スキルが終了し、ワーカーが「正常完了」と誤認してラベル遷移を進める。description 更新前にラベルが遷移して triage 系スキルが古い状態で起動される、post-issue-body の投稿完了前に別ワーカーが動き出す、といった状態壊れを防ぐため、内部処理はすべて同期実行で完結させる。

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

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

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

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

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

引数が空の場合も中断する。

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

pwd を実行し、結果に応じて以下を判定する。worktreeを新たに作成しないこと。

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

0-3. デフォルトブランチの安全な同期（fail-safeにスキップ可）

以下を試行し、失敗しても中断せずスキップして続行する（本スキルはコード変更を伴わないため、最新化に失敗しても作業継続できる）。

git fetch --prune || true

git rebase や git pull は実行しない（未コミット変更や conflict による中断を避けるため）。

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

---

1. 既存Issueの取得

引数から抽出したIssue番号で対象Issueを取得し、現在の内容を確認する。

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

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

本文に画像URLがある場合、gh-asset でダウンロードして内容を読む。テキストだけでは伝わらない仕様（UIの見た目・エラー画面・図など）が分析の判断に必要なことがあるため、URLを見て終わりにせず、ダウンロードした画像を実際に Read で確認する。

gh-asset download <asset_id> ~/Downloads/

参考: https://github.com/YuitoSato/gh-asset

なお、変更ログの 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に旧フォーマットの ## 依頼内容 見出しがある場合（本フォーマット移行前の Issue）
   • ## 依頼内容 の見出し直後から次の ## 見出しまたはEOFの直前までを中身だけ verbatim で切り出し、それを「依頼内容」とする。折りたたみブロックへの詰め替えは post-issue-body 側が行うため、中身を渡すだけでよい。
3. どちらも存在しない場合（初回実行 or 完全な旧フォーマットの Issue）

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

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

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

抽出した文字列は改行を含めてそのまま保持し、ステップ4の args YAML に埋め込む際は YAML の複数行文字列（| ブロックスカラー）で渡す。

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

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

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

• docs/ 配下のドキュメントファイル: ls docs/ 2>/dev/null で存在確認した上で、タスクに関係しそうなファイルを読む
• design/ 配下の Pencil ファイル（.pen）: ls design/ 2>/dev/null で存在確認した上で、inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得して内容を確認する（.pen は暗号化バイナリのため Read/Grep は使わない）。.pen の編集が必要と判明した場合は本スキル内では編集せず、post-issue-body へ渡す「実装プラン」「確認事項」に「pencil-design-updater エージェントで <対象 .pen> を更新する」旨を明記して後続タスクへ委譲する

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

Explore サブエージェントを起動し、以下を取得する。スコープは「既存Issueの title/body に記述されている内容」を基準にする。

• 影響範囲となる主要ファイル・ディレクトリ（最大10件）
• 既存の類似実装の参照先（最大5件、ファイルパスと役割の1行説明）
• タスク達成に必要な変更の概略（フェーズ分け可能なら3段階以内）
• 不確実性・確認事項のリスト（推測で埋めず、Issueに残す前提）

サブエージェントへのプロンプトには「ユーザーには質問せず、調査結果を返却して終了する」ことと、上記の出力フォーマットを明示する。

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

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

• 対象ファイルごとに git log --oneline -10 <file> を実行し、直近 commit のサマリを把握する
• gh pr list --search "<file>" で未マージの関連 PR を確認する
• 直近 commit に大規模リファクタ・共通ヘルパー追加などの大きな変更が含まれる場合や、未マージの関連 PR がある場合は、その内容を post-issue-body に渡す「直近関連変更」セクション（必要に応じて「参照情報」にも）に必ず記載し、実装プランが既存実装と重複していないか検証する
• git 履歴のない新規機能要求など確認が困難なケースでは「該当なし」と記載してスキップしてよい

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

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>` — <説明>
    （ステップ2で読んだ参照、無ければ "なし"）
  直近関連変更: |
    - `<commit hash>` <subject> — <影響>
    （ステップ3で確認した結果、無ければ "該当なし"）
  実装プラン: |
    1. （再分析後の最新版）
  影響範囲: |
    - `<path>` — <概略>
new_changelog_entry: Explore再分析で実装プランと影響範囲を更新  # 再分析で変えた点を1行
confirmation_items:  # 0件ならキーごと省略
  - <ステップ3で抽出した未確認事項>

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

Skill tool 呼び出しは Skill(skill='post-issue-body', args=<上記YAML文字列>)（必要なら plugin namespace 付きで base-tools:post-issue-body）。args は改行を含む複数行文字列としてそのまま渡す。post-issue-body の責務範囲は以下のとおりで、本スキルから重複して実行しない。

• gh issue view --json body で既存本文を再取得して変更ログを verbatim で再掲
• 本文テンプレート・投稿前チェックリストに従って本文を組み立て・検証
• gh issue edit で更新
• 確認事項が渡されていればコメント投稿

完了後、Issue URL と確認事項コメントの有無が返ってくる。

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

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

以下を機械的に実行する（ユーザーへの確認は不要）:

1. gh issue view <issue_number> --json body -q .body で更新後の body を取得する。
2. 取得した body から依頼内容ブロックの中身を抽出する: <details><summary>依頼内容</summary> から </details> までのブロックを特定し、その内側（<summary> の閉じタグ直後から </details> の直前まで、先頭・末尾の空行1つは正規化してよい）を切り出す。本文中に <details> は依頼内容と変更ログの2つ存在し得るので、必ず <summary>依頼内容</summary> で識別してから切り出す。
3. ステップ1.5で確定した「依頼内容」文字列と、抽出した中身を比較する。
   • ステップ1.5で「依頼内容」が空だった場合 — 更新後bodyに <details><summary>依頼内容</summary> ブロックが存在しないこと（存在すれば異常）。
   • ステップ1.5で「依頼内容」が非空だった場合 — 抽出した中身が、渡した文字列と改行・空白まで含めて完全一致すること。前後の空行1つ程度の差は許容してよいが、内容の欠落・改変は不可。特に初回実行時は **元のタイトル**: <原文タイトル> の1行、空行、body本体がそのまま並んでいることを確認する（title 行の脱落は「原文が失われた」に相当する重大な逸脱なので必ず検出する）。
   • 書き出しが折りたたみブロックになっていること — 更新後bodyが旧フォーマットの裸の ## 依頼内容 見出しのままなら逸脱として扱う（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のフォールバック用途に限る）
• 途中でユーザーに質問しない。確認したいことは post-issue-body へ「確認事項」として渡し、コメントとして残す
• 依頼内容は必ず <details><summary>依頼内容</summary> の折りたたみで書き出す。裸の ## 依頼内容 見出しは使わない
• 依頼内容ブロックの中身は「原文の verbatim 保持」が目的なので、要約したり体裁を整えたりしない。Explore 再分析の結果は必ず 概要 要件 実装プラン 側に反映する
• 依頼内容ブロックには元の title も **元のタイトル**: <原文> 形式で先頭に含める（初回実行時に組み立て、以降は verbatim 再掲）。Issue の title 自体を書き換えても、ブロック内の元タイトル行は絶対に書き換えない（「人が最初に書いた依頼」の保存領域）
• Pencil ファイル（.pen）の読み込みは inspect-pencil-node スキル経由でのみ行う（暗号化バイナリのため Read/Grep は使えない）
• .pen の編集は本スキルでは絶対に行わない。必要と判明した場合は pencil-design-updater エージェントで対応する旨を post-issue-body 経由で「実装プラン」または「確認事項」に明記して後続タスクへ委譲する（.pen 編集は pencil-design-updater 専任・edit-pencil-design スキル経由の運用に集約されており、手で pencil コマンドを直接組み立てたり frontend-implementer/general-purpose-assistant 等で代用したりしない）
• 入力は既存の title/body のみ。コメント由来の更新は /update-issue の責務であり、本スキルでは取り込まない