変更のレビュー

Rasen の全体的な約束は、あなたと AI がコードが書かれる前に構築内容に同意することです。その合意は、実際に AI が下書きしたものを読むかどうかに基づいてのみ意味があります。このページは、それをする 2 分間についてです—何を開くか、どのような順序で、何を探すか。

賭けはシンプルです: 1 段落のプランで間違ったターンをキャッチすることはほぼ無料です。同じ間違ったターンを 300 行のコードでキャッチすることはそうではありません。レビューはその賭けを支払う場所です。

レビューの 2 つの瞬間

正確に 2 つあります:

/rasen:propose ──► REVIEW THE PLAN ──► /rasen:apply ──► REVIEW THE CODE ──► /rasen:archive
                  (before any code)                    (/rasen:verify)

1. /rasen:propose の後（または /rasen:ff）、/rasen:apply の前—それがまだ単なる言葉である間にプランを読んでください。
2. 構築後、/rasen:verify を使用—コードが実際にプランが述べたことをしたことを確認してください。

最初のレビューは最も節約でき、スキップする人です。このページはそこにほとんどの時間を費やします。

この順序で読んでください

変更は rasen/changes/<name>/ 内のプレーン マークダウン フォルダです。何か間違っている場合は最も早く終了できる順序でファイルを読んでください:

rasen/changes/add-dark-mode/
├── proposal.md      1. the intent and scope   ← if this is wrong, stop here
├── specs/…/spec.md  2. the requirements       ← the heart of the review
├── design.md        (only for bigger changes) — the technical approach
└── tasks.md         3. the plan of work

すべての行を読む必要はありません。3 つの質問に答える必要があります、1 つのファイルごと。

提案: これは正しい問題ですか？

最初に proposal.md を開きます。「なぜ」と「何」をキャプチャします—意図、範囲、1～2 段落でのアプローチ。

良いものの見た目: 1 つの明確な意図、認識している範囲、これが今行う価値がある理由。

赤旗:

• あなたが尋ねたものとは少し異なる問題を解決します。
• 範囲が拡大しました—テーマ トグルを尋ねましたが、提案は「そこにいる間に」認証にも触れます。
• それは曖昧です。「設定ページを改善」は範囲ではありません。「OS の設定を尊重する暗いモード トグルを追加」です。

答える質問: これは実際に尋ねたことと一致していますか、そして何かが忍び込んでいますか？ 答えが いいえ の場合、停止—さらに読まないでください、提案を修正してください（後退は安いを参照）。

スペック デルタ: 「完了」は正しく定義されていますか？

これがレビューの中心です。specs/ の下のデルタ仕様は、変更が出荷するときに真実になるもの—要件とそれらを証明するシナリオとして:

## ADDED Requirements

### Requirement: Dark Mode Toggle
The system SHALL let a user switch between light and dark themes.

#### Scenario: Respects the OS preference on first load
- GIVEN a user who has never set a theme
- WHEN they open the app on a device set to dark mode
- THEN the app renders in dark mode

良い要件がどのように見えるか: 1 つの明確な SHALL/MUST ステートメント テスターに渡すことができる、そして少なくとも 1 つのシナリオ、その GIVEN/WHEN/THEN はステートメントを実際に実行します。

赤旗:

• 曖昧な要件。 「システムは速くなければならない」は構築またはテストできません。何が速いですか？
• シナリオのない要件、またはシナリオは、その下にある要件をテストしません。
• 最も価値のあるキャッチ: 何が欠けているか。 AI は述べたものを忠実に書きます。あなたの仕事は忘れたものに気づくことです。OS-preference ケースについて最も気にかけ、シナリオはそれを言及しない場合、それはレビューがそれを支払う場所です。

システムが正確に—そしてのみ—これをしたら、幸せになるだろうか？ として、デルタを読んでください。ここでのコードについては何もないため、変更する価値は変わります。

タスク: 作業計画は健全ですか？

tasks.md を最後に開きます。AI が動作する実装チェックリストです。

良いものの見た目: 順序付きステップ、各々が要件にトレース可能、謎なし。

赤旗:

• 一致する要件のないタスク（それはどこから来ましたか？）。
• すべての実際の決定を隠す 1 つの巨大な「機能を実装」タスク。
• 承認したばかりのスコープの外側に触れるタスク。

ここで推定またはマイクロマネジメントを行っていません—プランが既に受け入れた要件と一致することを確認しています。

後退は安い

3 つの質問のいずれかが間違ったことが返ってきた場合、そう言ってください。フェーズも何もロックされていません—修正して進みます。正確に 2 つの方法、変更の編集と同様に:

• ファイルを自分で編集。 プレーン マークダウンです。スコープ行を変更し、要件を絞り込み、タスクを削除してください。
• AI に何が間違っているかを伝え、修正を譲ります: 「認証の変更を削除—範囲外」、 「ユーザーがテーマを既に選択した場合のシナリオを追加」、 「タスク 3 をスキーマと UI に分割。」

その後、変更した部分を読み直してください。署名する価値があるプランになるまで再作成します。その後ろと前*製品の動作です。

コード後: 検証

作業が構築されたら、/rasen:verify が 2 番目のレビューです。成果物とコードを再読し、3 つの次元全体でミスマッチをレポートします:

You: /rasen:verify

AI:  Verifying add-dark-mode...

     COMPLETENESS
     ✓ All 8 tasks in tasks.md are checked
     ✓ All requirements in specs have corresponding code
     ⚠ Scenario "Respects the OS preference on first load" has no test coverage

CRITICAL、WARNING、SUGGESTION としてフラグが設定され、アーカイブをブロックしません—ギャップを表示し、呼び出しはあなたに任せます。これは「AI がコードを書いたか」と「合意した内容を構築したか」の違いです。

/rasen:verify は展開プロファイルにあります。それがない場合、rasen config profile をオンにします（その後 rasen update）、または自分で変更と差分を読み直してください。

レビューを右サイズに

すべての変更が完全なパスを獲得するわけではありません。1 ファイルのタイプフィックスは 20 秒のスキムに値します。認証、支払い、回復できないデータに触れる変更は、上記のすべての質問に値します。重要な点は式ではなく、ミスが高い場所に注意を費やし、そうでないスキム場所でスキムします。

2 分間のチェックリスト

• 提案の意図は、尋ねたものと一致します。
• 範囲に追加の範囲が忍び込んでいません。
• すべての要件はテストするのに十分な具体性です。
• すべての要件には実際にそれを実行するシナリオがあります。
• 私が最も気にかけるケースがカバーされています。
• タスクは要件にマップ。何も謎ではなく、範囲外です。
• AI がこれを正確に構築し、それ以上何も構築されない場合は快適です。

すべて 7 つが通過する場合、/rasen:apply を自信を持って実行してください。いずれかが失敗する場合、それは挫折ではありません—それは 2 分間がその仕事をしています。

次に行くところ

• 良い仕様の書き方 — フリップ側: 承認する価値のある要件とシナリオを下書きする方法。
• 変更の編集と反復 — 開始後にプランを変更する仕組み。
• ワークフロー — より大きなループでレビューが適合する場所。