auto-dev

# /auto-dev Issue番号: $ARGUMENTS Issue 1件を実装し、**push と PR 本文の差し替えまで**を人間への確認なしに自律実行する。起動するのは `npm run auto-programmer`（人間が直接打ってもよい）。 ## 前提 - **作業ツリーは AI 専用の clone で、人間の作業ツリーとは別物。** 起動側がこの clone を `origin/main` の状態へ戻し、トピックブランチを作り、ボードの 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` が行う。 ## 処理フロー ### Phase 1: Issue を読む ```bash gh issue view $ARGUMENTS --json title,body,labels,state ``` state が `OPEN` でなければ、何もせず理由を表示して終了する。 **本文は全節を読む。** 判断に使う順は「対応方針」→「タスク一覧」→「完了条件」で、実装の進め方は「実装フロー（使用するSkill）」と「今回作らないこと」、離脱の判定は「対象箇所」を材料にする。**方針を決め直さない。** 本文の「対応方針」に書かれた採る案どおりに実装する。 ### 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](../../../docs/policy/ai-review-gate-policy.md) に従って決める（自律型ワークフロー）。 - 指摘があれば、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 へ進む。満たしていなければ離脱手順へ進む。 ```bash gh issue close $ARGUMENTS --comment "<何をしたか>" ``` ### Phase 4: コミットする その Issue で編集したファイルだけを `git add <パス>` でステージし、`/git-commit stage` を実行する。ワーキングツリー全体を対象にしてはならない。 件名末尾の `(#$ARGUMENTS)` は git-commit Skill が必須としている。**`Closes` はコミットメッセージに書かない**（同じく git-commit Skill）。 ### Phase 5: push する ```bash 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 5・Phase 6 が「エラーハンドリング」の表のとおりに失敗した 人間が気付ける形にするため、終了前に次の2つを必ず行う。 ```bash 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 を `origin/main` の状態まで戻す。ボードの 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` が表示した本文ファイルの中身をコメントに貼って終了する |