coding-standards-a3ef2c — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited coding-standards-a3ef2c (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
以下のパターンを検出したら実装を一時停止し、該当パターン、影響を受ける現行要件、準拠できる最小の代替案、再開に必要な検証を記録する。代替案によってパターンが解消された場合、または文書化された要件によって維持する根拠を示せた場合に再開する。
ユーザー・運用者・保守者に必要な価値を届けつつ、システムの正しさと保守性を保てる、総合的な複雑性が最も低い解をエビデンスから選べる範囲まで調査する。
総合的な複雑性は、この設計で増えるユーザーの判断・設定・モード・概念・出力・永続状態・実装経路と、それらに伴うUX・実行時・実装・テスト・文書・保守のコストで判断する。成立する案の間で実際に異なる観点だけを比較する。同じ確認済みの価値と証明をより低い複雑性で届けられる場合は、既存機能の再利用または新しい仕組みを追加しない案を選ぶ。
エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ。元の診断情報を保持したまま失敗を伝播するか、明示的な型付きエラーを返す。
詳細な実装方法（Result型、カスタムエラークラス、層別エラー処理など）は各言語・フレームワークのルールを参照。
Martin Fowler「Refactoring」に基づく重複コードの扱い方：
| 重複回数 | 対応 | 理由 |
|---|---|---|
| 1回目 | インライン実装 | 将来の変化が予測できない |
| 2回目 | 将来の統合を意識 | パターンが見え始める |
| 3回目 | 共通化実施 | パターンが確立された |
共通化すべきケース
分離したままにするケース
プロンプトで示されたパスは調査の起点である。別のリポジトリファイルが、受け入れ済みの成果を実装している、必要な依存または接続経路である、あるいは今回影響を受ける契約を保つために変更を要するとエビデンスが示す場合は、そのファイルも変更対象に含める。呼び出し元、利用側、テスト、設定、import、データフローは判断材料であり、必ずすべてを確認するチェックリストではない。
パターン、API、依存を採用する際は、対象機能と、同じ責務・現行契約を共有するリポジトリ内の利用箇所を調べる。その責務で互換性を保っている実装を優先する。使用頻度は候補の発見には役立つが、パターンの正当性を決めるものではない。複数の方式が共存する場合は、呼び出し元、ライフサイクル、互換性から、現行パターンとレガシーまたは無関係な方式を区別する。
外部依存のバージョンは、マニフェスト、ロックファイル、互換性のある利用側から確定する。それらの情報でも互換性またはアーキテクチャに関わる選択を確定できない場合にのみエスカレーションする。
症状: エラーを修正すると新しいエラーが発生 原因: 根本原因を理解せずに表面的な修正 回避方法: 5 Whysで根本原因を特定してから修正
症状: どのチェックも契約も裏付けていない型を any や as で宣言している 原因: 型エラーを回避したい衝動 回避方法: 「型安全性の基礎」の根拠に関する基準を適用する。
症状: 実装後にバグ多発 原因: 受け入れ済みの振る舞いを証明するテストがない 回避方法: 届ける各振る舞いを、それを観測できる境界で証明する
症状: 前提の誤りが判明した時点で、その前提に依存した作業が失敗する、または回避策が積み重なる 原因: 想定した機能、振る舞い、既存実装を事実として扱う 回避方法: 未検証の前提が、選んだアプローチを成り立たなくする可能性がある場合は、その前提に依存する作業を進める前に、十分な範囲で最もコストの低い手段で確認する。結果が前提と矛盾した場合は、部分ごとの修正を重ねる前にアプローチを見直す。この判断は今回のタスク内で行い、別の成果物は作らない。
症状: 重複実装、アーキテクチャ不整合、結合時の障害、古いパターンの採用 原因: 実装前の既存コード理解不足、近隣ファイルのみ参照し代表性を確認していない 回避方法:
各回答を観測済みの根拠に結び付け、修正によって元の失敗を防げる原因に到達するまで掘り下げる。各質問、根拠、最終的な因果関係を記録する。次の回答が推測になる時点で止め、必要な根拠を明記する。
型安全の原則: 型の絞り込みには、実行時の検査または既存の契約を根拠とする。型ガードが保証する型は、実際の検査内容に一致させる。
unknown を用い、利用側が必要とするプロパティを検証する。型の複雑性管理
基本方針
実施手順: 現状把握 → 段階的変更 → 動作確認 → 最終検証
優先順位: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
実装の前に、変更するコードの呼び出し元、依存関係、データフロー（生成→変更→参照）を、「変更境界と参照の代表性」で定める変更境界を別のファイルが変えなくなるまで追跡する。実装やその検証が依拠する直接・間接の影響は、その作業に引き継ぐ。
未使用コードを検出したら、タスク完了までに、現行要件と到達可能な呼び出し経路から使用されているかを判断する。
対象: コード・ドキュメント・設定ファイル
推奨: 単体テストでの外部依存モック化
Unit testの境界: 外部接続には決定論的な代替を使用する。実際の外部境界は、その契約を対象として選定したIntegration testまたはE2E testで検証する
テストを修正: 間違った期待値、存在しない機能参照、実装詳細への依存、テストのためだけの実装 実装を修正: 妥当な仕様、ビジネスロジック、重要なエッジケース どちらの解釈も参照できる要件と両立する場合: 未解決の振る舞い判断として差し戻す — 2つの候補となる振る舞い、どちらが正しいかを決める出所、および一方を選ばず停止する条件を示す
観測可能な境界を通じてテストする：公開API、戻り値、例外、外部呼び出し、永続化された状態を検証する。privateメソッド、内部状態、アルゴリズムの詳細は、これらの観測可能な境界を通じてのみ到達する。
references/security-checks.mdを参照~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.