agentsclimarketplace

Ai code verification

Skill goonobu-dot/dev-skills-library/skills/ai-code-verification

15 auto-selectable Claude Code skills distilling engineering best practices (Kent Beck, Fowler, Google SRE, OWASP, Anthropic, Netflix…), with a bilingual offline learning site. Make Claude Code write better code — and learn the practices yourself.

Install
npx -y skills add goonobu-dot/dev-skills-library --skill ai-code-verification

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Verification discipline for AI-generated code: close the loop with tests/build/run before declaring done, detect hallucinated APIs and dependencies (slopsquatting), spot tautological tests, avoid premature abstraction, and run an adversarial review from a fresh perspective. Use when about to report any coding task as complete, when reviewing AI-written code, when adding new dependencies, or when the user says 本当に動く?, 検証して, AIが書いたコード. Applies proactively to the agent's own output. For general review standards use code-review-standard — this skill adds the AI-specific checks on top. Hand off diagnosing the cause of a failing test or build to systematic-debugging. Not for test suite architecture (use test-suite-design).

SKILL.md

8.2 KB, as published. Nobody here has run it

AI Code Verification

AIが生成したコードは構文的には整っているが、確信を持って微妙に間違っていることが多い。「もっともらしいが検証されていない実装」（trust-then-verify gap）は最大の失敗パターンであり、検証ループを自分で閉じない限り、この確認は常に人間の仕事として残り続ける。

鉄則（Iron Law）

  1. 「完了した」ではなく「チェックが通った」を完了の定義にする。 実行可能な検証（テスト・ビルド・lint・実行結果）がないまま「動くはず」で報告しない。
  2. importやメソッド呼び出しの実在を仮定しない。 生成直後に定義へジャンプして確認する。存在しないAPIを平然と使うのがAI生成コードの典型的な失敗モード。
  3. 依存関係は追加前に必ず実在確認する。 LLMが提案するパッケージ名の一定割合は実在しない。lockfileにない名前は fail closed（追加を許可しない）。
  4. 抽象化は rule of three で判定する。 3つの具体的ユースケースが揃うまで共通化・抽象化しない（AIが起こしがちな「早すぎる抽象化」への検証観点。恒常的な設計規律としては deep-module-design を参照）。
  5. 自己レビューはバイアスがかかる。 実装した本人（同一コンテキスト）による確認だけで完了とせず、可能ならフレッシュな視点での再検証を挟む。

作業手順

ステップ1: 検証基準を先に決める

  1. 実装前に「何が確認できれば完了と言えるか」を明確にする（期待する入出力、テストケース、ビルドコマンド）。
  2. 検証手段が用意できない変更は、着手前にどう検証するかを決めてから進める。

ステップ2: ハルシネーションAPIを検出する

  1. 生成コードが呼び出しているimport・メソッド・クラスについて、実在を仮定せず定義にジャンプ（grep/検索）して確認する。
  2. 新規コードが既存コードベースの慣習に沿っているか確認する。学習データ由来の別アーキテクチャ・別フレームワークの流儀を持ち込んでいないか疑う。

ステップ3: 依存関係の追加を検証する（slopsquatting対策）

  1. 新しい依存関係を提案したら、レジストリ（npm/PyPI等）に実在するか確認する。
  2. メンテナの妥当性（登録者、ダウンロード数、最終更新日）を確認してから追加する。
  3. lockfileにない名前でのインストールは許可しない。
  4. 既にプロジェクトで使っているライブラリの中から選ぶことを優先し、未検証の新規パッケージの提案は最小限にする。

ステップ4: テストの実効性を確認する

  1. 各テストについて「バグを仕込んだら本当に落ちるか」を自問する。
  2. モックが期待値をハードコードしているだけの同語反復テスト（tautological test）になっていないか確認する。実装の出力をそのままアサーションにコピーしていないかを見る。
  3. 幸せパスだけでなく、null入力・タイムアウト・空結果・並行アクセス・部分失敗などの異常系を必ず辿るテストがあるか確認する。

ステップ5: 検証ループを実行し証拠を残す

  1. テスト実行・ビルド・lintを実際に走らせる。
  2. UI変更は元デザインとスクリーンショットを比較し、差分をリストして修正する。
  3. ビルド失敗や検証失敗を、症状の抑制（テストを緩める、エラーを握りつぶす）で片付けない。根本原因を特定してから直す。
  4. 実行結果（テスト出力、コマンドの戻り値、スクリーンショット）を完了報告の証拠として提示する。

ステップ6: アドバーサリアルレビュー（独立視点での再検証）

  1. 実装が一段落したら、可能であれば独立したコンテキスト（サブエージェント等）に差分と検証基準だけを渡し、計画とのギャップを報告させる。実装時の試行錯誤や理由づけは見せない。
  2. レビュー観点は「正しさ・要件充足に関わるギャップ」に限定する。スタイル選好や好みの書き方の指摘は無視してよいと明示する。
  3. 指摘は全て追いかける必要はない。正しさに関わるものだけ対応する（レビュー担当は指摘を見つけるよう仕向けられているため、過剰対応・過剰設計を防ぐ）。

チェックリスト

生成直後:

  • すべてのimport・API呼び出しの実在を確認したか（存在を仮定していないか）
  • 新規依存関係はレジストリで実在・妥当性を確認したか
  • lockfileにない依存を無検証で追加していないか

完了報告前:

  • テスト・ビルド・lintを実際に実行し結果を確認したか
  • テストは「バグを仕込んだら落ちる」実効性があるか（同語反復になっていないか）
  • 異常系（null・タイムアウト・並行・部分失敗）を辿るテストがあるか
  • 抽象化は3ユースケース揃う前に導入していないか
  • 独立視点での再検証（アドバーサリアルレビュー）を挟んだか、または挟めない理由が明確か

アンチパターン集

やりがちな思考現実
「このAPIは存在するはず、よく使われる名前だし」LLMは尤もらしい名前を生成するのが得意なだけで、実在の保証にはならない。定義にジャンプして確認する
「パッケージ名を思いついたのでそのままインストールしよう」存在しないパッケージ名は攻撃者に先回り登録される（slopsquatting）。lockfile照合とレジストリ確認を先にする
「テストが全部greenだから完了」greenであることと実効性があることは別。バグを仕込んでも落ちない同語反復テストが紛れていないか確認する
「念のため共通化しておこう」3ユースケース揃う前の抽象化は過剰設計になりやすく、後の変更を逆に難しくする
「自分で書いたコードだから自分で見れば十分」同一コンテキストでの自己レビューは実装時の推論に引きずられる。フレッシュな視点でしか気づけない齟齬がある
「ビルドが通らないのでとりあえずエラーを握りつぶそう」症状の抑制は根本原因を隠すだけ。原因を特定してから直す

出典

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.