Menü
GitHub issue から計画・実装・テスト・レビュー・PR テキスト・理解確認まで一気通貫で行う。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Codex CLI にコードレビューを依頼する。PR が存在する場合は PR を、ローカルブランチの場合はメインブランチとの差分をレビューする。
GitHub issue から PR のタイトルと説明文を作成する。
GitHub issue と実装計画をもとにコードを実装する。計画からの逸脱は implementation-notes.md に記録しながら進める。
research の結果と受け入れ条件をもとに、実装方法を選択し TDD ベースの実装計画と動作確認チェックリストを作成する。
変更内容の解説(explainer)と理解確認クイズを生成する。マージ前に変更を理解しているか確かめたいとき、「この変更を説明して」「クイズを出して」「変更内容を理解したい」などの依頼で使う。
GitHub issue から実装前の調査を行い、受け入れ条件・影響範囲・実装方法の候補・リファレンス・盲点候補を整理する(選択は plan に委ねる)。
| name | dev |
| description | GitHub issue から計画・実装・テスト・レビュー・PR テキスト・理解確認まで一気通貫で行う。 |
| allowed-tools | Bash, Read, Glob, Grep, Write, Edit, Agent, Skill, AskUserQuestion, TaskCreate, TaskUpdate, TaskList |
| disable-model-invocation | true |
GitHub issue ( $ARGUMENTS ) に対して、計画から PR テキスト作成・理解確認まで一気通貫で実行する。
$ARGUMENTS は <issue> [mode] の形式で受け取る。
<issue>: issue 番号(123、#123)または URL。必須。空の場合はユーザーに issue 番号を質問する。URL が渡された場合は issue 番号を抽出し、以降のステップには正規化済みの issue 番号(例: 123)を渡す。[mode]: 慎重度合い。auto / normal のいずれか。省略可(開始時セットアップで質問する)。本スキルにおけるステップの唯一の定義。チェックポイント選択・スキップ選択・タスク登録・実行手順はすべてこの表を参照する。ステップを増減する場合はこの表の修正だけで完結させること。
| # | ステップ | 実行形態 | 呼び出し | 主な成果物 | 前提成果物 | 並列 |
|---|---|---|---|---|---|---|
| 1 | research | inline | Skill /research <issue> <mode> | research.md/.html | — | — |
| 2 | plan | inline | Skill /plan <issue> <mode> | plan.md/.html, checklist.html | research.md | — |
| 3 | review-plan | subagent | Agent → /review-plan <issue> | review-plan.md/.html | plan.md, checklist.html | — |
| 4 | implement | inline | Skill /implement <issue> <mode> | コード, implementation-notes.md, report.md/.html | plan.md | — |
| 5 | create-pr-text | subagent | Agent → /create-pr-text <issue> | pr.md | plan.md, report.md | A |
| 6 | test | inline | Skill /test <issue> <mode> | checklist.html 更新, screenshots/ | checklist.html, implementation-notes.md | A |
| 7 | review | inline | Skill /review <issue> | review.md/.html | 実装済みコード | — |
| 8 | quiz | subagent | Agent → /quiz <issue> | quiz.html | report.md, review.md | B |
| 9 | notify-discord | inline | Skill /notify-discord <サマリ> | — | — | B |
tmp/issues/<issue番号>/ 配下/test が結果を書き込む状態ファイルのため html 単一inline: Skill ツールで本会話内で実行する。ユーザーとの対話・コード変更・ブラウザ操作を伴うステップsubagent: Agent ツール(general-purpose)で別コンテキストとして実行する。対話が不要で「成果物を書いて要約を返す」ステップ。メイン会話のコンテキスト消費を抑え、review-plan では plan 作成の文脈を持たない独立視点 も担保する以下を 1 回の AskUserQuestion にまとめて 質問する(mode が引数で指定済みならその質問は省く)。このセットアップ質問は mode の「質問しない」制約の適用対象外(mode 確定前のセットアップであるため)。
auto / normal(推奨: normal)| mode | 挙動 |
|---|---|
auto | パイプライン中はユーザーに質問しない。plan の方針選択・曖昧な要件・config 追記もすべて推奨案で自動決定し、置いた仮定は各成果物に明記させる |
normal | plan の方針選択と config 追記の承認のみ質問する。それ以外は中断せず進める |
/plan 123 auto)。サブスキル側の質問要否は渡された mode に従うセットアップ完了時に tmp/issues/<issue番号>/dev-state.json を書き出し、ステップの開始・完了・ループ突入のたびに更新する。コンテキスト圧縮や中断を跨いでも選択と進捗を復元するため。
{
"issue": 123,
"mode": "normal",
"checkpoints": ["plan", "review"],
"skips": [],
"loops": { "review_plan": 0, "test": 0, "review": 0 },
"steps": { "research": "completed", "plan": "in_progress" }
}
/dev 開始時に同 issue の dev-state.json が既に存在する場合は内容を読み、未完了の最初のステップからの再開をユーザーに提案する(auto では自動で再開する)。
セットアップ完了後、TaskCreate より前に実行する。実装コミットがベースブランチや無関係なブランチに混ざるのを防ぐガード。
tmp/config.json の base_branch を読む。無ければ git remote show origin の HEAD branch から検出し、tmp/config.json に保存する(以降 <base> と表記)git rev-parse --abbrev-ref HEAD で現在のブランチ名を取得する。期待するブランチ名は issue-<issue番号>git rev-parse --verify issue-<issue番号> で存在確認し、存在すれば checkout、存在しなければ以下を順に実行
git status --porcelain で未コミットの変更を確認。変更がある場合は中断してユーザーに対処を促す(自動 stash / commit / discard はしない)git fetch origin <base>git checkout -b issue-<issue番号> origin/<base>(ローカル <base> を経由しない)issue-<issue番号> と異なるプロジェクトでは、動作を変える前にユーザーに相談するセットアップ後、ステップ定義表の各ステップ(スキップ対象を除く)を TaskCreate で一括登録する。
in_progress、正常完了で即座に completed に更新する(バッチ更新しない)in_progress にできるのは原則 1 タスク。例外: 同じ並列グループのステップは同時に in_progress にしてよいin_progress のまま保ち、必要ならループ内サブタスク(例: replan-round-2)を追加するステップ定義表の順に実行する。各ステップで:
auto: 警告を dev-state.json に記録し、続行可能なら続行、不可能ならそのステップもスキップ扱いにする。normal: ユーザーに続行可否を確認するAgent ツール(subagent_type: general-purpose)で起動し、プロンプトに以下を含める:
Skill ツールで review-plan を args「123」で実行してください)tmp/issues/<issue番号>/)の絶対パス/dev を終了するdev が実施内容のサマリを組み立てて /notify-discord <サマリ> として渡す。pitch の要領(結論・成果を先頭に、続けて要点)で構成する: 何ができたか(1-2 行)→ テスト・レビュー結果の要点 → 実施ステップ → 主要成果物のパス(詳細な解説は quiz.html の解説パートを案内)。notify-discord 側からユーザーへの質問が発生しない状態で呼び出すこと。
| ループ | 発動条件 | 戻り先 | 上限 |
|---|---|---|---|
| review-plan 差し戻し | 修正必須(must)が 1 件以上 | plan(修正)→ review-plan 再実行 | 3 回 |
| test 失敗 | チェックリストに失敗項目 | plan(更新)→ review-plan → implement → …(表の順に再実行) | test 実行 3 回 |
| review 差し戻し | must 指摘が 1 件以上 | implement(指摘の修正)→ review 再実行 | review 実行 3 回 |
loops に記録するtmp/issues/<issue番号>/ の既存成果物を新規作成し直すのではなく、失敗・指摘内容を反映して更新するreview ループを抜けたら、グループ B に進む前に plan.md の「完了の定義(Definition of Done)」を読み、各項目の充足を検証する。
指定されたステップの完了後、進行を一時停止し、直前ステップの成果物パスと次に実行されるステップを提示した上で AskUserQuestion で選択してもらう:
/dev を終了する(残タスクは削除し、dev-state.json に記録)ユーザーが回答するまで次のステップに進まない。
以下のいずれかで、plan が見落としていた間接依存・暗黙の必須セット・カスケードが判明した場合、今後の /plan と /review-plan で防げるよう、両スキルの config.json の attentions 配列に追記する(完全重複運用)。
以下のいずれかに該当する場合、追記候補とする:
逆に、以下は追記しない: その issue 限りの個別事情 / コード grep で素直に辿れる直接依存 / 既に同等の内容が attentions に存在する。
attentions には自然言語 1 行(または短い段落)で記述する。例:
"Firestore `orders/{orderId}` への書き込みは functions/src/triggers/onOrderWrite.ts を発火し、Discord 通知文面の更新も必要"
auto: ユーザー確認なしで両 config に自動追記normal: 追記候補の内容と追記先を提示し、承認されれば追記