Computer Health Check

What this skill does

Give the user a fast, trustworthy picture of their computer's health and a short list
of actions worth taking — the way a good technician would: look first, explain plainly,
fix only with permission.

It runs entirely through Desktop Commander's local shell, gathers a batch of read-only
diagnostics, scores each area, prints a concise summary in the chat, and then offers
cleanup suggestions the user can approve one by one.

The safety contract (read this first)

This is the part that makes users trust the skill, so honor it strictly:

• Read-only by default. The collection phase only observes (sizes, counts, status).

It changes nothing.

• Never use sudo or elevation. DC blocks sudo, shutdown, reboot, dd, mount,

mkfs, diskpart, etc. for good reason. Every check below is designed to work without
them. If something seems to need elevation, skip it and say so — don't try to work around
the block.

• Cleanups are opt-in. You may suggest cleanups freely, but only execute one after

the user explicitly approves that specific action, and only show the exact command first.

• Prefer reversible, non-destructive actions. Emptying caches that regenerate, clearing

a package-manager download cache, or emptying Trash are fine to offer. Deleting user
documents, uninstalling apps, or editing system files are not — suggest those, let the
user do them.

Workflow

Step 1 — Detect the OS

Determine the platform before doing anything else, because the commands differ.

• Quickest: read Desktop Commander's config (get_config) and use the

systemInfo.isMacOS / isWindows / isLinux booleans (or platformName) to
pick the platform.

• Or run uname (macOS/Linux) — if it fails, assume Windows.

Then open the matching reference file and use its command set:

• macOS → references/macos.md
• Windows → references/windows.md
• Linux → references/linux.md

Read only the one that matches. Each file contains a single batched collection script
plus interpretation notes and cleanup commands.

Step 2 — Collect (read-only)

Run the batched collection script from the reference file with start_process. Batching
everything into one call is much faster than many small calls and keeps the output tidy.

Guidance:

• Keep outputs bounded (head, Select-Object -First, etc.) so a long process list or

file listing doesn't flood the response.

• Skip the genuinely slow / network checks (full OS-update list, internet speed test) on the

first pass unless the user asked about updates or network. Mention they're available.

• If a single command errors (e.g., a tool isn't installed), continue — partial data is fine.

Step 3 — Score each area

Rate each category 🟢 Good / 🟡 Watch / 🔴 Act using the rubric below, then compute a simple
overall score. Start at 100 and subtract 8 per 🟡 and 18 per 🔴; floor at 0. Report the
number and a one-word verdict (90+ Excellent, 75–89 Good, 60–74 Fair, <60 Needs attention).

Battery is laptop-only — skip it on desktops/VMs. Reclaimable space is reported as an
informational figure, not scored.

Step 4 — Report in the chat

Use this exact structure. Keep it tight and scannable — this is the deliverable.

🖥️  Health Check — <Model>, <OS version>     Score: <N>/100 (<verdict>)

🟢/🟡/🔴  Storage      — <free> free of <total> (<%>). Reclaimable: ~<X> GB
🟢/🟡/🔴  Memory       — <one-line state>
🟢/🟡/🔴  Battery      — <cycles> cycles, <max capacity>%, <condition>
🟢/🟡/🔴  Maintenance  — up <days>d, <updates state>
🟢/🟡/🔴  Startup      — <count> login items (<notable ones>)
🟢/🟡/🔴  Right now    — top: <proc> <cpu%>, <proc> <cpu%>

Top recommendations
1. <highest-impact action> (<expected benefit, e.g. frees ~13 GB>)
2. <next>
3. <next>

List at most the 3–5 highest-impact recommendations, ordered by benefit. Don't dump every
finding — the goal is signal, not a wall of text.

Step 5 — Suggest cleanups, execute only on approval

For each recommendation that maps to a concrete command (see the reference file's "Cleanup"
section), offer it and show the exact command. Then:

• Safe, reversible (offer to run on a yes): empty Trash, package-manager cache cleanup

(brew cleanup, npm cache clean), clearing a regenerating user cache folder. (On Linux,
apt-get clean / dnf clean need root — suggest, don't auto-run.)

• Needs the user to decide / act (suggest, don't auto-run): disabling login items,

installing OS updates (requires restart), uninstalling apps, deleting files in Downloads.

• Never: anything requiring sudo/admin, removing system files, disk/partition operations.

When the user approves a safe action, run it, then report what changed (e.g., space freed).
Re-running Step 2's storage check afterward is a nice confirmation.

Recommendation rules (findings → advice)

These are the high-value mappings; adapt the wording to the platform.

• Uptime > 30 days → "Restart your computer — it's been up days. A reboot clears

memory and applies pending updates." (Highest ROI, lowest effort.)

• Pending OS/security updates → platform update step; flag security updates as higher

priority.

• Free space < 15% → lead with the biggest reclaimable buckets you measured.
• Large Downloads / Caches / Trash → empty Trash; review largest Downloads items by name;

clear caches that regenerate.

• Package manager has many outdated items / big cache → upgrade + cache cleanup.
• Battery max capacity < 80% → explain wear is normal; consider a battery service if it's

affecting runtime.

• Many third-party startup agents → name them and suggest disabling the ones the user

doesn't recognize/need (point to System Settings / Task Manager — don't edit them directly).

• A process pinned high at idle → name it and suggest quitting/investigating.

Notes & pitfalls

• Don't assume — measure. Always run the commands and report real numbers. Never

fabricate sizes, cycle counts, or statuses.

• Bounded output. Process and file listings can be huge; always cap them.
• Optional deep checks (mention, run on request): internet speed test, full update list,

per-folder disk scan of the whole home directory, crash-report trend analysis.

• Privacy. This reads local system metadata only. Don't send anything off the machine;

the public-IP check is optional and should be labeled.

• Cross-platform parity. The three reference files mirror the same categories so the

report looks the same regardless of OS.