レビュースタイルスキル
目的
コードがすべてのプロジェクトスタイルガイドに従っているかを検証します。 これはパス/フェイルのゲートであり、フィードバックセッションではありません。
使用するタイミング
- TDD検証フェーズ
- スタイル準拠のPRレビュー
- スタイル検証が必要なコードレビュー
必要な入力
context_files
- レビュー対象フェーズのスタイルガイド（例:
docs/style/rust-design.md） - レビューする変更ファイル
- 元号台帳ファイル（マルチサイクルレビュー時に任意）
context_data
phase: フェーズ（designer/tester/implementor）— どのスタイルガイドルールを適用するかを決定changed_files: レビューするファイルのリスト
レスポンス形式
以下のスキーマに従った構造化レスポンスを返します。
class StyleResult(BaseModel):
status: Literal["accept", "violations"]
violations: list[str] = [] # 各要素: "file:line - description"
themes: str | None = None # 違反にまたがるパターン（任意）
すべてのチェックがパスした場合:
StyleResult(status="accept")
いずれかのチェックが失敗した場合:
StyleResult(
status="violations",
violations=[
"src/config.rs:23 - snafuセレクタがモジュールレベルでインポートされています。関数内部で行うべきです",
"src/parser.rs:45 - テスト内にGiven/When/Thenコメントがありません",
],
themes="複数の違反が一貫性のないエラーハンドリング手法に起因しています"
)
元号台帳への対応
context_filesに元号台帳ファイルが提供された場合:
- 以前のサイクルを読む — どの違反が提起され、実装者がどう応答したかを確認
- RESOLVED（解決済み）項目を検証 — 修正が実際に適用されたことを確認
- DISPUTED（論争中）項目を尊重 — 実装者の理由が妥当であれば再提起しない
- 新しい違反のみを提起 — 以前に議論されていない問題のみ
スタイルガイド（信頼できる情報源）
docs/style/ 内のスタイルガイドが唯一の情報源です:
docs/style/rust-design.md— 設計フェーズのルール（型、シグネチャ、bon、nutype、snafu）docs/style/rust-impl.md— 実装フェーズのルール（エラーハンドリング、インポート、パニック禁止）docs/style/rust-test.md— テストフェーズのルール（Given/When/Then、test_case、アサーション）
該当するガイドを読み、自分の判断を適用してください。要約に頼らないでください。
手順
1. 適用ルールの特定
フェーズに基づいて:
designer: rust-design.md のルール（特に「プロジェクトクレート選択表」）tester: rust-test.md のルールimplementor: rust-impl.md のルール- テストファイル（
#[cfg(test)]モジュール）はフェーズに関係なく常に rust-test.md のルールが適用
2. 各ファイルのレビュー
適用可能なスタイルガイドルールに照らしてチェックします。 明確な違反のみをフラグし、スタイルの好みはフラグしません。
設計フェーズの重要なチェック:
- 複合構造体（2フィールド以上）は
#[derive(Builder)]と#[non_exhaustive]を使用しているか - バリデーション付きnewtypeは
nutypeを使用しているか - エラーは
#[snafu(module)]付きのsnafuを使用しているか - 関数本体は
todo!()であり、実装が含まれていないか
実装フェーズの重要なチェック:
- プロダクションコードに
unwrap()/expect()がないか - snafuコンテキストセレクタが関数内部でインポートされているか
- インポート間に空行がないか
テストフェーズの重要なチェック:
- すべてのテストにGiven/When/Thenコメントがあるか
- パラメータ化テストに
test_caseが使われているか
3. 構造化結果の返却
StyleResult スキーマを使用します。オーケストレーターがこれを解析して次のステップを決定します。
このスキルが行わないこと
- 違反に関係のない改善提案
- 一般的な建設的フィードバックの提供
- スコープや正当性のレビュー（それには review-scope を使用）
- ガイドにないスタイルの好みのフラグ
これはバイナリゲートです: 承認（accept）か違反（violations）かのみです。