القائمة
reviewed ラベルがついたIssueを見つけて実装する。対象Issueに WIP ラベルをつけ、git worktree で main を汚さずに開発し、テストがPASSすることを確認した上でIssueに紐づくPR（Closes
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dev-issue-implement |
| description | reviewed ラベルがついたIssueを見つけて実装する。対象Issueに WIP ラベルをつけ、git worktree で main を汚さずに開発し、テストがPASSすることを確認した上でIssueに紐づくPR（Closes |
reviewed ラベルのついたIssueを worktree 上で実装し、テストPASSを確認してIssue紐づけPRを作成する。
引数がある場合: Issue番号 / URL を対象にする。ただし既に WIP がついている場合は別プロセスが実装中のため着手せず、その旨を報告して終了する。reviewed がついていない場合はその旨を伝え、続行するかユーザーに確認する。
引数がない場合:
# reviewed 付き・WIP なしのオープンIssue（古い順）
gh issue list --state open --label reviewed --json number,title,labels,body,createdAt \
--jq '[.[] | select((.labels | map(.name) | contains(["WIP"])) | not)] | sort_by(.createdAt)'
Depends on #N / Blocked by #N があり、その依存Issueが未クローズの場合はスキップして次を選ぶ他のセッション・エージェントとの二重着手を防ぐため、着手前に必ずつける:
gh label create WIP --color FBCA04 --description "実装作業中" 2>/dev/null || true
gh issue edit <number> --add-label WIP
main ブランチを汚さないため、必ず worktree で作業する:
git fetch origin
# ブランチ名は git-workflow と同じ規約: feat/ fix/ refactor/ chore/ docs/ test/
git worktree add ../<repo>-issue-<number> -b <type>/<short-description> origin/main
Issueの「設計・実装方針」「必要な修正箇所」に従って実装する:
<type>: <description>）で書く実装中に設計の根本的な問題が判明した場合: 実装を中断し、Issueにコメントで問題点を記載して WIP ラベルを外し、ユーザーに報告する。
リポジトリのテストコマンドを検出して実行する（package.json の scripts、Makefile、CI設定 .github/workflows/ から判定）:
# 例: プロジェクトに応じて
npm test / pnpm test / cargo test / pytest / go test ./...
git push -u origin <branch-name>
gh pr create \
--base main \
--title "<type>: <description>" \
--body "$(cat <<'EOF'
## Summary
<変更の要約>
Closes #<issue-number>
## Changes
<変更ファイルと内容の概要>
## Test Plan
- [x] <実行したテストと結果>
EOF
)"
Closes #<issue-number> を入れてIssueと紐づける（マージ時に自動クローズされる）.github/pull_request_template.md 等）があればそれに従い、Closes #N を追加するgit worktree remove ../<repo>-issue-<number>
WIP がついているIssueには着手しない（引数で明示指定された場合も同様）。中断・失敗時は WIP ラベルを外してからユーザーに報告するCloses #<issue-number> を含めるgit push --force は使用しないdev系パイプライン（dev-pr-review / dev-pr-review-resolve / dev-issue-implement / dev-issue-review）を人間の確認なしで自律的に1タスク回すオーケストレーター。main を最新化した後、レビュー系を優先する固定順で対象を探し、最初に見つかった1件を対応するスキルで処理する。途中で解決済みIssueを見つけたら理由を書いてcloseする。needs-info によるユーザー確認待ちは禁止で、必ず自律判断する。ユーザーが「devパイプライン回して」「自律で開発回して」と言ったとき、または /dev-hotl を実行したときに使用。
現在のリポジトリの開発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` と言われたときに使用。
引数や会話の文脈中のトピック（機能要望・バグ・改善案・設計課題）をもとに、gh CLI で現在のリポジトリに開発Issueを作成する。mainを最新化した上でコードベースを調査し、設計・実現可能性・必要な修正箇所・テスト観点を構造化して記述する。工数は記述しない。トピックが大きすぎる場合は適切な粒度に分割して複数Issueを作成する。ユーザーが「Issue作って」「イシュー化して」「課題登録して」と言ったとき、または /dev-issue-create を実行したときに使用。