dsh 自動コードレビュー：レビュープリセット、ワークベンチ監査、修正のディスパッチ
実際の DeepSeek Harness 環境が自分のプラグイン リポジトリをどうレビューするか：読み取り専用のレビューエージェントがチェックリストスキルで項目ごとに確認し、変更はガードスクリプトとテストを通らなければ完了とみなされず、ワークベンチは README とランタイムの挙動の食い違いをその場で検出します。
最終更新: 2026-09-29
「AI コードレビュー」のデモの多くは「モデルが diff にコメントした」で終わります。この 16 分のスクリーン録画（Ubuntu VM 上の dsh Web UI、モデルは DeepSeek-V4-Flash）は、もう一歩踏み込んだ構成を見せてくれます。レビューは独立した読み取り専用エージェントが担当。すべての変更は可搬性ガード 37 項、テスト 19 スイート、アサーション 1,347 を通らなければ完了扱いになりません。さらに各プラグインの README の約束とランタイムで実際に登録されるものを照合するワークベンチ UI まであります。
動画に登場するワークベンチやプリセットは作者自作のプラグイン（Gitee の hecong_dsh_plugins リポジトリで公開）で、dsh の組み込み機能ではありません——ただしパターン全体は標準のプリセット体系で再現でき、その基礎は Agent プリセット実践
20 秒で分かるこのやり方
- ▸読み取り専用のレビュー専用プリセット（風控）を別に作り、code-risk-audit のチェックリストでコードリスクを審査——入力境界、パスと権限、エンドポイントと認証情報、データ整合性、テスト品質——file:line と再現手順付きの所見を出します。
- ▸コーディングプリセットには独自の規律があります：まずドメイン規約とスキルを読み、変更後は必ずプリフライトとテスト——デモの報告ではガード 37 項合格、プリフライト exit 0、19 スイート / 1,347 アサーション。
- ▸コーディングプリセットの PTC（Code Mode）兄弟版は一括巡回に向きます：モデルが 1 本の TypeScript プログラムを書いて複数のツール呼び出しを組み合わせ、何度もプロンプトを送り直しません。
- ▸プラグインワークベンチはリポジトリ全体を監査——158 プラグインを 7 依存レイヤーにカード展示——README とランタイムの不整合もその場で検出。修正は「開発タスク」としてディスパッチし返せます。
レビューループを順番に
レビュアーとレビュー対象をそろえる
- 1
レビュアーに読み取り専用プリセットを与える
設定 → Agent プリセットで、作者はレビュー業務を「風控」（risk-audit）という別のカスタムプリセットに分けています。説明文がそのまま仕様書です：読み取り専用のレビューエージェントがスキル code-risk-audit のチェックリストに沿ってコードリスクを審査し（入力境界、パスと権限、エンドポイントと認証情報、データ整合性、テスト品質）、file:line と再現手順付きの所見を出します。修正は agent_ask 経由でコーディングエージェントに引き渡し、自分では書き換えません。隣にはコーディング用プリセット：插件编码（まずドメイン規約とスキルを読み、変更後は必ずプリフライトとテスト）と、その PTC 兄弟版——このセッションで「使用中」表示なのは後者です。
設定 → Agent プリセット：読み取り専用レビュアー、コーディングプリセット、PTC 版が同じ画面に。12:30 の場面を見る - 2
プリセットが実際に何をマウントするか確認する
Agent ワークベンチは「プリセット → プラグインフロー → セッション」の読み取り専用マップです。コーディングプリセットを選ぶと、2 枚の識別カード（plugin-dev と plugin-dev-ptc）、それぞれが取り込む 16 個の会話レベル プラグイン、その下の L3 能力プロバイダー——fs-sandbox、subprocess、jobs、skill、goal、web、settings、セッション永続化——が見えます。右側のマウント済みセッション パネルは各セッションをワークスペース パスとモードに紐付け、レビュアーとコーダーが同じコンテキストを共有しないことを走らせる前に確認できます。
Agent ワークベンチはプリセット → プラグインフロー → セッションを読み取り専用のマップに描きます。13:00 の場面を見る
レビューを実行し、3 層の報告を読む
- 3
レビューを実行し、3 層すべての報告を読む
録画の冒頭はリポジトリ監査を終えた場面で、報告書はリリース チェックリストのように読めます。所見層：エージェント自身が書いたファイルの権限が 600 だったため chmod 644 に変更。一方で既存の 600 ファイル 59 個はローカル umask による元からの状態なので触らなかった——git が記録するのは実行ビットだけだから、と報告が説明します。検証層：可搬性ガード 37 項合格、プリフライト exit 0、全体テストは 19 スイート / 1,347 アサーション。境界層：ライセンスの署名は作者自身が決めるべきこと、そして git commit はしていない——コミットは意図的に人間に残した、と明言します。
報告は 3 層構造：所見、機械検証、そして明示された境界。0:30 の場面を見る - 4
ワークベンチでリポジトリ全体を診断する
プラグインワークベンチはリポジトリの全プラグインをカードで描画します：158 個の実行レベル プラグインを 7 依存レイヤーに整列（L0 基盤：credentials、isolate、loader、locale、storage。L1 転送：api-gateway、webserver）、各カードに provide/call/send バッジと違反カウント付き。機能ドメイン ビューに切り替えると、同じプラグイン群がメディア生成・音声・ビジョン・小説・ライブ・プラットフォームのドメインごとにグループ化——停止中のプラグインは赤、事故レベルはタグ表示されます。レイヤーとドメインのカウンタは生きていて、プラグインをアンロードすればビュー間を移動します。
機能ドメインビュー：赤は停止中のプラグイン、観測ツールはプラットフォームドメインに。9:10 の場面を見る - 5
README の主張とランタイムの食い違いを捉える
プラグインカードを開くと、宣言とランタイムの実際を並べた「宣言 vs 事実（README とランタイムの不一致）」欄が現れます。audio-player の例では、consumes/listen の項目のうち webServer「ルートを登録し提供する」は README にだけ存在し、ランタイムにだけあるもの、両方にあるものも——目視では見抜けず、統合時に確実に壊れる種類のドキュメント腐敗です。説明文はその場で編集でき、ソースはプラグインの README でファイル パスも併記されます。
宣言 vs 事実：ワークベンチは README とランタイム登録を項目ごとに照合します。6:30 の場面を見る
修正をディスパッチし、再検証して公開
- 6
修正をチャット メッセージではなくタスクとしてディスパッチする
同じダイアログが所見を仕事に変えます：説明欄に望む挙動を書き（「xxxxx 機能を担当してほしい」）、ツールバーの「保存して AI 開発へ」、「開発」タスクへ引き渡すブループリント版、セッション再チェックの 3 つのアクションを使います。ダイアログは自身の未保存状態（「変更あり、未保存」）を管理し、セッションの作業ディレクトリも表示——編集はコーディングエージェントが後で走るのと同じワークスペースに着地します。
所見はタスクに：説明を書いてディスパッチ、チャットへのコピペは不要。11:00 の場面を見る - 7
bootstrap と preflight で最後の門を守る
録画の結びは作者が Gitee に公開したリポジトリ（hecong_dsh_plugins、MIT）で、README はこの規律を 2 つのコマンドに収めています：bootstrap はビルド依存のインストール、シンボリックリンク修復、成果物ビルド、セルフチェック。preflight は終了コード 0 を返して初めて dsh の起動に進めます。前提条件テーブルは Node.js 18 以上（v22/v24 で実測）、npm は任意バージョン、初回のみ esbuild と winbox のためにネットワーク必要——以後はオフラインで動く。これがレビューループの最後の性質です：機械が検証する門はリポジトリの中にあり、誰かの記憶の中にはありません。
$node scripts/bootstrap.mjs$node scripts/preflight.mjs
公開されたリポジトリはこの規律を 2 コマンドに収めます：bootstrap、そして preflight。15:50 の場面を見る
よくある質問
何が組み込みで、何が作者自作か、何を真似すべきか。
プラグインワークベンチや風控レビューは dsh の公式機能ですか？
いいえ。ワークベンチ、「風控」レビュープリセット、「插件编码」プリセットはいずれも動画作者が自作した Cordis プラグインで、Gitee の hecong9402/hecong_dsh_plugins リポジトリ（MIT）で公開されています。dsh 本体に組み込まれるのは 4 つの標準プリセット（標準・PTC・最小・Creator）です。動画が示しているのはパターン——読み取り専用レビュープリセット、リポジトリに置かれた検証スクリプト、ランタイム巡回 UI——で、どれも dsh のドキュメント化された仕組みで再現できます。
code-risk-audit のチェックリストは何を見ますか？
動画のプリセットカードによれば：入力境界、パスと権限、エンドポイントと認証情報、データ整合性、テスト品質。所見には file:line の位置と再現手順が付きます。これは作者マシン上のカスタムスキルなので、自分でチェックリストをスキルとして書き、レビュープリセットに向けることももちろん可能です。
レビュアーを読み取り専用にする理由は？
コードを審査するエージェントが、書いた本人と別であり続けるために。プリセットの説明文は「審査するが直さない」で終わり、所見は agent_ask 経由でコーディングエージェントに引き渡されます。この分離により「できた」（コーダー）と「まだ問題がある」（レビュアー）という 2 系統の報告が自然に手に入ります。ステップ 3 の報告書がまさにその構造です。
一括巡回に PTC 版を使う理由は？
PTC プリセットのカード自身が説明しています：Code Mode 方式でツールを提示——モデルが 1 本の TypeScript プログラムを書いて複数のツール呼び出しを組み合わせる——ので、リポジトリの一括スキャンや検証の再実行のような「何往復もする」作業に向きます。ステップごとのコード変更は通常のコーディングプリセットで行い、1 作業ずつ見守れます。
関連ガイド
ドキュメント化された部品で同じループを組み立てる。
ソースとクレジット
本ページのスクリーンショット 8 枚はすべて下記の Bilibili 動画（1080p・字幕トラックなし、画面文字はフレーム単位で照合）から取得し、各画像に元のタイムスタンプへのリンクを付けています。動画のワークベンチとプリセットは作者自作のプラグインで、Gitee の hecong9402/hecong_dsh_plugins リポジトリ（MIT）で公開されており、README は 2026-09-29 に動画と照合済みです。ページの文章はすべてオリジナルで、動画の字幕を転載したものではありません。