GOOD検証可能
根拠を指す
「逆引きは最初の対を返す（pipeline.ts:357-358）」
GUIDE
requestの書き方
agentの推測を減らし、1つの収束ループで検証可能なrequestへ整えます。
このページの内容
最重量部を行間に隠さない
request.mdはPipelineへの入力です。解像度が低い部分はagentの推測になります。実装方法を固定しすぎず、境界・判断材料・完了条件を明確にします。
既存機構の一般化、暗黙の前提の変更、複数箇所への波及など、実装で最も重い変更は要件として名指しします。受け入れ基準から読み取らせません。
## Meta
- **type**: new-feature
- **slug**: my-feature
- **base-branch**: main
- **adr**: true現状コードの前提は書く直前に検証する
「今のコードはこうなっている」という断定にはfile:lineを添え、記述直前に実コードと突き合わせます。古い調査メモから転記すると、request-reviewで不要なescalationを招きます。
AVOID推測
記憶に頼る
「逆引きは多対一に対応していないはず」
1 requestは1つの収束ループ
1件のレビュー収束ループで直しきれる範囲を上限の目安にします。大きい場合は「土台 → 上物」で分割します。
独立して設計・テストできる分割する
収束の意味論が異なる必ず分割する
片方が他方の受け入れ基準を参照する同じrequestに残す
スコープ外を名指しする
実装中に「ついでに」変更したくなる隣接領域を列挙します。これは実装の逸脱防止とレビュー判定の両方に使われます。
受け入れ基準は機械検証できる文にする
GOODtrue / false
検証方法を含める
「既存テストが無変更でgreen」「typecheck && testがgreen」
AVOID曖昧
評価語だけを書く
「適切に動作する」「品質が改善される」
却下した代替案と理由を書く
採用案だけでなく、検討して退けた案と理由を残します。implementerによる再発明と、reviewerによる決着済み論点の再提起を防ぎます。
「専用fixerは収束ループの組み合わせ爆発を招くため却下し、findingsの出所識別で代替する」
typeとadrを選ぶ
設計の追加・変更を含む場合はbug-fixではなくspec-changeまたはnew-featureを選びます。typeはモデル選択とreviewerの判定姿勢に影響します。
adrは雛形コメントの判断基準に従います。構文は実行前に検証します。
npx specrunner request template
npx specrunner request validate my-feature