Communitygithub.com

ritamgh/claude-skills

自動的にエビデンス契約を適用し、非自明な実装計画を作成・レビュー・修正する際に、計画内容をリポジトリの証拠に基づいて検証可能にします。

claude-skills とは?

このスキルは、AIエージェント(Claude Code、Cursor、Codexなど)向けに設計された「エビデンス契約」であり、実装計画の作成・レビュー時に、当て推量ではなく実際のリポジトリの証拠に基づく計画を強制します。計画内の各主張を「観測済み」「推測」「未知」に分類し、影響を受けるファイルや依存関係を特定した上で、各計画項目に実行可能な成功チェックを付与します。アーキテクチャ計画、機能計画、バグ修正、リファクタリング、移行、実装提案など、非自明な変更に自動的に適用されます。単一行の変更など自明なケースではスキップされ、手動で `/evidence-contract` と入力することでも呼び出せます。このスキールにより、計画の検証可能性と正確性が大幅に向上し、不確かな前提に基づく実装を防止します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ritamgh/claude-skills/tree/HEAD/skills/evidence-contract

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

エビデンス契約

テスト可能で、実際のリポジトリに基づいた計画を作成し、当て推量を排除します。

アクティベーション

タスクが非自明な実装計画または計画レビューを必要とする場合、このスキルを自動的に適用します。ユーザーが明示的に呼び出すのを待たないでください。

目標、動作、検証がすでに明らかである自明な変更については、完全な契約をスキップし、代わりに簡単なチェックを記述してください。

このスキルは計画専用です。ユーザーが計画の実行も依頼していない限り、実装ファイルを編集しないでください。

ワークフロー

1. 意図と成功条件を確立する

望ましい結果を一文で言い換えます。リクエストから具体的な受け入れ動作を抽出します。表現が曖昧な場合は、ユーザーに質問する前にリポジトリを調査します。調査後も実質的に異なる結果が残る場合にのみ質問してください。

2. 最小限の十分な証拠を収集する

アーキテクチャを提案したり、影響を受けるファイルを命名したりする前に:

  1. PROJECT_CONTEXT.md が存在する場合はそれを読む。
  2. 対象を絞った検索で機能のエントリポイントを特定する。
  3. 関連する実装ファイル、設定ファイル、テストファイルの最小セットを読む。
  4. 重要な呼び出し元、依存関係、永続化の境界、公開インターフェースをトレースする。
  5. ドキュメントとコードの矛盾を記録する。コードと実行可能な動作をより強い証拠として扱う。

対象を絞った証拠で十分な場合、広範なリポジトリスキャンは避けてください。

3. すべての重要な主張を分類する

以下のラベルを内部で使用し、有用な場合に公開します:

  • 観測済み: ファイル、シンボル、コマンド結果、テスト、またはランタイム観測によって直接サポートされている。
  • 推測: 観測された証拠から強く示唆されるが、直接実証されていない。
  • 未知: 確立されていない重要な情報。

推測または未知の主張を事実として提示しないでください。重要な観測済みの主張には、コードの場所またはツールによる観測結果を含めてください。ファイルパス、API、依存関係、既存の動作をでっち上げないでください。

4. ブロッキングとなる未知の項目を解決する

アーキテクチャ、スコープ、データフロー、互換性、または受け入れ動作を変える可能性のある未知の項目を調査します。未知の項目がローカルで解決できない場合:

  • それを明示的に述べる、
  • なぜ重要かを説明する、
  • 最も安全な制約付き仮定を提案する、そして
  • 間違った結果を生む可能性がある場合のみユーザーに質問する。

5. エビデンスでゲートされた計画を作成する

すべての非自明な計画項目には以下を含める必要があります:

  1. 変更: 最小の一貫した実装ステップ。
  2. 証拠: そのステップを正当化する、観測されたリポジトリの事実(関連するパスやシンボルを含む)。
  3. 影響範囲: 変更される可能性のあるファイル、インターフェース、データ、呼び出し元、依存関係、またはワークフロー。
  4. 成功チェック: 実行可能なテスト、ビルド、リンター、ランタイム、または受け入れ観測。
  5. リスクまたは前提: 重要な場合のみ、推測または未知としてラベル付け。

1つの要件を1つの観測可能なチェックにマッピングする計画を優先します。バグ修正や互換性に敏感な変更には、回帰テストを含めてください。

6. 計画ゲートを実行する

計画を提示する前に、以下を確認してください:

  • 要求された各結果が少なくとも1つの計画項目にマッピングされている。
  • 各計画項目に証拠と具体的な成功チェックがある。
  • 名前付きのファイルとシンボルは観測されたものであり、推測ではない。
  • 重要な前提が可視化され、分類されている。
  • 依存関係と統合境界がカバーされている。
  • 計画はリクエストを満たす最小の変更を使用している。
  • 推測的な機能や無関係なリファクタリングが追加されていない。

ゲートに失敗した場合は、計画を返す前に調査または修正してください。

出力形式

タスクが複雑でない限り、結果は簡潔に保ちます。

## エビデンス契約
- 観測済み: `path/to/file` により ... が確立される
- 推測: ... なぜなら ...
- 未知: ...; 制約付きの仮定または必要な決定 ...

## 計画
1. **変更** ...
   - 証拠: ...
   - 影響: ...
   - 検証: ...
   - リスク/前提: ...

## 完了ゲート
- [ ] 要件からチェックへのマッピングが完全である
- [ ] ラベル付けされていない前提が残っていない
- [ ] 受け入れチェックが実行可能である

空の推測または未知のセクションは省略します。小規模な計画では、各項目を1行に圧縮しつつ証拠と検証を保持します。

アンチパターン

以下を行わないでください:

  • ファイル名だけで計画を立てる、
  • 推測とマークせずに「おそらく」「たぶん」「~すべき」を使用する、
  • テストを実行せずに合格したと主張する、
  • 利用可能な実際の受け入れパスをモックされたチェックで代用する、
  • リポジトリから回答可能な質問でユーザーに負担をかける、
  • 自明な変更に対して契約を書類作業に変える、
  • 計画が完了したという理由だけで実装を開始する。

関連スキル