xallindrome-labs/claude-code-ops

/runway

目標：すべての質問は今行うため、40ターン目に質問する必要はありません。その後、ユーザーは1つの計画を承認して離脱し、電話は停止ポイントでのみ呼び出されます。

基本ルール（ユーザーが独自のルールを CLAUDE.md に持っている場合はそちらが優先されます）：

• ローカルで元に戻せる作業（編集、ビルド、テスト、ローカルコマンド、ブランチまたはワークツリーでのコミット）は、確認なしで実行します。
• 以下の場合は必ず停止します： プッシュまたはデプロイ、メッセージの送信、アプリケーションの送信、金銭の消費、データの削除、公開情報の発行。
• 負荷の高い作業（検索、テスト実行、ログトリアージ）には安価なサブエージェントモデルを使用し、トップモデルは設計と難しいデバッグにのみ使用します。

0. 事前確認（サイレント、質問なし）

• リポジトリのルートとその状態を確認します：git status、現在のブランチ、既存の SPEC.md、テストおよびビルドスクリプト（package.json、Makefile など）。事実を見つけるのはあなたの仕事であり、ユーザーの仕事ではありません。
• 電話承認が有効かどうかを確認します。~/.claude/settings.json に phone-approve.js を実行する PermissionRequest フックがある場合、またはこのプラグインのフックが有効で、かつ ~/.claude/phone-approve.json が存在する場合、有効です。そうでない場合は、ユーザーに一度だけ伝え（セットアップ：node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init を実行し、そのファイル内のリクエストトピックに ntfy アプリを購読します）、続行します。停止ポイントはデスクトップダイアログにフォールバックします。
• 停止ポイントコマンドが強制的にプロンプト表示されるように設定されていることを確認します。自動モードではプロンプトなしで承認される可能性があるためです。ユーザー設定、プロジェクト設定、ローカル設定で、git push、このリポジトリのデプロイコマンド（vercel、aws s3 sync、cdk deploy、npm publish、gh release、gh pr merge）、および削除コマンド（rm -r、git clean、git branch -D）をカバーする permissions.ask（または deny）ルールを確認します。ルールがない場合は、具体的なルールを提案し、差分を表示し、ユーザーが同意した場合のみ追加します（プラグインの examples/permissions-ask.json が開始点です）。送信、公開、デプロイツールに allow ルールを追加したり、Bash(*) を許可したりしないでください。

1. 仕様が完了するまでインタビューを行う

grilling または grill-me スキルがインストールされている場合は、それを呼び出してこの機能に対して実行します。そのルールが完全に適用されます。ない場合は、以下のように自分でインタビューを実行します。ラウンドで質問します。各ラウンドには、前提条件が既に確定しているすべての質問が含まれ、それぞれ番号が振られ、あなたの推奨回答が「はい」で受け入れられるように書かれています。回答を待ち、今質問可能なものを再計算し、繰り返します。環境の事実は自分で調べ（負荷の高い検索にはサブエージェントを使用）、自分で調べられることをユーザーに決して尋ねないでください。決定はユーザーが行います。

ユーザーが以前に会話の中でこの機能について grilling セッションを実行し、共通認識を確認している場合は、繰り返さないでください。回答を再利用し、以下のチェックリスト項目で未解決のものだけを質問します。

以下のすべての項目が未解決でなくなるまで続けます：

1. 目標：1～2文で、ユーザーが目に見える成果。
2. 範囲：変更されるもの（領域、ファイル、画面）。
3. 範囲外：絶対に触れてはならないもの。
4. 受け入れ基準：各項目がコマンド出力によって真であることを示せるチェックリスト。
5. 検証コマンド：終了コード0で完了を意味する正確に1つのコマンド（例：npm run lint && npm test && npm run build）。存在しない場合、仕様には最初のタスクとしてそれを書くことが含まれます。
6. 停止ポイント：プッシュ/デプロイ/送信/提出/消費/削除/公開のうち、この機能が該当するものと、各ポイントでユーザーが期待すること（例：「ブランチをプッシュし、PRを開き、マージはしない」）。
7. タスク途中で行うであろう決定：ライブラリ、命名、データ構造、コピー、エッジケースの動作。今、推奨とともに質問します。
8. ターン上限（デフォルト60）と予算に関する懸念。

ユーザーが共通認識を確認するまで先に進まないでください。

2. SPEC.md を作成し、ローカルにコミットする

リポジトリルートに SPEC.md を作成します：

# <機能名>
## 目標
## 範囲
## 範囲外
## 受け入れ基準
- [ ] ...
## 検証コマンド
`<1つのコマンド>`
## 停止ポイント
| アクション | 期待される処理 |
## 既に行われた決定
## ターン上限
60

ブランチを作成し（git switch -c runway/<スラッグ>）、または他のセッションが同じフォルダを編集している場合はワークツリーを使用し、SPEC.mdのみをコミットします。これはローカルで元に戻せる作業です。確認は不要です。決してプッシュしないでください。

3. 1つの計画承認

計画モードに入り、単一の計画を提示します：順序付けられたステップ、どのステップがサブエージェントに（どのモデルで）行くか、検証コマンド、および期待される処理付きの停止ポイント。これが実行前の唯一の承認です。ExitPlanMode を使用し、ユーザーに 「はい、自動モードを使用します」 を選択するように求めます。（電話フックは意図的に計画承認をスキップするため、ユーザーはコンピュータでこれを行います。）

承認後、自動モードがアクティブでない場合は、その旨を伝え、ユーザーに切り替えるよう依頼します。手動モードでループを実行しないでください。

4. /goal とターン上限の下で実行する

組み込みのスラッシュコマンドはモデルから呼び出せないため、前のステップを終了する際に、ユーザーに1行を貼り付けるよう指示します（実際のコマンドと上限を記入）：

/goal <検証コマンド> が終了コード0を返し、SPEC.md のすべての受け入れ基準がトランスクリプト内の証拠とともにチェックされ、SPEC.md の範囲外リストにあるものは一切触れられていないこと、または60ターン経過後に停止すること

セッションが既にゴールを実行している場合、/goal はそれを置き換えます。評価者はトランスクリプトのみを見るため、作業中は：検証コマンドを頻繁に実行し、その結果を出力し、証拠とともに SPEC.md の基準をチェックします。各ターンでターン上限に対する進捗を報告します。

実行中：

• 質問をしないでください。指定されていないことが発生した場合は、仕様に最も近いオプションを選択し、「既に行われた決定」に記録して続行します。停止ポイントに達するか、仕様に反する場合にのみ、質問のために停止します。
• 小さなコミットで runway ブランチに作業をコミットします。停止ポイントの承認なしにプッシュしないでください。
• 停止ポイントでは、通常どおり呼び出しを行います。権限プロンプトが電話を呼び出します。拒否された場合は、別の方法で再試行せず、記録し、それを必要としない作業を完了して報告します。
• 3連続のターンで進捗がない場合は、停止して何が妨げになっているかを報告します。

5. 終了

検証が成功した場合（または上限に達した場合）、以下の順序で報告します：

1. 結果：完了 / 一部完了 / ブロック、およびブランチと任意のPRリンク。
2. 差分統計（git diff --stat <ベース>...HEAD）。
3. 検証済み：証明された基準と、コマンドと結果。
4. 未検証：証明されていない、または部分的にしか証明されていない基準。停止ポイントでスキップまたは拒否されたもの。
5. 使用されたサブエージェント、どのモデルか、小さいモデルで悪化した場所。
6. ターン数と、上限に対するおおよそのコスト。