syscheck

name	syscheck
description	Use when the user says "syscheck" or asks for a parallel system health check. Fans out THREE subagents via the `task` tool — one checks CPU, one network, one memory — using only safe read-only commands, then synthesizes their results into one report. Demonstrates parallel subagent fan-out in opencode.

Syscheck (demo) — parallel subagent fan-out (opencode)

Demonstrates fanning out work to several subagents at once with opencode's task tool. Instead of one agent checking CPU, network, and memory one after another, the main agent invokes three subagents in parallel — each owns one subsystem — and then combines their findings into a single system-health report.

Each task call spawns a subagent in its own context that runs asynchronously: the call returns control to the main agent immediately, and opencode notifies the main agent when the subagent completes. To run the three checks concurrently, issue all three task calls in one message; opencode starts them together, and you gather and synthesize their results as they report back.

This extends the background-subagent pattern (one subagent) to fan-out: several independent subagents at once, each in its own context, with the main agent acting as orchestrator.

Safety: every subagent uses read-only commands only — it observes the system and never modifies it. No writes to files, sysctl, services, or config.

What to do

1. Invoke three subagents in a single message (so they start concurrently) with the task tool, subagent_type: "general". Hand each one of the three task prompts below. Do not run the checks yourself, and do not chain any tool call after them in the same message that depends on their results — let the turn end so control returns to the user while the subagents run.

   ① CPU — description: "check cpu":

   Check CPU status using only safe, read-only commands (no writes, no config or sysctl changes). Run: lscpu (model, core count), nproc, uptime (load average), and top -bn1 | head -n 15 for current utilization. Report a short summary: CPU model, physical/logical cores, load average (1/5/15 min), and approximate CPU utilization. Return only the summary.

   ② Network — description: "check network":

   Check network status using only safe, read-only commands (no writes, no config changes). Find the primary interface with ip route get 1.1.1.1. Run ip -s link show <iface> (counters), ip addr show <iface> (address), and ping -c 5 -W 2 1.1.1.1 for latency/loss (fall back to 8.8.8.8). Report: interface, IP, gateway, RTT min/avg/max (ms), packet loss %. Return only the summary.

   ③ Memory — description: "check memory":

   Check memory status using only safe, read-only commands (no writes). Run: free -h (RAM + swap) and vmstat -s -S M for detail. Report: total RAM, used, available, used %, and swap used/total. Return only the summary.

2. Immediately tell the user, in one or two lines, that three checks (CPU, network, memory) are now running in parallel in the background and they can keep talking meanwhile. Then end your turn — do not block waiting for the subagents.

3. When the subagents complete, you will be notified with their results (one notification per subagent). Once all three have reported, synthesize their summaries into one short system-health report — a section or row per subsystem — and flag anything notable (high load, packet loss, low available memory).

Why these are background subagents

Three things make this background fan-out, not blocking calls:

1. Separate context. Each subagent has its own conversation/tool loop; the lscpu/ping/free output never enters the main transcript — only the three short summaries come back.
2. Non-blocking. The main agent launches all three and ends its turn instead of waiting, so the user keeps control.
3. Async result. When each subagent completes, opencode notifies the main agent, which then synthesizes the combined report. You do not poll.

The teaching point: fan-out. Three independent subagents work in parallel, each in its own context, and the main agent only collects and combines the distilled results — fire-and-continue, not fire-and-wait.