メニュー
@issue_note.txt の課題No、または Evernote 共有リンク（ノート下書き）をもとに、GitHub Issueを作成する。対応種別に応じてfeature/bugfixテンプレートを使い分ける。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-issue |
| description | @issue_note.txt の課題No、または Evernote 共有リンク（ノート下書き）をもとに、GitHub Issueを作成する。対応種別に応じてfeature/bugfixテンプレートを使い分ける。 |
このスキルの目的は GitHub Issue を新規作成すること。 設計ドキュメントの更新・同期は一切行わない（それは sync-docs スキルの役割）。本スキルで設計ドキュメントに触れるのは、Issue 本文の項目を埋めるための「読み取り専用の参照」に限る。
引数: $ARGUMENTS（次の2形態のいずれか）
ISSUE-001）: issue_note.txt の該当セクションを入力ソースにする（従来どおり）https://share.evernote.com/note/<GUID>）または ノート GUID: そのノート本文を入力ソースにする引数の形式を先に判別し、入力ソースを決める。
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）issue_note.txt）@issue_note.txt を読み込む$ARGUMENTS）に一致するセクションを探すhttps://share.evernote.com/note/<GUID>）の場合は末尾の <GUID> 部分を抽出するget_note（引数 noteId=<GUID>）でノートのタイトル・本文（ENML）を取得するissue_note.txt は参照しない（入力ソースはノート本文）
WebFetchは使わない: Evernote 共有リンクはaccounts.evernote.comの認証リダイレクトに飛ぶため、WebFetchでは本文を取得できない。ノート本文の取得は必ず Evernote MCP のget_noteを使う。
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 |
issue_note.txt のセクションに記載された「対応種別」を使う。入力ソースが「課題No のセクション」か「Evernote ノート本文」かに関わらず、下記の各テンプレート項目マッピングは共通で使う（「課題の〜」と書かれた箇所は、Evernote 経路ではノート本文の該当内容と読み替える）。
Issue 本文の各項目を埋めるための材料として、設計ドキュメント（routing.md, wireframe.md, database.md, README.md）を読み取り専用で参照する（ドキュメント側は変更しない）。課題情報をテンプレートの各セクションに転記する。
gh issue create コマンドでIssueを作成するgh issue create --title "Issue タイトル" --body "$(cat <<'EOF'
Issue 本文
EOF
)"
Issue作成に成功したら、報告の最後に /rename コマンドを単独の1行で提示する。
ユーザーはこの1行をそのままコピペして実行することで、claude --resume のピッカーで「どのIssueの作業をしていたセッションか」を一目で判別できる。
/rename #<Issue番号> <Issueタイトル>
/rename #261 店舗検索のビールカテゴリ複数選択対応WebFetch で試みること（認証リダイレクトで取得できない。必ず Evernote MCP の get_note を使う）PRをMerge commit方式でマージし、リモート・ローカル両方のfeatureブランチを削除して司令塔ベースブランチを最新化する。マージのタイミングはユーザーが決める。
Issue起点の実装計画を作成する。Issueの内容とプロジェクトの設計ドキュメントを照合し、影響範囲・実装方針・テスト方針を含む計画を出力する。
Playwright MCPを使って、既に起動済みのlocalhost環境に対してE2E観点の動作確認を行うための運用ルール。
PRのコードレビューを実施し、レビュー結果をPRコメントとして投稿する。アーキテクチャ観点でのコードレビュー。
ブランチ・Git運用ルール。feature ブランチ作成、コミット、プッシュ、PR作成の手順。品質チェック後のGit操作フロー。
ready ラベル付き Issue を古い順に1件ずつ直列で消化する半自動ループ。各Issueを /impl の手順で実装し、品質ゲート（pr-review が Low 以下 + E2E green + CI green）を満たせば /merge 相当で自動マージする。条件を満たさないものは needs-merge / blocked で人に戻す。実装ロジック本体は /impl が持つ。