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 code analysis via the explore-agent subagent. 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番号]
hooks	{"Stop":[{"matcher":"","hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/scripts/stop-servers.mjs\""}]}]}

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 再掲・依頼内容折りたたみブロックの verbatim 再掲・gh issue edit 実行」は post-issue-body スキルへ委譲する。本文テンプレート・変更ログ追記ルール・投稿前チェックリスト・heredoc 投稿コマンドはすべて post-issue-body 側に集約されているため、本スキル内では再記述しない。

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

Instructions

実行モードの制約

本スキル固有のリスク: 本スキルは 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 のベースブランチ決定と同じ確定的導出を用いる）。

git fetch --prune || true

BASE_BRANCH=""
PARENT=$(gh issue view "$0" --json parent --jq '.parent.number // empty') || 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の変更は「既に存在するコード」として扱い、実装プランで再実装しない
• gh issue view --json parent に失敗した場合（PARENT=__unresolved__）は parent 不明として続行するが、未マージPRを根拠とした確認事項は生成しない（epic フローの正常状態を誤って確認事項化しないための安全側の倒し方）。その旨は最終報告に1行残す

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

---

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-agent サブエージェントを使用）

explore-agent サブエージェントを起動し、以下を取得する。スコープは「既存Issueの title/body に記述されている内容」を基準にする。サブエージェントへのプロンプトにはステップ0-3で確定した BASE_BRANCH をターゲットブランチとして明示し、「現在の作業ディレクトリのコード状態が基準であり、デフォルトブランチとの差分は論点にしない」ことを伝える。

• 影響範囲となる主要ファイル・ディレクトリ（最大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 に載せず、後述の「確認事項の取捨選択」で絞り込む）

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

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

explore-agent が挙げた候補をそのまま confirmation_items へ流さない。確認事項コメントは人の回答待ち（cc-answer-issue-questions）を発生させるため、調査で答えが出るものを混ぜると着手が無駄に止まる。

投稿前に1件ずつ判定し、以下に該当するものは確認事項から外す。外した項目は、結論と根拠を description（要件・実装プラン・参照情報）側へ書く。

• コード・ドキュメント・git履歴・gh コマンドで調べれば一意に決まる（既存実装・既存パターン・設定値・命名規約から導ける）
• 本文の結論を裏付け直すだけの確認（「〜という理解で合っているか」「〜の方針でよいか」）
• どちらを選んでも要求を満たす実装判断 — 既存実装に倣った安全側の既定を選び、選んだ理由を実装プランに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のマージ先に影響しないため除外する

  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項目が揃い、対象ファイルの直近関連変更が把握できていること。揃わない場合でも追加調査せず、不足分は「不明」として次に進む。

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-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 の責務範囲は以下のとおりで、本スキルから重複して実行しない。

• 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 へ「確認事項」として渡し、コメントとして残す。ただし渡すのは「確認事項の取捨選択」を通過した項目だけで、調査で自明に決まる点は確認事項にせず description 側へ結論を書く（0件ならコメントは投稿しない）
• 依頼内容は必ず <details><summary>依頼内容</summary> の折りたたみで書き出す。裸の ## 依頼内容 見出しは使わない
• 依頼内容ブロックの中身は「原文の verbatim 保持」が目的なので、要約したり体裁を整えたりしない。explore-agent 再分析の結果は必ず 概要 要件 実装プラン 側に反映する
• 依頼内容ブロックには元の 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 の責務であり、本スキルでは取り込まない
• 分析のターゲットブランチは常にステップ0-3で確定した BASE_BRANCH。サブIssueでデフォルトブランチをターゲットに据えると、epic ブランチへマージ済みの兄弟サブIssueの成果物を見落とすうえ、「Epic PR が未マージだがどうするか」という本来不要な検討事項が description・確認事項に混入する