メニュー
引数や会話の文脈中のトピック（機能要望・バグ・改善案・設計課題）をもとに、gh CLI で現在のリポジトリに開発Issueを作成する。mainを最新化した上でコードベースを調査し、設計・実現可能性・必要な修正箇所・テスト観点を構造化して記述する。工数は記述しない。トピックが大きすぎる場合は適切な粒度に分割して複数Issueを作成する。ユーザーが「Issue作って」「イシュー化して」「課題登録して」と言ったとき、または /dev-issue-create を実行したときに使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
dev系パイプライン（dev-pr-review / dev-pr-review-resolve / dev-issue-implement / dev-issue-review）を人間の確認なしで自律的に1タスク回すオーケストレーター。main を最新化した後、レビュー系を優先する固定順で対象を探し、最初に見つかった1件を対応するスキルで処理する。途中で解決済みIssueを見つけたら理由を書いてcloseする。needs-info によるユーザー確認待ちは禁止で、必ず自律判断する。ユーザーが「devパイプライン回して」「自律で開発回して」と言ったとき、または /dev-hotl を実行したときに使用。
reviewed ラベルがついたIssueを見つけて実装する。対象Issueに WIP ラベルをつけ、git worktree で main を汚さずに開発し、テストがPASSすることを確認した上でIssueに紐づくPR（Closes
現在のリポジトリの開発Issueが妥当かどうかをレビューする。リポジトリの目的に沿っているか、調査内容・設計に問題がないかをチェックし、WebSearch や Parallel Search MCP で裏取りして本文を追記・修正する。レビュー着手時に in-review ラベルで排他し、問題なければ reviewed ラベルをつけ、あまりに見当違いな場合は理由を記述してcloseする。Issue番号・URLを引数に取るか、未レビューのIssueを自動で探す。ユーザーが「Issueレビュー」「Issueの妥当性チェック」と言ったとき、または /dev-issue-review を実行したときに使用。
reviewed ラベルがついたPRを見つけて、レビュー指摘事項を検討・修正する。着手時に in-review ラベルで排他する。妥当な指摘は worktree 上で修正し、反論がある場合は根拠をコメントに記述して、各レビュースレッドをresolveしていく。すべてのレビューをresolveしたら必ずmergeする。PR番号・URLを引数に取るか、対応待ちのPRを自動で探す。ユーザーが「レビュー指摘を解消して」「reviewedのPRを片付けて」と言ったとき、または /dev-pr-review-resolve を実行したときに使用。
in-review ラベルがついていないオープンPRを見つけてレビューする。git worktree でPRのコードをローカルに取得し、変更箇所以外との整合性・紐づくIssue通りの実装かを確認する。問題なければmerge、軽微な指摘なら修正してmerge、問題が多い場合はレビューを記述して reviewed ラベルをつけ、見当違い・修正済みのPRは理由を記述してcloseする。PR番号・URLを引数に取るか、レビュー待ちのPRを自動で探す。ユーザーが「PRレビューして回して」「レビュー待ちPRを処理して」と言ったとき、または /dev-pr-review を実行したときに使用。
ローカルにインストール済みの Codex CLI (OpenAI) を使って、別 LLM からのコードレビュー・セカンドオピニオン・意見交換を取得する。Claude が書いたコードに対して「別モデルの目」を入れたいとき、設計判断で複数モデルの見解を突き合わせたいとき、`codex` / `/codex` と言われたときに使用。
| name | dev-issue-create |
| description | 引数や会話の文脈中のトピック（機能要望・バグ・改善案・設計課題）をもとに、gh CLI で現在のリポジトリに開発Issueを作成する。mainを最新化した上でコードベースを調査し、設計・実現可能性・必要な修正箇所・テスト観点を構造化して記述する。工数は記述しない。トピックが大きすぎる場合は適切な粒度に分割して複数Issueを作成する。ユーザーが「Issue作って」「イシュー化して」「課題登録して」と言ったとき、または /dev-issue-create を実行したときに使用。 |
引数または会話の文脈からトピックを特定し、現行コードベースに基づく調査・設計・実現可能性・テスト観点を記述した開発Issueを gh で作成する。
以下を並列で実行してコンテキストを収集する:
# リポジトリの確認
gh repo view --json nameWithOwner,hasIssuesEnabled
# 利用可能なラベル
gh label list --limit 50
# Issueテンプレートの検索
ls .github/ISSUE_TEMPLATE/ 2>/dev/null
# リモートの最新を取得
git fetch origin
mainの最新化:
git pull --ff-onlygit fetch origin のみ行い、調査は origin/main の内容（git show origin/main:<path> / git diff HEAD origin/main --stat）を基準にする。ローカルの状態は変更しない中断条件:
トピックからIssueの種別を判定する:
| 種別 | 判定基準 | ラベル候補 |
|---|---|---|
| feature | 新機能・機能追加の要望 | enhancement |
| bug | 不具合・期待と異なる動作 | bug |
| refactor | 内部構造の改善・技術的負債 | refactoring, tech-debt |
| design | 設計判断・アーキテクチャ検討 | design, discussion |
| docs | ドキュメント整備 | documentation |
コードベース調査（最新のmainに対して）: Grep / Glob / Read で以下を必ず把握する:
憶測でファイルパスや実装方針を書かず、実際に確認した内容のみ記載する。
重複チェック:
gh issue list --search "<キーワード>" --state all --limit 10
類似Issueが見つかった場合はユーザーに提示し、新規作成するか既存に追記するか確認する。
以下のいずれかに該当する場合、複数Issueへの分割を検討する:
分割の原則:
Depends on #<number> / Blocked by #<number> を明記分割する場合はIssue作成前に分割案をユーザーに提示して確認する。分割不要なら確認せず進む。
Issueテンプレートがあればその構造に従う。なければ種別に応じたデフォルト形式を使用する。
共通ルール: 工数・所要時間・難易度の見積もりは一切記述しない。
## 概要
<何を実現したいか、なぜ必要かを1〜3段落で>
## 背景・課題
<現状の問題点、このIssueが生まれた文脈>
## 調査結果
<現行コードベース（main最新）の関連実装の状況。`path/to/file.ts` の `functionName()` 形式で具体的に>
## 設計・実装方針
<調査に基づく実装アプローチ>
## 必要な修正箇所
- `path/to/file.ts` — <どんな変更が必要か>
- <新規作成が必要なファイルがあればそれも>
## 実現可能性
<現アーキテクチャで実現可能か。制約・リスク・技術的な懸念点。代替案があれば記載>
## テスト観点
- [ ] <ユニットテスト: 対象関数と主要ケース>
- [ ] <統合/E2Eテスト: 必要な場合>
- [ ] <エッジケース・エラーパス>
## 受け入れ条件
- [ ] <完了と判断できる具体的な条件>
## 概要
<どんな不具合か1〜2文で>
## 再現手順
1. <手順>
## 期待する動作 / 実際の動作
- 期待: <期待する動作>
- 実際: <実際の動作>
## 原因調査
<コード調査でわかった原因・怪しい箇所。`path/to/file.ts:123` 形式で記載>
## 修正方針と必要な修正箇所
- `path/to/file.ts` — <修正内容>
## テスト観点
- [ ] 再現ケースの再発防止テスト
- [ ] <周辺のエッジケース>
## 受け入れ条件
- [ ] <修正確認の条件>
タイトルのルール: conventional commit 形式 <type>: <description>、70文字以内。
ラベルが未作成の場合は先に作成する（Step 1 の gh label list の結果で判定）:
# 例: 種別ラベルが存在しない場合は作成してから付与する
gh label create enhancement --color A2EEEF --description "新機能・機能追加" 2>/dev/null || true
gh label create bug --color D73A4A --description "不具合" 2>/dev/null || true
gh label create refactoring --color E4E669 --description "内部構造の改善" 2>/dev/null || true
gh label create design --color C5DEF5 --description "設計判断・アーキテクチャ検討" 2>/dev/null || true
gh label create documentation --color 0075CA --description "ドキュメント整備" 2>/dev/null || true
作成するのは実際に付与するラベルのみでよい（全種を毎回作る必要はない）。
gh issue create \
--title "<title>" \
--label "<label>" \
--body "$(cat <<'EOF'
<body>
EOF
)"
gh label create してから --label に指定するDepends on #N を記載- [ ] #N）に反映作成した全IssueのURLと、分割した場合は依存関係の概要を提示する。
Issueのタイトル・本文は、明示的な指定がない限りリポジトリの主要言語（既存Issue・コミット履歴・READMEから判定）に従う。
gh label create で作成してから付与する（存在しないラベルを --label に指定するとエラーになる）