Claude Code Skillsで手動確認を検証ループへ変換

Claude Blogは、実装後に人が繰り返す確認作業をSkillsへ記述し、Claude自身が修正と再検証を回す方法を紹介しました。

要点

• 型検査、リンター、テストに加え、プロジェクト固有の手動確認も検証ループにできます。
• 単独、生成Skillへの組み込み、複数Skillの連鎖、PRごとの自動実行という配置があります。
• 成否条件と正確なコマンドを明文化し、実タスクでループが閉じるか試す必要があります。

今回のブログ記事で語られていること

Claude Codeは、型検査、リンター、テスト、実行時エラーなど決定的な信号を観察して修正できます。しかし、画面の見え方、設計文書との一致、移行時のバックフィル、アクセシビリティなど、人が毎回確認する項目は自動的には分かりません。記事は、その手順を平易な文章で書き、Skillsとして再利用することで、Claudeが確認、修正、再確認を繰り返せると説明します。ビルドやテストの正確なコマンドをCLAUDE.mdへ記録することも勧めています。

既存の仕組みとして、アプリをビルドして観察する/verify、PRを別のエージェントが確認するコードレビュー、GitHub Actions、仕様書との一致確認、別の採点エージェントを使うRubricsが挙げられます。独自ループを作る際は、人が毎回直している小さな問題を書き出します。「列を削除する移行にはバックフィル手順が必要」のように、一般的なリンターでは扱えない規則も対象です。

配置方法は四つあります。単独Skillは必要なときだけ実行します。組み込みは生成Skillの末尾へ検証を加えます。連鎖はコードレビュー、簡素化、検証、デザイン確認などを順に呼びます。PRごとの実行は、個人が呼び忘れても同じ基準を適用します。組み込みは自分で編集できるSkillに限り、プラグイン管理や内蔵Skillにはラッパーを使います。連鎖を増やすと費用も増えるため、小さな実タスクで失敗時に本当に再作業へ戻るかを確認することが重要です。

検証Skillには、読む対象、実行順、合格条件、修正してよい範囲、判断を人へ戻す条件を記述します。チェックが曖昧だと、合格を主張するだけで問題を再現できません。既知の失敗を含む小さな変更で試し、その失敗を検出して修正後に再検証できることを確認するとよいです。

今回のブログ記事が関係する人

Claude Codeを使う開発者、チーム標準を管理する担当、CIやPRレビューを設計するプラットフォームチームに関係します。

結局、今回のブログ記事をどう読むべきか

プロンプトを増やす話ではなく、人の確認習慣を実行可能な契約へ変える設計です。検査を置いただけで終わらず、失敗から修正へ戻る動作を試す必要があります。