DeepSeek Harness ベストプラクティス

製品の事実をチーム方針から分離する

操作する前に、小さな範囲を読み取る

1. 01

   最初にプロジェクト指示を読む

   リポジトリ直下と下位ディレクトリにある指示ファイルを特定し、対象パスへ適用されるルールを確認します。

2. 02

   関連する範囲だけを調べる

   対象ファイル、テスト、設定、直近のローカル変更を読んでから、必要に応じて検索範囲を広げます。

3. 03

   変更内容と必要な証拠を明示する

   対象ファイル、期待する観測結果、検証コマンド、ロールバック地点を記録します。

4. 04

   可逆的な単位で変更する

   一度に行うのは一貫した変更 1 つにし、次の段階へ進む前に差分を確認します。

必要最小限の権限セットを使う

認証情報をプロンプトやリポジトリへ入れない

• 現在の操作に必要な最小限の認証情報だけを渡します。可能なら、適用範囲を限定したプロバイダー設定や短命トークンを使います。
• チャット、プロジェクト指示、ログ、スクリーンショット、fixture、コミット対象の環境ファイルへ秘密情報を貼り付けてはいけません。
• 差分や成果物を共有する前に、追跡済み・未追跡の変更を対象に、秘密情報や機密性の高いローカルパスをスキャンします。
• 漏えいの可能性があれば、最初に認証情報を失効またはローテーションします。ファイルを削除するだけでは、コピー済みの認証情報は無効になりません。

すべての変更をロールバック可能に設計する

1. 01

   ベースラインを記録する

   現在のリビジョン、構成、テスト結果、操作で変わり得る外部状態を記録します。

2. 02

   非破壊的な操作を優先する

   範囲を限定した upsert、追加型 migration、復元可能なファイル移動、正確な対象指定を使い、広範囲の削除や reset を避けます。

3. 03

   差分全体を確認する

   意図した編集と既存のユーザー作業を区別し、生成ファイルが元のソースと一致していることを確認します。

4. 04

   失敗の影響が大きい場合は復旧をテストする

   パッケージ、migration、デプロイでは、リリース前にアンインストール、逆 migration、バージョンのロールバック、snapshot 復元を試します。

完了という説明ではなく、実際の動作を確認する

1. 変更した動作を直接証明する、範囲の狭いテストを実行します。
2. リスクに応じて、型、format、build、より広い回帰テストを実行します。
3. 実際の build と、関係するブラウザー、ランタイム、データベース、パッケージ経路を使ってテストします。
4. 終了コードだけに頼らず、console、network、log、データベース結果、出力成果物を確認します。
5. 失敗はそのまま記録します。再試行が証拠になるのは、元の原因を理解できている場合だけです。

Skills とプラグインをサプライチェーン入力として扱う

Skill は再利用可能な指示パッケージで、プラグインは実行可能な機能を追加できます。利用前にソースと要求能力を確認し、可能なら不変バージョンを固定し、ライセンスと checksum を検証し、隔離環境でテストします。さらに、管理責任者を記録し、更新・削除手順を定めます。名前だけを永続的に信頼せず、変更のたびに再確認してください。

境界から内側へ、順に障害を診断する

1. 最小の入力と、クリーンまたは使い捨てのワークスペースで再現します。
2. 有効な Profile、プラグインのバージョン、プロバイダー設定、ワークスペースルート、permission preset、報告された sandbox enforcement を確認します。
3. モデル出力の問題を、ツール、shell、network、認証情報、UI、永続化の障害から切り分けます。
4. 構造化イベントと log を調べ、正常と分かっているベースラインと比較します。
5. 一度に変数を 1 つだけ変えて同じ検証を再実行し、原因が確定するまで失敗時の証拠を保持します。