/auto-dev

Issue番号: $ARGUMENTS

Issue 1件を実装し、push と PR 本文の差し替えまでを人間への確認なしに自律実行する。起動するのは npm run auto-programmer（人間が直接打ってもよい）。

前提

• 作業ツリーは AI 専用の clone で、人間の作業ツリーとは別物。 起動側がこの clone をデフォルトブランチ（GitHub のリポジトリ設定）の最新の状態へ戻し、トピックブランチを作り、ボードの Status を「着手中」へ動かしたうえで起動する。このスキルはブランチを作らない・切り替えない・Status を動かさない（どれも起動側が済ませている）。
• 人間はこの実行を見ていない。 確認を待たずに最後まで進める。進めないと分かったら「離脱手順」で痕跡を残して終了する。
• 1 Issue = 1 ブランチ = 1 PR。Issue は閉じない。 PR 本文の Closes がマージ時に閉じる。CLAUDE.md の「完了したら gh issue close する」は、PR を経由しない作業への規定なので、このスキルには適用しない。ただしリポジトリの差分が出ない Issue（GitHub 上の操作だけで完了するもの）は PR を経由しない作業に当たるので、このスキルが閉じる（「差分が無いとき」）。
• PR 本文は /pr-body が書く。 ラベル付与・マージ可否の判定・auto-merge は pipeline.yml → pr-ai-triage.yml が行う。
• push 前の取り込みは Phase 4 の手順で行う。 CLAUDE.md の「git push する前に、デフォルトブランチの最新を取り込む」は、このスキルでは Phase 4 で置き換える。PR はデフォルトブランチ宛てに作られるので、取り込む先もデフォルトブランチにする。

処理フロー

Phase 1: Issue を読む

gh issue view $ARGUMENTS --json title,body,labels,state

state が OPEN でなければ、何もせず理由を表示して終了する。

本文は全節を読む。 判断に使う順は「対応方針」→「タスク一覧」→「完了条件」で、実装の進め方は「実装フロー（使用するSkill）」と「今回作らないこと」、離脱の判定は「対象箇所」を材料にする。方針を決め直さない。 本文の「対応方針」に書かれた採る案どおりに実装する。「対応方針」の直後にある <details>（/issue-check が追記した外部制約）も読む。「対応方針」の表の「変えた後」の文言が一次資料の原文と食い違うときは、Issue 本文は書き換えず、成果物に書く文言だけを原文に合わせて直す（採る案・書き先・対象は変えない）。例：「変えた後」が「月100回まで無料」と書くが、<details> が引く一次資料は「月50回まで」なら、成果物には「月50回まで」と書く。文言を直すのは実装者であり、/issue-check が直すと方針の書き換えになるため。

Phase 2: 実装

本文に「実装フロー（使用するSkill）」があれば、そこに並ぶ Skill を記載順に Skill ツールで実行する。無ければ CLAUDE.md「変更種別ごとの使用Skill」で決める。

• AskUserQuestion が要る場面は、最初の選択肢（既定）を選んで進む
• タスクを1つ終えるごとに gh issue edit $ARGUMENTS でチェックリストを更新する（CLAUDE.md の厳守ルール）
• 本文の「今回作らないこと」に挙がっているものには手を出さない

実行する Skill がレビュー（/doc-review・/code-review・/cdk-review・/arch-review・/requirements-review）のときは、合否・再レビューの回数・修正範囲を ai-review-gate-policy に従って決める（自律型ワークフロー）。

• 指摘があれば、severity にかかわらずすべて直す（例外は同ポリシー「直す範囲は毎回すべて」の残してよい例外だけ）。直したら同じレビュー Skill を再実行する。再レビューには前回の指摘を渡さない
• レビューは同じ Skill ごとに最大2回（初回を含む）。「タスク一覧」の作業として動作確認のために回したものも回数に数える。残してよい例外以外の Critical が0件になった回で合格とし、その回に出た High・Medium もその場で直してから次へ進む
• 2回目のレビューで指摘が出たら、直したうえで再レビューせずに Phase 3 へ進む

Phase 3: 検証

変更した種類に応じて実行する。落ちたら直し、通るまで次へ進まない。

変更した対象	実行するもの
Markdown・.claude/ のプロンプト定義	npm run check:links と /quick-doc-review
アプリ・スクリプト	/code-ci
CDK	/cdk-ci
.claude/hooks/ 配下	npm run test:hooks

Phase 2 で同じ Skill を実行済みなら、その後にファイルを直していない限り再実行しない。npm run で始まるものは、最後の編集より後に1度は必ず実行する。

差分が無いとき

git status --short が空なら、Phase 4〜6 を飛ばす。離脱手順にも回さない（作業は終わっているのに「直しきれなかった」印が付く）。

本文の「完了条件」をすべて満たしたと確かめてから、何をしたかを書いて閉じ、Phase 7 へ進む。満たしていなければ離脱手順へ進む。

gh issue close $ARGUMENTS --comment "<何をしたか>"

Phase 4: コミットする

先に、最新のデフォルトブランチを取り込む。 ステージする前に行う（ステージ済みの変更があると、git が取り込みを断る）。取り込みから push までを短くし、その間にデフォルトブランチが進んで再び衝突するのを減らすため、最後のコミットの直前に置く。取り込みの後のコミットで、pre-commit hook が npm run gen:adr-index の生成物を作り直す。

デフォルトブランチ名は gh で GitHub から引く（origin/HEAD は clone した時点の値のまま残り、使い回す clone では古くなるため使わない）。シェル変数は Bash ツールの呼び出しをまたいで残らないので、1回で実行する。

base=$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name) && git fetch origin "$base" && git merge --no-edit "origin/$base"

• 衝突したら、衝突したファイルを解く。生成物は中身を手で直さず、npm run gen:adr-index で作り直して git add する。解けなければ離脱手順へ進む
• 「Your local changes ... would be overwritten」で止まったら、取り込みが未コミットの変更と重なっている。先に下の手順でコミットし、そのあとで取り込む。自動で完了する merge コミットでは pre-commit hook が走らないので、取り込んだ後に npm run gen:adr-index を実行し、差分が出たら git add して /git-commit stage でコミットする

その Issue で編集したファイルだけを git add <パス> でステージし、/git-commit stage を実行する。ワーキングツリー全体を対象にしてはならない。

件名末尾の (#$ARGUMENTS) は git-commit Skill が必須としている。Closes はコミットメッセージに書かない（同じく git-commit Skill）。

Phase 5: push する

git push -u origin HEAD

Phase 6: PR のタイトルと本文を差し替える

/pr-body $ARGUMENTS を Skill ツールで実行する。pipeline.yml が作る PR を待ち、タイトルと本文（末尾に Closes #$ARGUMENTS）を差し替えるところまでを /pr-body が行う。

Phase 7: 報告する

PR の URL・実行した検証・更新したタスクを表示して終了する。差分が無く PR を経ずに閉じたときは、URL の代わりに close した理由を表示する。

離脱手順

次のどれかに当たったら、以降の Phase へ進まずに終了する。

• 本文から何を直すか決まらない（「対応方針」の見出しが無い・見出しの中に「採る案」の記述が無い／「対象箇所」に挙げた箇所が既に無い）
• Phase 3 の検証が通らず、2回直しても同じ箇所で落ちる
• 修正が、本文の「対象箇所」の外へ波及した（Phase 4 の取り込みで衝突を解いた変更は数えない）
• Phase 5・Phase 6 が「エラーハンドリング」の表のとおりに失敗した

人間が気付ける形にするため、終了前に次の2つを必ず行う。

gh issue comment $ARGUMENTS --body "<どこまでやって、何で止まったか>"
gh issue edit $ARGUMENTS --add-label "issue:needs-clean-session"

このラベルは「着手したうえで、このやり方では直しきれないと分かった印」で、/sweep と同じ意味で使う。付けた Issue は /sweep の対象からも外れ、人間が専用のセッションで1件だけ対応する。

押し戻しはしない。 未コミットの変更・作ったコミット・push 済みのブランチは、どれも消さずに残してよい。次の npm run auto-programmer が clone をデフォルトブランチの状態まで戻す。ボードの Status は「着手中」のままなので、同じ Issue が次の実行で拾われることはない。

エラーハンドリング

起きたこと	どうするか
gh の認証が切れている	コメントも投稿できないので、最後のメッセージに理由を出して終了する
Skill が進まない（fork型：frontmatter に agent: を持つ Skill。ListAgents が running のまま、同じ経過時間の表示が3回続けて変わらない）	TaskStop に Skill 名を渡して止め、その Skill が指定する agent を run_in_background: false で起動し直す
Skill が進まない（並列起動型：frontmatter に agent: を持たず、中で subagent をレンズごとに並列 Task 起動する Skill。ListAgents で止まっているレンズ1回分だけが running のまま、同じ経過時間の表示が3回続けて変わらない）	止まっているレンズ1回分だけ TaskStop で止め、そのレンズに渡していたのと同じ引数（レンズ名・対象パスなど）で、そのレンズの subagent だけを run_in_background: false で起動し直す。ほかのレンズの結果は捨てない
push が拒否される（同名ブランチが先にある）	起動側がブランチを作り直すので、離脱手順へ
push が pre-push hook の整形検査（npm run format:check）で拒否される	npm run format で整形し、変わったファイルを git add <パス> して /git-commit stage でコミットし、push し直す。--no-verify で飛ばさない。整形だけの変更は、離脱条件の「対象箇所の外へ波及」に数えない
/pr-body が失敗を表示して終了する	離脱手順に加えて、/pr-body が表示した本文ファイルの中身をコメントに貼って終了する