| name | create-issue |
| description | @issue_note.txt の課題No、または Evernote 共有リンク（ノート下書き）をもとに、GitHub Issueを作成する。対応種別に応じてfeature/bugfixテンプレートを使い分ける。 |
GitHub Issue 作成フロー
このスキルの目的は GitHub Issue を新規作成すること。 設計ドキュメントの更新・同期は一切行わない（それは sync-docs スキルの役割）。本スキルで設計ドキュメントに触れるのは、Issue 本文の項目を埋めるための「読み取り専用の参照」に限る。
引数: $ARGUMENTS（次の2形態のいずれか）
- 課題No（例:
ISSUE-001）: issue_note.txt の該当セクションを入力ソースにする（従来どおり）
- Evernote 共有リンク（例:
https://share.evernote.com/note/<GUID>）または ノート GUID: そのノート本文を入力ソースにする
Phase 1: 入力ソースの判別と取得
引数の形式を先に判別し、入力ソースを決める。
- 引数が
ISSUE- で始まる → 課題No経路（Phase 1-A）
- 引数が
share.evernote.com/note/... を含む共有 URL、または GUID 形式（^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$）→ Evernote 経路（Phase 1-B）
Phase 1-A: 課題No経路（issue_note.txt）
@issue_note.txt を読み込む- 引数で受け取った課題No（
$ARGUMENTS）に一致するセクションを探す
- 該当する課題が見つからない場合はエラーメッセージを表示して終了する
Phase 1-B: Evernote 経路（共有リンク / GUID）
- 引数からノート GUID を取り出す
- 共有 URL（
https://share.evernote.com/note/<GUID>）の場合は末尾の <GUID> 部分を抽出する
- GUID が直接渡された場合はそのまま使う
- Evernote MCP の
get_note（引数 noteId=<GUID>）でノートのタイトル・本文（ENML）を取得する
- 取得に失敗した場合（GUID 不正・アクセス不可など）はエラーメッセージを表示して終了する
- この経路では
issue_note.txt は参照しない（入力ソースはノート本文）
WebFetch は使わない: Evernote 共有リンクは accounts.evernote.com の認証リダイレクトに飛ぶため、WebFetch では本文を取得できない。ノート本文の取得は必ず Evernote MCP の get_note を使う。
Phase 2: テンプレートの選定（経路共通）
Phase 1 でどちらの経路（課題No / Evernote）を通ったかに関わらず、以降の Phase 2〜4 は共通の手順で進める。
課題の「対応種別」に応じて使用するテンプレートを決定する。
| 対応種別 | テンプレート |
|---|
| 機能追加 | .github/ISSUE_TEMPLATE/feature.md |
| レイアウト変更 | .github/ISSUE_TEMPLATE/feature.md |
| アーキテクチャ変更 | .github/ISSUE_TEMPLATE/feature.md |
| バグ修正 | .github/ISSUE_TEMPLATE/bugfix.md |
- 課題No経路では、
issue_note.txt のセクションに記載された「対応種別」を使う。
- Evernote 経路では、ノート本文から対応種別を読み取る。本文から対応種別が判別できない場合は推測で決めず、ユーザーに確認する（推測補完は禁止。禁止事項を参照）。
Phase 3: Issue本文の作成
入力ソースが「課題No のセクション」か「Evernote ノート本文」かに関わらず、下記の各テンプレート項目マッピングは共通で使う（「課題の〜」と書かれた箇所は、Evernote 経路ではノート本文の該当内容と読み替える）。
feature テンプレートの場合
Issue 本文の各項目を埋めるための材料として、設計ドキュメント（routing.md, wireframe.md, database.md, README.md）を読み取り専用で参照する（ドキュメント側は変更しない）。課題情報をテンプレートの各セクションに転記する。
- 概要: 課題の「課題」「なぜそれをやるのか？」を要約
- 対象画面 / ルーティング: 課題の「対象システム」「対象ページ」から特定し、routing.md と照合
- 仕様（ユーザー視点）: 課題の「期待する状態」をもとに記載
- データ要件: 課題の「前提条件」や database.md から関連テーブルを特定
- UI 要件: wireframe.md から対象ページのUI仕様を参照して記載
- 振る舞い・ロジック: 課題内容から想定される動作を記載
- 受入条件: 課題の「受入条件」をPlaywrightで検証可能な形に変換
- 未確定事項 / 確認事項: 課題の「やらないこと」や不明点を記載
- 補足: その他の制約・注意点を記載
bugfix テンプレートの場合
- バグ概要: 課題の「課題」を記載
- 発生箇所: 課題の「対象ページ」「対象機能」から特定
- 再現手順: 課題内容から再現手順を推定して記載
- 期待した結果: 課題の「期待する状態」を記載
- 実際の結果: 課題の「課題」から現状を記載
- 受入条件: 課題の「受入条件」をPlaywrightで検証可能な形に変換
Phase 4: Issue作成（ユーザー承認必須）
- 作成するIssue本文をユーザーに提示する
- ユーザーが「OK」と回答するまで Issue を作成してはならない
- OK後、
gh issue create コマンドでIssueを作成する
gh issue create --title "Issue タイトル" --body "$(cat <<'EOF'
Issue 本文
EOF
)"
- 作成されたIssue URLを報告する
Phase 5: セッション名の提示（Issue作成成功後）
Issue作成に成功したら、報告の最後に /rename コマンドを単独の1行で提示する。
ユーザーはこの1行をそのままコピペして実行することで、claude --resume のピッカーで「どのIssueの作業をしていたセッションか」を一目で判別できる。
- 形式:
/rename #<Issue番号> <Issueタイトル>
- 例:
/rename #261 店舗検索のビールカテゴリ複数選択対応
- タイトルが長い場合は要点を30字程度に短縮してよい（元のIssueタイトルそのままでも可）
- コードブロックで囲まず、コピペしやすいよう独立した1行のプレーンテキストで提示する
- このコマンドはユーザーが対話セッションで実行するものであり、本スキル（サブエージェント）側では実行しない／実行できない
禁止事項
- ユーザー承認なしでIssueを作成すること
- @issue_note.txt に存在しない課題Noで作成を試みること
- テンプレートの構造を無視してIssue本文を作成すること
- 課題情報を推測で補完すること（不明点は「未確定事項」に記載する）。Evernote 経路で本文から「対応種別」が判別できない場合も推測で決めず、ユーザーに確認すること
- Evernote 共有リンクの本文取得を
WebFetch で試みること（認証リダイレクトで取得できない。必ず Evernote MCP の get_note を使う）
- 設計ドキュメント（routing.md / wireframe.md / database.md / README.md）を更新・同期すること（本スキルは参照のみ。同期は sync-docs の役割）
