/opsx:apply 以降を完全放置でPR作成までやってくれるスキルを作った

---
name: opsx-auto-apply
description: "/opsx:apply以降のワークフロー（実装→検証→レビュー→修正ループ→spec同期→最終検証→コミット&push&PR）をフルオートで実行します。"
---

# opsx-auto-apply

## 目的

OpenSpecのapply以降のワークフローを完全自動で実行する。
手動で `/opsx:apply` → `/opsx:verify` → `/review` → 修正ループ → spec同期 → 最終検証 → コミット&push&PR を繰り返す手間を省く。

## 前提条件

- openspec CLIがインストールされている
- 対象のchangeが存在し、tasksアーティファクトが作成済みである
- gitリポジトリ内で作業している
- デフォルトブランチ（main）上ではなく、作業ブランチが準備されている

## 入力

`$ARGUMENTS` でchange名を指定する。省略時はopenspec listから推定またはユーザーに選択を促す。

## 実行フロー

### Phase 0: 準備

1. **change名の決定**

   `$ARGUMENTS` が指定されていればそれを使う。なければ：
   ```bash
   openspec list --json
   ```
   で一覧を取得し、1つしかなければ自動選択、複数あればAskUserQuestionで選択を促す。

2. **ブランチ確認**

   現在のブランチがデフォルトブランチ（main）でないことを確認する。
   mainの場合はエラーとして停止する。

3. **生成されたchangesをコミット & push**

   openspecが生成したchanges（タスクファイル等）がまだコミットされていない場合、Draft PR作成前にコミットしておく。
   - 変更ファイルを個別に `git add`
   - `git commit`
   - `git push`

4. **Draft PRをオープン**

   ```bash
   gh pr create --draft --title "<change名に基づくタイトル>" --body "WIP: OpenSpec auto-apply in progress"
   ```

   既にPRが存在する場合はスキップする。PRのURLを記録しておく。

### Phase 1: 実装（/opsx:apply相当）

1. **openspec instructions applyを実行してコンテキストを取得**

   ```bash
   openspec status --change "<name>" --json
   openspec instructions apply --change "<name>" --json
   ```

2. **contextFilesを全て読み込む**

3. **タスクを順次実装する**
   - 各タスクについてコード変更を実施
   - タスク完了時にcheckboxを `[x]` に更新
   - 全タスク完了まで継続

4. **コミット & push**
   - 変更したファイルを個別に `git add` する（`git add -A` 禁止）
   - `git commit` する
   - `git push` する

### Phase 2: 初回検証（/opsx:verify相当）

1. **openspec verify手順を実行**
   - Completeness（タスク完了状況、spec coverage）
   - Correctness（要件実装マッピング、シナリオカバレッジ）
   - Coherence（設計準拠、コードパターン一貫性）

2. **CRITICAL issueがあれば修正してPhase 2を再実行**

### Phase 3: コードレビュー

1. **レビューコマンドの選択**

   以下の順で判定し、最初に該当するものを使う：
   - プロジェクトがGoプロジェクト（`.go`ファイルが存在）かつ Go用レビュースキル が利用可能 → Go用レビュースキル を使用
   - 上記に該当しない → `/review` を使用

   利用可能かどうかは、system-reminderに表示されるavailable skillsの一覧で判断する。

2. **レビューを実行**
   - 現在のブランチの変更内容（ベースとの差分）を対象にレビューを実施

3. **レビュー結果の評価**
   - 各指摘事項の重要度を確認

### Phase 4: レビュー修正ループ

レビュー結果にWarningsレベル以上の指摘事項がある場合、以下をループする：

1. **指摘事項を修正する**
   - CRITICAL → WARNING の順に優先度高く対応
   - 修正内容は最小限に留める

2. **修正をコミット & push**
   - 変更ファイルを個別に `git add`
   - コミットメッセージは修正内容を反映
   - `git push`

3. **再レビュー**
   - Phase 3で選択したレビューコマンドで再度レビュー

4. **ループ継続判断**
   以下を総合的に判断してループを終了する：
   - Warningsレベル以上の指摘事項がすべて解消された → 終了
   - 修正を繰り返しても同じ指摘が残り続ける（修正困難と判断） → 終了し、残課題として記録
   - 新たな指摘が発生せず、残りの指摘がSUGGESTIONレベルのみ → 終了

### Phase 5: Spec同期（/opsx-reverse相当）

1. **コード変更とspecの差分を検知**
   - `git diff` でapply以降の全変更を確認
   - 変更されたコードに関連するopenspec仕様書を特定

2. **差分がある場合、specを更新**
   - コード実装を正としてspec .mdファイルを更新
   - 既存の記述スタイル・形式を維持
   - コードは変更しない（.mdファイルのみ更新）

3. **spec更新をコミット & push**

### Phase 6: 最終検証（/opsx:verify相当）

1. **再度openspec verify手順を実行**
   - spec同期後の状態で3次元検証（Completeness, Correctness, Coherence）

2. **CRITICAL issueがあれば修正 → 再検証（Phase 6をループ）**

3. **最終コミット & push**

### Phase 7: 完了

1. **最終結果レポートを表示**

   ```
   ## Auto-Apply Complete

   **Change:** <change-name>
   **PR:** <PR URL>

   ### Summary
   - Tasks: X/X complete
   - Review: Passed (N iterations)
   - Spec sync: Y files updated
   - Final verify: All checks passed

   ### Remaining Notes
   - <SUGGESTIONレベルの残課題があれば記載>
   ```

## ガードレール

- `git add -A` や `git add .` は絶対に使用しない
- mainブランチでは作業しない
- コミット前にプロジェクトのビルド・テストコマンドを実行する
  - Makefile がある場合: lint/test 系のターゲットを実行（例: `make lint && make test`）
  - package.json がある場合: `npm test` や `npm run lint` 等を実行
  - go.mod がある場合: `go vet ./... && go test ./...` 等を実行
  - 上記に該当しない場合: プロジェクトの構成から適切なコマンドを推定する
- セキュリティ上の問題（APIキー、パスワード等）を含むファイルをコミットしない
- 各フェーズ間でユーザー確認は挟まない（完全フルオート）
- エラーが発生した場合は自動リカバリを試み、不可能な場合のみ停止してユーザーに報告

## コンテキスト

$ARGUMENTS