mcpField
A
audit-verify-explain-grade-5

audit-verify-explain-grade-5

github.com/akillnessテスト・品質5358 回インストール今日更新
リポジトリ

audit-verify-explain-grade-5 について

開発者や技術チーム向けに、変更や主張を監査し、直接的な証拠で確認して、結果を平易に説明するスキルです。確認できた点と未確認の点を明示します。

主な機能

  1. 01変更や主張の監査
  2. 02テストと証拠による検証
  3. 03事実と判断の区別
  4. 04技術的な発見を平易に説明
  5. 05検証範囲の制約を報告

活用シーン

  1. 01コード変更を採用前にレビュー
  2. 02修正が機能するか確認
  3. 03性能改善の主張を検証
  4. 04テスト結果を非技術者に説明

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/akillness/jeo-skills --skill audit-verify-explain-grade-5

インストール後、Claude Code で/audit-verify-explain-grade-5を入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlSKILL.toon

詳細

監査、検証、説明

このスキルを使う場面

  • ユーザーから、変更、修正、主張を信頼する前にレビュー、監査、確認するよう求められた場合。
  • テスト、アプリの実行、ログ、スクリーンショット、成果物など、具体的な証拠に基づいて結果を検証するよう求められた場合。動作すると決めつけてはいけません。
  • テスト結果の要約や、実際に動作するかどうかの確認を求められた場合。
  • 技術的な指摘、差分、修正内容を、技術に詳しくない人にも分かる小学5年生向けの言葉で説明するよう求められた場合。
  • パフォーマンスや改善の主張を、思い込みではなく測定した証拠に基づいて確認する必要がある場合。
  • 監査、検証、説明の手順を伴わない、新しいコードやコンテンツの作成だけが目的のタスクや、専門家向けの高度に技術的で専門用語の多い説明を求められた場合は、このスキルを使わないでください。その場合は、通常の実装または執筆ワークフローに振り分けてください。

基本ルール

回答では、次の3つを行います。

  1. 変更された内容や主張を監査します。
  2. 直接的な証拠を使って検証します。
  3. 読者を賢い初心者と考え、分かりやすく説明します。

ローカルファイル、コマンド、ログ、テスト、スクリーンショット、ソースデータが利用できる場合、検証を省略してはいけません。推測しただけの内容を、検証済みであるかのように述べてはいけません。

ワークフロー

1. 監査

まず、信頼できる情報源を特定します。

  • コードの変更では、差分、変更されたファイル、関連する呼び出し元、既存のテストを調べます。
  • バグ修正では、修正前後の動作と、ユーザーが操作する経路を特定します。
  • パフォーマンスに関する主張では、測定された証拠と、改善が見込まれる点を分けます。
  • リリースやアプリの動作では、可能であればパッケージ化された成果物や実行中の成果物を確認します。
  • ドキュメントやコンテンツでは、ユーザーの依頼と実際に作成された成果物を照らし合わせます。

次の点を確認します。

  • 明らかなバグやデグレード
  • 考慮されていないエッジケース
  • 古くなった前提
  • 検証されていない主張
  • 実装とユーザーの意図の不一致
  • 小学5年生向けに説明することで、かえって見えにくくなるリスク
2. 検証

次の順に、証拠を優先します。

  1. 自動テスト、ビルド、リンター、型チェック、バリデーター。
  2. 実際のアプリまたはワークフローの実行。
  3. ログ、プロセスの確認、スクリーンショット、生成された成果物、実際の出力。
  4. 実行が現実的でない場合の静的なコード確認。
  5. それ以上の確かな証拠がない場合は、推論であることを明記します。

検証に失敗した場合は、妨げとなった要因と、その意味を報告します。検証が部分的な場合は、何を確認し、何を確認できなかったのかを正確に伝えます。

パフォーマンスに関する作業では、過度な主張を避けます。コード上、明らかに繰り返しの処理がなくなっている場合に限り、「繰り返しの処理をなくしました」と述べます。実行時間の記録がない場合は、「改善する見込みがあります」と述べます。変更前後の測定がある場合に限り、「測定の結果、速くなりました」と述べます。

3. 分かりやすく説明する

ユーザーを見下すことなく、小学5年生にも分かる言葉を使います。

  • 短い文を使います。
  • 技術用語は、平易な言葉で説明します。
  • 本当に役立つ場合に限り、簡単なたとえを1つ使います。
  • 何が変わったのか、なぜ重要なのか、どうテストするのかを伝えます。
  • 重要な注意点を隠さずに示します。

次の形式を優先します。

What changed:
- ...

Why it matters:
- ...

How I verified it:
- ...

What is still not proven:
- ...

回答がごく短い場合は、見出しを無理に付けず、短い段落にします。

説明の基準

技術的な考え方は、次のように説明します。

  • 「キャッシュ」→「同じ質問を繰り返さなくて済むように、答えを覚えておくこと」
  • 「メタデータ」→「ファイルのサイズや更新日など、ファイルについての簡単な情報」
  • 「デグレード」→「以前は動いていたものが、動かなくなること」
  • 「成果物」→「作成された実際のファイルやアプリ」
  • 「静的検査」→「コードを実行せずに読むこと」

ワークフロー全体をテストしていない限り、「すべて正常に動作します」と言ってはいけません。システムの一部だけを検証した場合は、「確認した部分は動作しています」と伝えます。

出力ルール

回答を最初に示してください。落ち着いた明確な口調を保ってください。

根拠となるファイルパス、コマンド、コミットハッシュ、テスト名、ログの抜粋を記載してください。簡潔にまとめてください。

事実と判断を分けてください。

  • 事実：「テストに合格しました。」
  • 判断：「これにより、タイムラインプランナーへの信頼度は高まりますが、エディター UI 全体への信頼度が高まるわけではありません。」

別のテストによって信頼度が大きく高まる場合に限り、最も有用な次のテストを最後に示してください。

参照

コメント

Markdown 対応