Communityコーディング&開発github.com

WinMedic

Windows PC 修繕:診断、クリーンアップ、移行、修復。ディスク容量、起動・パフォーマンス、アプリライフサイクル、更新・ドライバ、ネットワーク、セキュリティ状態、復旧トリアージをカバー。読み取り優先、破壊的操作は隔離領域で行いロールバック対応、各提案に証拠を添付。

WinMedic とは?

WinMedic は、Windows コンピュータの診断、クリーンアップ、移行、修復をエージェント駆動で行うスキルです。ホストエージェントを推論層、ローカルの PowerShell エンジンを実行層とし、まず証拠を収集して原因を特定してから最小限の修復を提案し、ユーザーの承認を得て実行、検証します。対応範囲はディスク容量(C ドライブ不足など)、起動・パフォーマンス遅延、アプリのインストール/アンインストールの残骸、Windows Update やドライバの障害、ネットワーク問題、ブルースクリーン、ファイル復旧など多岐にわたります。すべての操作は読み取り優先で、削除などの破壊的操作は隔離領域で行われ、ロールバックが可能です。各提案には証拠が添付されるため、ユーザーは納得して操作を進められます。このスキルは単独のモデルを起動せず、インターネットにも接続せず、テレメトリも収集しません。ホストの権限と承認メカニズムに常に従います。対応プラットフォームは Claude Code、Cursor、Codex など、ローカルの PowerShell を実行できるエージェントです。

対応~Claude Code~Codex CLI~Cursor
npx skills add Awenforever/winmedic-skill

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

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

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

ドキュメント

WinMedic は何をしますか?

目標

ホスト Agent を推論層、ローカルの PowerShell と内蔵エンジンを実行層として使用します。まず証拠で原因を特定し、最小限の修復を提案、確認後に実行し検証します。

本 Skill は単独のモデルを起動せず、インターネットに接続せず、テレメトリを収集しません。常にホストの権限と承認メカニズムに従います。

実行前チェック

  1. プラットフォームが Windows、Shell が PowerShell、現在管理者権限かどうかを確認します。ユーザーの説明から推測しないでください。
  2. 作用範囲がローカルマシンであることを確認します。ユーザーが指定した保留項目(「WeChat を触らない」「D ドライブを消さない」など)は制約として書き留め、常に遵守します。
  3. engine\winmedic.ps1 doctor を実行し、権限/PS バージョン/WizTree の可用性を取得します。
  4. ホストにローカル実行能力がない場合(チャットのみ)、「手動手順 + 検証ポイント」モードで出力し、実行を偽装しません。

強制ワークフロー

1. 目標明確化

  • 症状、期待状態、変更不可な制約に分解します。
  • 複数の目標はそのまま保持し、削除で移行を代替したり、再インストールで修復を代替したりしないでください。
  • 曖昧さが経路を大幅に変える場合のみ質問します。

2. Playbook のルーティング

  • playbook-index.md を読み、症状に基づいて最も具体的なものを選択します。
  • 必要なものだけ playbooks/*.md を読み込み、一度に全部読み込まないでください。
  • 複数の独立した問題がある場合、「影響範囲 × 依存順序」で1つずつ処理します。

3. 読み取り専用診断

winmedic.ps1 probe --set <domain>        # 出力: state\findings.json
  • プローブは読み取り専用です。どのステップでも書き込み操作が発生したらバグです。即座に停止し報告してください。
  • 取得できない項目は「取得不可」と正直に記載し、推測しないでください。

4. 計画の生成

winmedic.ps1 plan --from state\findings.json

出力: plan.json + plan.md + planHash。plan.md の原文をユーザーに提示し、自分で要約して曖昧な説明にしないでください。

plan.md には2つのセクションが含まれます:

  1. 推奨(優先順位順) — ドメイン横断的な処置の推奨。high が優先(再起動待ち、復元ポイントなし、セキュリティリスク、ディスク緊急)
    • 処置 列に 実行可能: <action> とあるものは、直接 winmedic.ps1 apply --action <action> --yes を実行可能
    • 手動: <playbook> とあるものは、その playbook に従って1つずつ処置し、自分で手順を考案しないでください
  2. 明細 — エンジンが実行可能なクリーンアップ項目(id で実行)

推奨セクションのソースは決定論的なルール(モデルの推測ではない)であり、証拠は playbook または catalog 証拠エントリにリンクしています。

5. 確認

  • 項目ごとに: アクション、影響量、リスクレベル、ロールバック可否を列挙。
  • ユーザーが承認した id のみ実行します。 ユーザーが「何でもいい」と言った場合、デフォルトで Tier 1 + Tier 2 のみ実行します。
  • Tier 3 は項目ごとに確認が必要です。Tier 4 は一切実行しません。

6. 実行

winmedic.ps1 apply --plan state\plan.json --ids R1,R3 --yes
  • デフォルトで隔離領域に入ります(ソフトデリート)。--purge を軽率に付けないでください。
  • 部分失敗(終了コード 7)の場合、journal を確認してから続行するか判断します。

7. 検証

winmedic.ps1 verify --journal <id>
  • 空き容量、サービス状態、ターゲットが消えたかどうかを確認します。
  • pendingReboot = true の場合、ユーザーに「再起動後に完全に有効になります」と明確に伝え、成功したと偽らないでください。

8. 報告

固定の5セクション: 現状 → 何を見つけたか → 何をしたか → 検証結果 → 何をしなかったか(およびその理由)

アクション階層

Tier意味実行要件
1リスクゼロ、削除してもシステムは動作確認のみ
2キャッシュ、再構築される再構築のコストを説明
3判断が必要、機能に影響する可能性あり項目ごとに確認 + 証拠提示
4レッドライン実行を拒否、理由を説明し手動の手順を提示

画面1つの健康診断と比較

winmedic.ps1 probe --set intake        # ドメイン横断読み取り専用収集(約60〜90秒)
winmedic.ps1 summary                   # 9ドメイン画面1つのサマリー、OK/WARN/BAD
winmedic.ps1 diff --from a.json --to b.json   # 2回の収集を比較

summary で未収集のドメインは [?] 未収集 と表示されます。これに基づいて結論を下さず、先に収集を補完してください。

サマリーの末尾には「推奨」(優先順位順)が直接リストされ、plan の推奨セクションと同じソースです。機械可読にするには --json を追加してリダイレクトします:

winmedic.ps1 summary --json > status.json

特定のソフトウェア(ワークロードドメイン)

ユーザーが特定のソフトウェアを指定した場合(LaTeX、PyCharm、Steam、Zotero、Word、プロキシツール…)、最初に以下を実行:

winmedic.ps1 probe --set workloads

これは catalog/workloads.json のシグネチャテーブルに従い、各ソフトウェアのキャッシュとデータのサイズを測定し、プロキシチェーンの一貫性をチェックします。

重要な区別:

  • kind=cache(シェーダーキャッシュ、IDE インデックス、texmf-var、OfficeFileCache)→ クリーンアップ可能、コストは再構築
  • kind=data(ゲーム本体、Zotero 添付ファイル、WeChat チャット履歴、texmf-dist)→ 絶対に削除しない、移行のみ
  • kind=review(Tencent Video ダウンロード、混合ディレクトリ)→ 事前確認必須、ユーザーが自らダウンロードしたコンテンツが含まれる可能性あり
  • probe.proxy-chain は system/WinHTTP/git/npm/pip の5層のプロキシ値をリスト、consistent=false は競合

新しいソフトウェアを追加するのにコード変更は不要: catalog/workloads.json にシグネチャ(detect + measure + playbook)を1行追加するだけです。

移行判断(ユーザーが「キャッシュ/ソフトウェアを別のドライブに移動」「C ドライブに新しいソフトウェアをインストールできない」と言った場合)

これは判断問題であり、参照問題ではありません。エンジンは事実のみを提供し、計画はあなたが決定しますが、チェックリストを完了する必要があります。

winmedic.ps1 relocate            # ディスク概要 + 判断チェックリスト + 事実テーブル + デフォルト推奨
winmedic.ps1 relocate --json     # 同上、構造化

出力は3つのセクションで構成され、意味が異なります。混同しないでください:

セクション意味使用方法
判断チェックリスト答えるべき3つの質問回答で各質問に結論を出す必要があり、スキップ不可
事実パス/サイズ/メディア/存在/既知のフォルダ/ソフトウェア宣言パス判断の根拠
デフォルト推奨エンジンのデフォルト視点(policySource=default-hint)参考のみ、あなたの判断で覆せる;結論としてそのまま伝えないこと

3つのチェックリスト質問(回答時に明示的にカバーすること)

  1. 既知のフォルダ配下か? はい → そのフォルダを1回移動し、個々のソフトウェアにパスを設定しない;ただし、まず以下の第3条を判断
  2. ホットデータかコールドデータか? ホット(リアルタイムレンダリングキャッシュ、IDE インデックス、ストリーミングキャッシュ)→ 最速のドライブに残す;コールド(ゲーム/VM/ライブラリ/チャット履歴)→ 容量ドライブへの移動を検討
  3. ソフトウェアは既に絶対パスを記録しているか(インストール後に移動するケース)? はい → 移動後、ソフトウェア内の設定を同期して変更しないと、古いパスを参照する

あなた(DSH)がやるべきこと

  • 事実テーブルの メディア を最初に確認: ホットデータを HDD に移動するのは間違い。たとえ HDD のほうが大きくても
  • ソフトウェア宣言パス を最初に確認: これは「インストール後に移動」の決定的な証拠
  • 計画は「何をする → なぜ → リスク → 検証方法」の形式で記述し、ユーザーが確認してから実行させること
  • エンジンは代わりに移行しません;あなたの役割は理由付きの計画を提示すること

詳細は playbook apps-relocate-cache(PB-913)参照。

経過(誰が増えているか、だけでなく誰が最大か)

winmedic.ps1 trend --record      # スナップショットを記録(1日1回推奨)
winmedic.ps1 trend --days 14     # 変化とレートを確認

判断ルール:

  • confidence=insufficient(<2 サンプル)→ 結論を下してはいけない、まず記録
  • confidence=low(間隔 <0.5日)→ 変化量のみを見る。日次レートなし
  • confidence=ok → 「1日 X GB 増加」と言える

用途: C ドライブが満杯のとき、まずトレンドを確認し、それからキャッシュをクリアするか、特定のソフトウェアがログを大量に書き込んでいるかを調査するかを判断。

鑑別診断(C ドライブ満杯 / ネットワーク異常など「原因追究が必要」なシナリオ)

winmedic.ps1 diagnose --list
winmedic.ps1 diagnose --case dx.cdisk-full

出力は事実テーブル(仮説 × 指標 × 現在値 × 判定シグナル × データソース)。結論は含まれません。

必須: 各項目を判断し、どの仮説が除外され、どの仮説が支持されたかを説明し、その後に計画を提示。 source に trend が含まれるものは変化量;low のものはレートを計算できない;insufficient のものは値なし。

外部ツールが必要な場合は、まずツールキャビネットを確認: winmedic.ps1 tools(検出のみ、Tier≥3 の自動実行はしない)。

症例ライブラリ(経験の蓄積)

cases/ には7セクション形式の症例: 症状 / 環境 / 収集 / 仮説と除外 / 処置 / 結果 / 教訓

  • 同じ問題に遭遇したら症例を先に検索、丸ごと1ラウンドの調査を節約可能
  • 新しい問題を解決したら cases/_template.md に従って1件記録。そうしないと次回また最初からやり直し
  • pending マークは現場証拠なしの調査待ち項目、結論として引用してはいけない

証拠照会

どのアクション実行前でも、ユーザーが「なぜ」「根拠は」と尋ねたら、直接検索:

winmedic.ps1 explain --action storage.winsxs-cleanup

出力: レベル、ロールバック可否、コマンド、注意事項、証拠原文と公式リンク、確認日、検証ルール

リスクゲート

apply は復元能力(復元ポイント/ボリュームシャドウコピー)をチェック:

  • ターゲットに Tier 3(ロールバック不可)が含まれ、復元能力が ready でない → 実行を拒否、リターンコード 4
  • この場合の正しい対処: 最初に apply --action recovery.create-restore-point --yes で復元ポイントを作成、またはユーザーに明示的に --accept-risk を追加させる
  • タスクを進めるために勝手に --accept-risk を追加しないこと

ユーザー保留項目(ハード制約)

ユーザーが「WeChat を触らない」「D ドライブに触らない」と言った場合、すぐに保留項目として固定化し、頭の中だけで覚えないこと:

winmedic.ps1 profile --exclude "C:\Users\<user>\Documents\WeChat Files"
winmedic.ps1 profile --exclude "D:\*"
winmedic.ps1 profile                       # 現在の保留項目を表示
winmedic.ps1 profile --exclude "..." --remove  # 削除

保留項目は二重のインターセプト: plan フェーズで除外、apply フェーズで再度拒否して記録。

いつ手を止めるべきか

  • ターゲットが Windows\WinSxS 内のファイル、Windows\Installer、System32、WindowsApps
  • ターゲットがチャット履歴ディレクトリ(WeChat Files / xwechat_files)またはユーザー宣言の保留項目
  • 残り1〜2個のシステム復元ポイントで、削除を要求された場合
  • コミット量が上限に近い状態でページファイルの縮小を要求された場合
  • ユーザーが「全部削除」「リスクを気にしない」と要求した場合 — まず説明し、その後 Tier 1/2 のみ実行

エンジン呼び出し規約

ホストが MCP 経由でのみツールにアクセスできる場合、engine\mcp\winmedic-mcp.ps1 を使用(docs/MCP.md 参照); ツールパラメータは以下のコマンドと1対1対応、ツールは yes=true が必要。その他のルールは完全に同じ。

  • すべてのサブコマンドは --json をサポート。--json なしの場合は人間可読なサマリーを出力。
  • 終了コード: 0 成功 / 2 使用方法 / 3 権限 / 4 前提条件未通過 / 5 plan 無効 / 6 レッドライン / 7 部分失敗
  • エンジンをバイパスして直接削除コマンドを実行しないでください。 エンジンの価値はハッシュバインディング、隔離領域、監査ログです。

レポート生成

winmedic.ps1 report --journal <runId>        # 5セクション形式の納品レポート
winmedic.ps1 report --set storage --out report.md

レポートは固定5セクション: 現状 → 何を見つけたか → 何をしたか → 検証結果 → 何をしなかったか(およびその理由) データがない場合は正直に「未収集」と書き、捏造しない。

レポートテンプレート

## 現状
C: 98.7 GB、空き 16.7 GB(83%)

## 何を見つけたか
| 項目 | サイズ | レベル | 根拠 |
| ごみ箱 | 7.03 GB | 1 | 影響なし |
| hiberfil.sys | 6.32 GB | 1 | マイクロソフト文書: powercfg /h off |

## 何をしたか
R1 ごみ箱を空にする: 7.03 GB -> 0
R2 休止状態を無効化: 6.32 GB 解放

## 検証結果
C: 空き 16.7 -> 30.1 GB;スリープ S0 正常;pendingReboot なし

## 何をしなかったか
SoftwareDistribution(ユーザーがスキップを要求)、Windows\Installer(高リスク、専用ツール推奨)

関連スキル