standards について
変更内容に関連する標準だけを読み込む、エンジニアリングレビュー向けのガイダンススキルです。コードレビュー担当者を対象とし、パスと行番号付きの指摘、および確認済み・未確認の範囲を明示します。
主な機能
- 01ファイル・言語・リスクに応じた標準選択
- 02パスと行番号付きの指摘
- 03確認済み・未確認範囲の明示
- 04実装前に言語ルールをインライン表示
- 05一括書き換えの安全策を確認
活用シーン
- 01セキュリティ上重要な変更のレビュー
- 02言語別ガイダンスに基づく変更確認
- 03一括フォーマッターやコード移行のレビュー
- 04実装前のコーディング規約提示
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ boshu2/ agentops --skill standardsインストール後、Claude Code で/standardsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/common-standards.mdgo.mdjavascript.mdjson.mdllm-trust-boundary-checklist.mdmarkdown.mdpython.mdrace-condition-checklist.mdrust.mdshell.mdskill-structure.mdsql-safety-checklist.mdtest-pyramid.mdtypescript.mdyaml.mdscripts/validate.sh詳細
Standards — 対象を絞ったエンジニアリングガイダンス
呼び出し元のファイル、言語、リスクに照らして必要な最小限の標準だけを読み込みます。リファレンス全体を事前に読み込まないでください。
プロンプト
Check standards for the changed files in fleet-router PR #214: cli/internal/auth/token.go and cli/internal/auth/token_test.go, Go, a security-sensitive change. Load only the matching references and report cited findings with path and line plus checked and not-checked scope.
できている状態
- レポートが
common-standards.mdと、該当する Go リファレンスだけを読み込み、リファレンス全体は読み込んでいません。 - すべての指摘に、
cli/internal/auth/token.go:18のようなパスと行番号が記載されています。 not_checkedが空の場合も含め、レスポンスでcheckedとnot_checkedの対象範囲を明示しています。git diff --statにテスト、ゲート、フィクスチャのファイル変更が表示されていません。標準レポートは指摘のみを報告します。
手順
- 提供されたパス、言語、変更の種類、リスクを示す要素を記録します。
common-standards.mdと、該当する言語またはチェックリストのリファレンスだけを読み込みます。- 提供された成果物を、それらの情報源と照合します。
- 可能な場合はパスと行番号を添えて指摘を返し、確認済みおよび未確認の範囲も示します。
- 停止します。
このスキルはコンテキストと指摘を提示します。編集、検証、再試行、承認、コミット、リリース、納品、継続の判断は行いません。
生成するコードで守るべき重要な規約(測定済み)
呼び出し元がコードをレビューするだけでなく、これから書く場合は、該当する言語のルールを作業コンテキストにインラインで提示します。リンク先のリファレンスでは動作は変わりませんが、インラインの命令なら変わります。Go の基本ルール:
- 伝播させるエラーにはすべてコンテキストを付けます:
fmt.Errorf("doing X: %w", err)— 内側のエラーをそのまま返すことは禁止です。 - 複数ケースを扱う関数には、テーブル駆動テスト(
[]structのケースとケースごとのt.Run)を作成し、エラーケースを含む期待値を正確に検証します。
他の言語では、以下から該当するリファレンスを取得し、同じ方法で最上位のルールをインラインで提示します。
2026-08-04 に
standards-go-conventionsプローブで測定(gpt-5.6-luna、N=2、方向性あり):対照条件では%wでラップする形式とテーブル駆動テストの形式が 1/2 回で生成されましたが、これらのルールをインラインで提示した場合は 2/2 回でした。インラインの命令はリファレンスへのリンクより優先されます。graphify プローブでは、リンクされたドキュメントの指示が守られたのは 0/2 回でした。記録:evals/skill-probes/LEDGER.md。
変更の安全性に関する標準
提供された変更が既存ファイルを一括で書き換える場合(フォーマッター、codemod、移行スクリプト、手書きのソースを対象にしたジェネレーターなど)は、次の 3 つの標準に照らして確認し、欠けているものがあればそれぞれ指摘として報告します。
- 監査可能な単一の変更経路。 すべての書き換えが、入力、出力、ドライランモードを確認できる、名前の付いた 1 つのコマンドまたはスクリプトを通じて行われます。場当たり的なワンライナーや手動修正に編集が散らばることは、変更経路の分散という失敗パターンです。監査、再実行、責任の特定を行える単一のポイントがありません。指摘:この変更経路の外にあるすべての変更手段を列挙します。
- 書き換え前のハッシュで検証できるバックアップ。 変更経路を実行する前に、元の内容を保存し、コンテンツハッシュを記録します(コミット済みのベースラインも該当します)。こうすることで、「書き換えによる変更は申告どおりの範囲だけだった」ことを主張ではなくバイト単位で確認できます。指摘:検証可能な変更前の状態を残さずに一括で書き換えています。
- 変更範囲を制限する独立したゲート。 この変更で意図的に触れない対象を明記し、差分もその範囲を守ります。名前変更も行うフォーマッターの実行や、リファクタリングも行う codemod は、スコープ拡大型の書き換えという失敗パターンです。指摘:差分に、この変更で明示された対象範囲外のファイル分類が含まれています。
この確認の停止条件:3 つの標準すべてについて、明確な合格判定または指摘があること。スタイル上の細かな指摘だけを報告し、これらを確認しない一括書き換えのレビューは不完全です。