Skill: calvinxhk/botlearn-healthcheck (version 1.0.5)

--- name: botlearn-healthcheck version: 0.1.5 description: "botlearn-healthcheck — BotLearn autonomous health inspector for OpenClaw instances across 5 domains (hardware, config, security, skills, autonomy); triggers on system check, health report, diagnostics, or scheduled heartbeat inspection." metadata: openclaw: emoji: "🏥" requires: bins: ["curl", "node", "bash"] anyBins: ["clawhub", "openclaw"] optionalBins: ["jq"] os: [darwin, linux] primaryEnv: OPENCLAW_HOME triggers: - "health check" - "diagnose" - "doctor" - "check system" - "system status" - "troubleshoot" - "what's wrong" - "fix my setup" - "check gateway" - "check skills" - "check config" - "check security" - "check autonomy" - "check hardware" - "体检" - "修复" - "诊断" --- # OpenClaw Health Doctor > **THIS ENTIRE DOCUMENT IS FOR YOU — THE AI AGENT.** > Collect all data autonomously. Never ask the human to execute commands. > Every check, analysis, and report is your responsibility to produce. > All output to the user must be in their native language (REPORT_LANG). ## Role You are the OpenClaw Health Doctor. You autonomously collect raw system data from a live OpenClaw instance, analyze it across **5 health domains**, and produce a quantified traffic-light report (✅ pass / ⚠️ warning / ❌ error) with domain scores (0–100) and fix guidance — rendered in the user's native language. ## First Run On first activation, or when the OpenClaw environment has not yet been verified, read **`setup.md`** and execute the prerequisite checks before proceeding to Phase 1. ## Operating Modes | Mode | Trigger | Behavior | |------|---------|----------| | Full Check | "health check" / "doctor" / general query | All 5 domains in parallel | | Targeted | Domain named explicitly: "check security", "fix skills" | That domain only | --- ## Phase 0 — Language & Mode Detection **Detect REPORT_LANG** from the user's message language: - Chinese (any form) → Chinese - English → English - Other → English (default) **Detect mode:** If user names a specific domain, run Targeted mode for that domain only. Otherwise run Full Check. --- ## Phase 1 — Data Collection Read **`data_collect.md`** for the complete collection protocol. **Summary — run all in parallel:** | Context Key | Source | What It Provides | |-------------|--------|-----------------| | `DATA.status` | `scripts/collect-status.sh` | Full instance status: version, OS, gateway, services, agents, channels, diagnosis, log issues | | `DATA.env` | `scripts/collect-env.sh` | OS, memory, disk, CPU, version strings | | `DATA.config` | `scripts/collect-config.sh` | Config structure, sections, agent settings | | `DATA.logs` | `scripts/collect-logs.sh` | Error rate, anomaly spikes, critical events | | `DATA.skills` | `scripts/collect-skills.sh` | Installed skills, broken deps, file integrity | | `DATA.health` | `openclaw health --json` | Gateway reachability, endpoint latency, service status | | `DATA.precheck` | `scripts/collect-precheck.sh` | Built-in openclaw doctor check results | | `DATA.channels` | `scripts/collect-channels.sh` | Channel registration, config status | | `DATA.security` | `scripts/collect-security.sh` | Credential exposure, permissions, network | | `DATA.workspace_audit` | `scripts/collect-workspace-audit.sh` | Storage, config cross-validation | | `DATA.doctor_deep` | `openclaw doctor --deep --non-interactive` | Deep self-diagnostic text output | | `DATA.openclaw_json` | direct read `$OPENCLAW_HOME/openclaw.json` | Raw config for cross-validation | | `DATA.cron` | direct read `$OPENCLAW_HOME/cron/*.json` | Scheduled task definitions | | `DATA.identity` | `ls -la $OPENCLAW_HOME/identity/` | Authenticated device listing (no content) | | `DATA.gateway_err_log` | `tail -200 $OPENCLAW_HOME/logs/gateway.err.log` | Recent gateway errors (redacted) | | `DATA.memory_stats` | `find/du` on `$OPENCLAW_HOME/memory/` | File count, total size, type breakdown | | `DATA.heartbeat` | direct read `$OPENCLAW_HOME/workspace/HEARTBEAT.md` | Last heartbeat timestamp + content | | `DATA.models` | direct read `$OPENCLAW_HOME/agent/models.json` | Model contextWindow, maxTokens per model | | `DATA.cache` | `openclaw cache stats` | Cache size, history count, index size | | `DATA.workspace_identity` | direct read `$OPENCLAW_HOME/workspace/{agent,soul,user,identity,tool}.md` | Presence + word count + content depth of 5 identity files | On any failure: set `DATA.<key> = null`, continue — never abort collection. --- ## Phase 2 — Domain Analysis For **Full Check**: run all 5 domains in parallel. For **Targeted**: run only the named domain. Each domain independently produces: **status** (✅/⚠️/❌) + **score** (0–100) + **findings** + **fix hints**. Read the corresponding `check_*.md` file for complete scoring tables, edge cases, and output format. Read **`openclaw_knowledge.md`** for platform defaults (gateway address, latest version, CLI commands). | # | Domain | Data Sources | Key Checks | Pass/Warn/Fail | Reference | |---|--------|-------------|------------|----------------|-----------| | 1 | Hardware Resources | `DATA.env` | Memory, Disk, CPU, Node.js, OS | ≥80 / 60–79 / <60 | `check_hardware.md` | | 2 | Configuration Health | `DATA.config`, `DATA.health`, `DATA.channels`, `DATA.tools`, `DATA.openclaw_json`, `DATA.status` | CLI validation, config structure, gateway, agents, channels, tools, consistency, security posture | ≥75 / 55–74 / <55 | `check_config.md` | | 3 | Security Risks | `DATA.security`, `DATA.gateway_err_log`, `DATA.identity`, `DATA.config` | Credential exposure, file permissions, network bind, CVEs, VCS secrets | ≥85 / 65–84 / <65 | `check_security.md` | | 4 | Skills Completeness | `DATA.skills` | Built-in tools, install capability, count & coverage, skill health, botlearn ecosystem | ≥80 / 60–79 / <60 | `check_skills.md` | | 5 | Autonomous Intelligence | `DATA.precheck`, `DATA.heartbeat`, `DATA.cron`, `DATA.memory_stats`, `DATA.workspace_audit`, `DATA.doctor_deep`, `DATA.logs`, `DATA.status`, `DATA.workspace_identity` | Heartbeat, cron, memory, doctor, services, agents, logs, workspace identity → Autonomy Mode | ≥80 / 60–79 / <60 | `check_autonomy.md` | **Common rules:** - Base score = 100, subtract impacts per check failure - If data source is null: use fallback score noted in each `check_*.md` - Privacy: NEVER print credential values — report type + file path only - Output: domain labels and summaries in REPORT_LANG; metrics, commands, field names in English --- ## Phase 3 — Report Generation Generate persistent health report documents (MD + HTML) from domain analysis results. Save to `$OPENCLAW_HOME/memory/health-reports/healthcheck-YYYY-MM-DD-HHmmss.{md,html}`. Read **`flow_report.md`** for: output location, file naming, MD/HTML content templates, generation protocol. --- ## Phase 4 — Report Analysis Present analysis results to the user with layered output (one-line status → domain grid → issue table → deep analysis). Compare with historical reports for trend tracking. Read **`flow_analysis.md`** for: output layer formats (L0–L3), historical trend comparison, follow-up prompts. Reference **`fix_cases.md`** for real-world diagnosis patterns and root cause analysis. --- ## Phase 5 — Fix Cycle If any issues found, guide user through fix execution with confirmation at every step. Show fix command + rollback command → await confirmation → execute → verify. **Never run any command that modifies system state without explicit user confirmation.** Read **`flow_fix.md`** for: safety rules, per-fix protocol, batch mode, scope limits. Reference **`fix_cases.md`** for proven fix steps, rollback commands, and prevention strategies. --- ## Phase 6 — Fix Summary After fix cycle, generate a final summary: actions taken, score changes, remaining issues. Append fix results to the previously generated report files. Read **`flow_summary.md`** for: summary content, post-fix verification, report update, closing message. --- ## Key Constraints 1. **Scripts First** — Use `scripts/collect-*.sh` for structured data; read files directly for raw content. 2. **Evidence-Based** — Every finding must cite the specific `DATA.<key>.<field>` and its actual value. 3. **Privacy Guard** — Redact all API keys, tokens, and passwords before any output or storage. 4. **Safety Gate** — Show fix plan and await explicit confirmation before any system modification. 5. **Language Rule** — Instructions in this file are in English. All output to the user must be in REPORT_LANG.

path: check_autonomy.md
content: # Domain: Autonomous Intelligence

> Deep reference for Domain 5 in SKILL.md.
> Load this file when running L3 analysis or when SKILL.md thresholds need clarification.
>
> **Input:** `DATA.precheck`, `DATA.heartbeat`, `DATA.cron`, `DATA.memory_stats`,
>             `DATA.workspace_audit`, `DATA.doctor_deep`, `DATA.logs`, `DATA.status`
> **Output:** status (✅/⚠️/❌) + score (0–100) + autonomy mode label + findings + fix hints

---

## Analysis Checklist

### 1. Heartbeat Status

From `DATA.heartbeat` (raw content of `workspace/HEARTBEAT.md`):

Parse the last heartbeat timestamp (ISO 8601 or human-readable format).
Calculate age: `now - last_heartbeat_time`.

| Heartbeat Age | Status | Score Impact | Qualitative |
|---------------|--------|-------------|-------------|
| < 60 minutes | ✅ | 0 | Agent actively running |
| 1–6 hours | ⚠️ | -10 | Potentially idle |
| 6–24 hours | ⚠️ | -20 | Agent likely stopped |
| > 24 hours | ❌ | -40 | Agent has been down |
| File missing | ⚠️ | -15 | Heartbeat not initialized |

From `DATA.config.agents.heartbeat`:
- `autoRecovery: false` or missing → ⚠️ (-10). Risk: no automatic restart after crash.
- `intervalMinutes > 120` → ⚠️ (-5). Risk: slow crash detection.

**Fix (no heartbeat):** Verify `openclaw start` is running; check `workspace/HEARTBEAT.md` config.
**Fix (autoRecovery off):** Set `agents.heartbeat.autoRecovery: true` in `openclaw.json`.

---

### 2. Scheduled Tasks (Cron)

From `DATA.cron`:

| Condition | Status | Score Impact |
|-----------|--------|-------------|
| At least 1 active task defined | ✅ | 0 |
| 0 tasks in cron directory | ⚠️ | -10 |
| cron directory missing | ⚠️ | -5 |
| Any task with `status: error` or last-run failed | ⚠️ | -10 per task (max -20) |

For each cron task, report: `name`, `schedule`, `last_run`, `next_run`, `status`.

**Risk:** Without cron tasks, the agent cannot perform scheduled learning cycles,
self-optimization, or periodic health checks.

---

### 3. Memory Health

From `DATA.memory_stats`:

| Condition | Status | Score Impact | Qualitative |
|-----------|--------|-------------|-------------|
| `total_size` < 100 MB | ✅ | 0 | Lean and efficient |
| `total_size` 100–500 MB | ⚠️ | -10 | Growing — consider pruning |
| `total_size` > 500 MB | ❌ | -25 | Bloated — likely affects search performance |
| `total_files` < 100 | ✅ | 0 | |
| `total_files` 100–500 | ⚠️ | -5 | |
| `total_files` > 500 | ⚠️ | -10 | High file count slows memory search |

Report type breakdown to show memory composition:
e.g., "42 .md files (knowledge), 18 .json files (structured data)"

**Fix (bloated):** `clawhub memory compact` or prune entries older than 90 days manually.

---

### 3b. Agent & Service Status (from DATA.status)

From `DATA.status`:

| Check | Field | ✅ | ⚠️ | ❌ | Score Impact |
|-------|-------|-----|-----|-----|-------------|
| Gateway service running | `status.overview.gateway_service.running` | true | — | false | ❌ -20 |
| Node service installed | `status.overview.node_service.installed` | true | false | — | ⚠️ -10 |
| Active agents | `status.overview.agents_overview.active` ≥ 1 | ≥1 | 0 | — | ⚠️ -15 |
| Agent bootstrap file | `status.agents[].bootstrap_present` | true | false | — | ⚠️ -10 per agent (max -20) |

**Bootstrap file absent**: If any agent has `bootstrap_present = false`, the agent lacks
a configuration file at startup — it cannot self-configure or restore its role after restart.
Report each affected agent by name.

**Fix (gateway service not running):** `openclaw start` or `openclaw restart`
**Fix (node service not installed):** `openclaw install-service` (enables auto-start on boot)
**Fix (bootstrap absent):** Create or restore `agent.md` in the agent's store directory
(`status.agents[].store_path`) and restart: `openclaw restart`

**Log Issues from Status**: `DATA.status.log_issues[]` provides pre-filtered notable log lines
(timeouts, errors, command-not-found). Cross-reference with `DATA.logs` for completeness.
Each entry in `log_issues` that is not already captured by `DATA.logs` should be added as
an additional finding.

---

### 4. Self-Check Results (openclaw doctor)

From `DATA.precheck.summary` + `DATA.doctor_deep`:

| Condition | Status | Score Impact |
|-----------|--------|-------------|
| All checks passing (error=0, warn=0) | ✅ | 0 |
| `warn > 0` | ⚠️ | -10 per warning (max -20) |
| `error > 0` | ❌ | -20 per error (max -40) |
| `precheck_ran = false` (doctor unavailable) | ⚠️ | -15 |

From `DATA.doctor_deep` (text output of `openclaw doctor --deep --non-interactive`):
- Extract lines containing "FAIL" or "ERROR" → add as ❌ findings.
- Extract lines containing "WARN" or "CAUTION" → add as ⚠️ findings.
- Cross-reference with `DATA.precheck.summary` to catch anything not captured by JSON.

---

### 5. Log Anomalies (Autonomy Signals)

From `DATA.logs`:

| Condition | Status | Score Impact |
|-----------|--------|-------------|
| `critical_events` contains OOM or segfault | ❌ | -20 |
| `critical_events` contains UnhandledPromiseRejection | ⚠️ | -10 |
| `anomalies.error_spikes` severity=high | ⚠️ | -10 |
| `anomalies.error_spikes` severity=critical | ❌ | -20 |
| Error rate < 1% | ✅ | 0 |

Focus on patterns indicating autonomous operation disruption:
- OOM → memory pressure disrupting agent continuity
- Uncaught rejections → skill execution instability
- Error spikes → external dependency failures affecting scheduled tasks

---

### 6. Workspace Identity & Configuration Review

**Source:** `DATA.workspace_identity`

The agent's workspace should contain 5 core identity files. Their presence and content depth
directly determine how well the agent understands itself and the user it serves.

#### 6.1 File Presence

| File | Purpose | Missing → Status | Score Impact |
|------|---------|-----------------|-------------|
| `agent.md` | Role definition, capabilities, behavioral rules | ❌ | -20 — no bootstrap identity; agent restarts as blank |
| `user.md` | User profile, preferences, personal context | ❌ | -15 — agent cannot adapt to the individual |
| `soul.md` | Personality, values, principles | ⚠️ | -10 — agent lacks character consistency |
| `tool.md` | Available tools and usage context | ⚠️ | -10 — agent unaware of its own tool surface |
| `identity.md` | Agent name, version, organizational context | ⚠️ | -5 — identity is implicit only |

If `agent.md` is missing, flag as **Critical** regardless of overall score.

#### 6.2 Content Sufficiency

For each file that exists, assess content depth by word count and key structural signals.
Do not reproduce content verbatim — analyze and summarize only.

**agent.md** — Must declare the agent's role. Look for: "you are", "your role", "responsibilities",
"capabilities", behavioral rules, constraints.

| Content Level | Condition | Status | Score Impact |
|---------------|-----------|--------|-------------|
| Rich | ≥ 200 words + role declaration + behavioral rules | ✅ | 0 |
| Basic | 50–199 words, role defined but thin | ⚠️ | -5 |
| Critical | < 50 words or no clear role declaration | ❌ | -10 |

**user.md** — Must contain actual user context. Look for: name/handle, background, preferences,
communication style, goals, domain expertise. Generic template content ("Your user is...") does NOT count.

| Content Level | Condition | Status | Score Impact |
|---------------|-----------|--------|-------------|
| Personalized | ≥ 100 words + personal context + preferences | ✅ | 0 |
| Sparse | 20–99 words, minimal or generic profile | ⚠️ | -8 |
| Empty/template | < 20 words or clearly unfilled template | ❌ | -12 |

**soul.md** — Values, principles, personality traits. Look for: adjectives describing character,
ethical guidelines, tone preferences, interaction style.

| Content Level | Condition | Status | Score Impact |
|---------------|-----------|--------|-------------|
| Defined | ≥ 80 words + clear values/principles | ✅ | 0 |
| Thin | < 80 words or generic | ⚠️ | -5 |

**tool.md** — Tool inventory with context. Look for: tool names listed, usage notes, limitations.

| Content Level | Condition | Status | Score Impact |
|---------------|-----------|--------|-------------|
| Complete | ≥ 50 words + tool names with context | ✅ | 0 |
| Sparse | exists but lacks detail | ⚠️ | -3 |

**identity.md** — Agent name and organizational context. Look for: agent name, version, owner,
purpose statement.

| Content Level | Condition | Status | Score Impact |
|---------------|-----------|--------|-------------|
| Defined | ≥ 30 words + name + purpose | ✅ | 0 |
| Thin | exists but vague | ⚠️ | -3 |

#### 6.3 Identity Completeness Labels

After scoring all 5 files, assign an overall identity label:

| Condition | Label | Score Bonus |
|-----------|-------|-------------|
| All 5 present + agent.md ✅ + user.md ✅ | **Identity Complete** | +5 |
| agent.md present ✅ but user.md missing/sparse | **User-Blind** | 0 — agent cannot personalize |
| agent.md missing | **Identity Critical** | 0 — autonomous operation compromised |
| All 5 missing | **Identity Absent** | 0 — blank agent instance |

#### 6.4 Fix Guidance

For missing or thin files, generate specific recommendations:

```
# agent.md — recommended minimum structure:
You are [agent name], a [role description].
Your responsibilities: [list]
Your capabilities: [list]
Behavioral rules: [constraints]

# user.md — recommended minimum structure:
Name: [user name]
Background: [domain/expertise]
Preferences: [communication style, format]
Goals: [what they want to achieve]

# soul.md — recommended minimum structure:
Personality: [key traits]
Values: [principles that guide behavior]
Tone: [how to speak/write]
```

---

## Autonomy Readiness Assessment

After all checks, determine the overall autonomy mode.
Also incorporate `DATA.status` service indicators:

| Condition | Autonomy Mode | Score Bonus |
|-----------|--------------|-------------|
| Heartbeat <1h + autoRecovery=on + ≥1 cron task + doctor errors=0 + gateway_service running + all bootstrap_present + identity_label=Complete | Autonomous-Ready | +5 |
| Heartbeat active but: missing cron, or autoRecovery off, or gateway stopped, or any bootstrap missing, or identity label = User-Blind | Partial Autonomy | 0 |
| Heartbeat missing/stale OR identity_label = Identity Critical | Manual Mode | 0 |

---

## Scoring

```
Base score: 100
Apply all score impacts (cumulative).
Apply +5 bonus if Autonomous-Ready.
Floor: 0. Ceiling: 100.
```

| Score Range | Status |
|-------------|--------|
| ≥ 80 | ✅ |
| 60–79 | ⚠️ |
| < 60 | ❌ |

---

## Output Format

Produce in REPORT_LANG (domain label, autonomy mode label, and descriptions translated; commands and paths in English):

```
[Autonomous Intelligence — translated domain label] [STATUS] — Score: XX/100
[Autonomy Mode label in REPORT_LANG]: [Autonomous-Ready / Partial Autonomy / Manual Mode — translated]
[One-sentence summary in REPORT_LANG]

[Heartbeat label in REPORT_LANG]:  last seen [X ago / never]  interval=[X]min  autoRecovery=[on/off]  [STATUS]
[Cron label in REPORT_LANG]:       [X] tasks — [name: schedule, last-run status, ...]               [STATUS]
[Memory label in REPORT_LANG]:     [X] files, [X MB] ([X .md, X .json, ...])                       [STATUS]
[Services label in REPORT_LANG]:   gateway [running/stopped] (pid=[X])  node-service [on/off]       [STATUS]
[Agents label in REPORT_LANG]:     [X] active  bootstrap: [all present / X agents missing]          [STATUS]
[Self-Check label in REPORT_LANG]: [X pass / X warn / X error] (openclaw doctor)                   [STATUS]
[Log Health label in REPORT_LANG]: error rate [X%], critical events: [none / list]                  [STATUS]
[Identity label in REPORT_LANG]:   [Identity Complete / User-Blind / Identity Critical / Identity Absent]
  agent.md: [✅ rich / ⚠️ thin / ❌ missing]  ([X] words)
  user.md:  [✅ personalized / ⚠️ sparse / ❌ missing/template]  ([X] words)
  soul.md:  [✅ defined / ⚠️ thin / ❌ missing]
  tool.md:  [✅ complete / ⚠️ sparse / ❌ missing]
  identity.md: [✅ defined / ⚠️ thin / ❌ missing]
  [STATUS]

[If any ⚠️/❌ — Findings label in REPORT_LANG:]
- [Evidence citing DATA field and actual value]

[Fix Hints label in REPORT_LANG:]
- [Actionable steps ordered by severity, each with rollback where applicable]

[If Autonomous-Ready:]
[Confirmation message in REPORT_LANG that instance is configured for full autonomous operation]
```


path: check_security.md
content: # Domain: Security Risks

> Deep reference for Domain 3 in SKILL.md.
> Load this file when running L3 analysis or when SKILL.md thresholds need clarification.
>
> **Input:** `DATA.security`, `DATA.gateway_err_log`, `DATA.identity`, `DATA.config`
> **Output:** status (✅/⚠️/❌) + score (0–100) + risk classification + findings + fix hints
> **Privacy rule:** NEVER print credential values. Report type + file path + line number only.

---

## Analysis Checklist

### 1. Credential Exposure

From `DATA.security.credentials` (each item: `type`, `file`, `line` — value always redacted):

| Location | Severity | Score Impact |
|----------|----------|-------------|
| Config files | ❌ Critical | -30 per finding (max -60) |
| Log files | ❌ High | -20 per finding (max -40) |
| Workspace files | ⚠️ Medium | -10 per finding (max -20) |

Also scan `DATA.gateway_err_log` for credential patterns the script may have missed.
Redact before storing: replace matched values with `[REDACTED]`.

**Report format per finding:**
```
[type] credential in [file]:[line] — value REDACTED
```

---

### 2. File Permissions

From `DATA.security.file_permissions`:

| Permission Issue | Status | Score Impact |
|-----------------|--------|-------------|
| Sensitive file world-readable (o+r) | ⚠️ | -10 per file (max -30) |
| Sensitive file group-writable (g+w) | ⚠️ | -5 per file (max -20) |
| Identity credential file world-readable | ❌ | -20 per file |

From `DATA.identity` (directory listing only):
- Any `.pem`, `.key`, `.p12`, `.cert` with `o+r` in `ls -la` output → ❌ (-20 each)

**Fix:** `chmod 600 <file>`
**Rollback:** `chmod <original-mode> <file>` (note the original mode before applying fix)

---

### 3. Network Exposure

From `DATA.config.gateway` + `DATA.security.network_exposure`:

| Configuration | Risk Level | Status | Score Impact |
|--------------|------------|--------|-------------|
| `bind=loopback`, any auth | Low | ✅ | 0 |
| `bind=lan`, jwt/token auth | Medium | ⚠️ | -10 |
| `bind=lan`, `auth.type=none` | Critical | ❌ | -35 |
| `bind=tailnet`, any auth | Low-Medium | ⚠️ | -5 |
| `controlUI=true` on non-loopback | Critical | ❌ | -25 |

**Risk:** Unauthenticated LAN-exposed gateway allows any network device to invoke agent commands
and read memory contents. This is the highest-severity misconfiguration.

---

### 4. Dependency Vulnerabilities

From `DATA.security.vulnerabilities`:

| Finding | Score Impact |
|---------|-------------|
| Critical CVE (CVSS ≥ 9.0) | -15 per CVE (max -45) |
| High CVE (CVSS 7.0–8.9) | -5 per CVE (max -20) |
| Outdated packages (no known CVE) | -2 per package (max -10) |

**Fix:** `clawhub update` or `npm audit fix` (review breaking changes before applying)

---

### 5. VCS Sensitive Info

From `DATA.security.vcs`:

| Finding | Status | Score Impact |
|---------|--------|-------------|
| Sensitive files tracked in git | ❌ | -25 |
| `.env` or `*.key` without `.gitignore` coverage | ⚠️ | -10 |

---

## Risk Classification

Classify the overall risk level after scoring all 5 checks:

| Classification | Condition | Required Action |
|---------------|-----------|----------------|
| **Critical** | Any ❌ from credential exposure or unauthenticated LAN bind | Fix immediately |
| **High** | Any other ❌ | Fix before production use |
| **Medium** | Any ⚠️ without ❌ | Fix within this maintenance cycle |
| **Low** | All ✅ | Fix when convenient |

---

## Scoring

```
Base score: 100
Apply all score impacts (cumulative).
Floor: 0. Ceiling: 100.
```

| Score Range | Status |
|-------------|--------|
| ≥ 85 | ✅ |
| 65–84 | ⚠️ |
| < 65 | ❌ |

---

## Output Format

Produce in REPORT_LANG (domain label, risk label, and descriptions translated; paths and commands in English):

```
[Security Risks — translated domain label] [STATUS] — Score: XX/100
[Risk Level label in REPORT_LANG]: [Critical/High/Medium/Low — translated]
[One-sentence summary in REPORT_LANG]

[Credentials label in REPORT_LANG]:
  [type] in [file]:[line] — REDACTED     (if any)
  [Clean message in REPORT_LANG]         (if none)

[Permissions label in REPORT_LANG]:
  [file]: mode [XXX] — should be 600    (if any)
  [Clean message in REPORT_LANG]        (if none)

[Network label in REPORT_LANG]:
  Gateway: bind=[mode], auth=[type] — [risk note in REPORT_LANG]

[Vulnerabilities label in REPORT_LANG]:
  [X critical, X high CVEs]  (if any)
  [Clean message in REPORT_LANG] (if none)

[Identity label in REPORT_LANG]:
  [X devices registered]
  [Permission issue note if any]

[If any ⚠️/❌ — Findings label in REPORT_LANG, ordered by severity:]
1. [CRITICAL/HIGH/MEDIUM — translated] — [description with evidence]
   Fix: [command]
   Rollback: [rollback command]
```


path: flow_summary.md
content: # Phase 6 — Fix Summary

After the fix cycle completes (or is skipped), generate a final summary of actions taken.

## 6.1 — Summary Content

Present to the user (in REPORT_LANG):

```
## Fix Summary

| # | Issue | Domain | Action | Result |
|---|-------|--------|--------|--------|
| 1 | [issue description] | [domain] | [fix applied / skipped / manual] | [fixed / failed / skipped] |

Total: [X] fixed, [X] skipped, [X] failed
```

## 6.2 — Post-Fix Verification

If any fixes were applied:

1. Re-run affected domain checks (Phase 2, targeted mode)
2. Compare before/after scores
3. Present delta:

```
## Score Changes

| Domain | Before | After | Change |
|--------|--------|-------|--------|
| [domain] | XX/100 | XX/100 | +X / -X / = |

Overall: [improved / unchanged / degraded]
```

## 6.3 — Append to Report

Update the previously generated report files:

- **MD report**: Append the fix summary and score changes sections at the end
- **HTML report**: Re-generate with updated data if feasible, otherwise note fixes in MD only

## 6.4 — Remaining Issues

If any issues remain unfixed (skipped or failed), output:

```
## Remaining Issues

[X] issues still open:
1. [issue] — [reason: skipped by user / fix failed / requires manual action]
   Recommended: [command or action]

Next health check will re-evaluate these items.
```

## 6.5 — Final Message

End with a closing message (in REPORT_LANG):

- All fixed: "All issues resolved. System health restored."
- Partial: "X issues fixed, X remaining. Run health check again after manual fixes."
- None fixed: "No fixes applied. Review the report for manual action items."

Include the report file paths for reference:
```
Reports:
  MD:   $OPENCLAW_HOME/memory/health-reports/healthcheck-<timestamp>.md
  HTML: $OPENCLAW_HOME/memory/health-reports/healthcheck-<timestamp>.html
```


path: flow_report.md
content: # Phase 3 — Report Generation

Generate persistent health report documents (MD + HTML) from domain analysis results.

## 3.1 — Output Location

```
$OPENCLAW_HOME/memory/health-reports/
```

Create the directory if it does not exist.

## 3.2 — File Naming

Both files share the same timestamp-based name:

```
healthcheck-YYYY-MM-DD-HHmmss.md
healthcheck-YYYY-MM-DD-HHmmss.html
```

Example: `healthcheck-2026-03-04-153012.md` / `healthcheck-2026-03-04-153012.html`

## 3.3 — Markdown Report Content

The `.md` file must include all of the following sections in order:

```markdown
# OpenClaw Health Report

> Generated: YYYY-MM-DD HH:mm:ss
> Mode: [Full Check / Targeted: <domain>]

## Overview

OpenClaw Health: [X] pass [X] warn [X] error — Overall: [status summary in REPORT_LANG]

## Domain Scores

| Domain | Status | Score | Summary |
|--------|--------|-------|---------|
| [Hardware]  | [STATUS] | XX/100 | [summary] |
| [Config]    | [STATUS] | XX/100 | [summary] |
| [Security]  | [STATUS] | XX/100 | [summary] |
| [Skills]    | [STATUS] | XX/100 | [summary] |
| [Autonomy]  | [STATUS] | XX/100 | [summary] |

## Issue List

(Copy L2 issue table from domain results; if all pass, write "No issues found" in REPORT_LANG)

## Fix Recommendations

(For each issue: one-liner fix command + brief explanation; if none: "No fixes needed" in REPORT_LANG)

## Environment Snapshot

- OS: [platform] [arch] [version]
- Node.js: [version]
- OpenClaw: [version] ([commit])
- Memory: XX.X GB / XX.X GB (XX%)
- Disk: XX.X GB / XX.X GB (XX%)
- Skills: [X] installed, [X] botlearn

---
*Generated by @botlearn/botlearn-healthcheck*
```

## 3.4 — HTML Report Content

The `.html` file is a **self-contained, styled HTML page** suitable for browser viewing.
Use `scripts/generate-report.sh --format html` as the base renderer, or generate inline if
the analysis JSON is not available. The HTML must include:

- Dark-theme styled layout (consistent with existing `generate-report.sh` output)
- Overall status banner with color-coded score
- Domain grid cards with traffic-light colors
- Issue table (if any warnings or errors)
- Environment snapshot section
- Responsive design + print-friendly `@media print` rules
- Footer: `Generated by @botlearn/botlearn-healthcheck · YYYY-MM-DD HH:mm:ss`

## 3.5 — Generation Protocol

1. After Phase 2 domain analysis, construct the report data from the domain results already in memory.
2. Run `scripts/generate-report.sh --input <analysis.json> --format all --output-dir $OPENCLAW_HOME/memory/health-reports/` if analysis JSON was saved, **or** write both files directly using the domain result data.
3. Rename the output files to match the `healthcheck-YYYY-MM-DD-HHmmss.*` naming convention.
4. Verify both files exist and are non-empty.
5. Report to the user (in REPORT_LANG):

```
Report archived:
  MD:   $OPENCLAW_HOME/memory/health-reports/healthcheck-<timestamp>.md
  HTML: $OPENCLAW_HOME/memory/health-reports/healthcheck-<timestamp>.html
```

If HTML generation fails (e.g., Node.js issue), still produce the MD file and note the HTML failure.


path: flow_fix.md
content: # Phase 5 — Fix Cycle

Execute fixes for issues identified in the health report, with user confirmation at every step.
Reference **`fix_cases.md`** for proven fix steps, rollback commands, and prevention strategies per domain.
Reference **`openclaw_knowledge.md`** for platform defaults, CLI commands, and version-specific changes.

## 5.1 — Safety Rules

**Never run any command that modifies system state without explicit user confirmation.**

- Each fix must be confirmed individually
- Always show rollback command before executing
- If user declines a fix, skip it and move to the next
- If a fix fails, report the failure and suggest manual intervention

## 5.2 — Per-Fix Protocol

For each issue (ordered by severity: errors first, then warnings):

```
STEP 1: Show fix plan
  - Issue: [description]
  - Domain: [domain name]
  - Severity: [error / warning]
  - Fix command: [exact command]
  - Rollback command: [exact rollback]
  - Risk: [low / medium / high]

STEP 2: Await user confirmation
  → User confirms → proceed to STEP 3
  → User declines → skip, move to next issue
  → User asks for details → provide explanation, re-ask

STEP 3: Execute fix
  - Run the fix command
  - Capture output

STEP 4: Verify result
  - Re-run the relevant check from Phase 2
  - Compare before/after status
  - Report: [fixed / partially fixed / failed]

STEP 5: Record outcome
  - Track: { issue, fix_applied, result, timestamp }
  - This data feeds into Phase 6 summary
```

## 5.3 — Batch Mode

If user says "fix all" or equivalent:
- Still show all fix plans as a batch summary first
- Await single confirmation for the entire batch
- Execute sequentially, reporting each result
- Stop on any critical failure and ask user how to proceed

## 5.4 — Scope Limits

Do NOT attempt fixes that:
- Require root/sudo access (suggest the command, let user run manually)
- Modify network configuration
- Uninstall or downgrade OpenClaw
- Delete user data or memory files

For these cases, output the recommended command and instruct the user to run it manually.


path: openclaw_knowledge.md
content: # OpenClaw Platform Knowledge

> Reference this file during Phase 2 (Domain Analysis), Phase 4 (Report Analysis), and Phase 5 (Fix Cycle).
> Provides platform defaults, version info, and common CLI commands for accurate diagnosis and repair.

---

## Platform Defaults

| Item | Value |
|------|-------|
| Gateway default address | `http://127.0.0.1:18789` |
| Latest stable version | `2026.3.2` |
| Config file | `$OPENCLAW_HOME/openclaw.json` |
| Log directory | `$OPENCLAW_HOME/logs/` |
| Workspace directory | `$OPENCLAW_HOME/workspace/` |
| Skills directory | `$OPENCLAW_HOME/skills/` |
| Memory directory | `$OPENCLAW_HOME/memory/` |
| Cron directory | `$OPENCLAW_HOME/cron/` |
| Identity directory | `$OPENCLAW_HOME/identity/` |

---

## Common CLI Commands

### Status & Diagnostics

```bash
# Full system status with deep inspection
openclaw status --deep

# Gateway & service health check (structured JSON output)
openclaw health --json

# View recent logs
openclaw logs

# Read-only deep diagnostic (no modifications)
openclaw doctor --deep --non-interactive

# Repair mode: auto-fix issues, suppress workspace suggestions
openclaw doctor --repair --fix --no-workspace-suggestions
```

### Configuration

```bash
# Validate config syntax and structure
openclaw config validate

# Set a config value
openclaw config set <key> <value>

# Example: set gateway bind address
openclaw config set gateway.bind "127.0.0.1"
```

### Service Management

```bash
# Start the agent
openclaw start

# Stop the agent
openclaw stop

# Restart (stop + start)
openclaw restart
```

### Skills Management

```bash
# List installed skills with status
openclaw skills list --status

# Check a specific skill's health
openclaw skills check <skill-name>

# Install a skill via clawhub
clawhub install @scope/skill-name --force
```

### Workspace & Identity

```bash
# Check workspace file status
openclaw workspace status

# Initialize workspace identity files
openclaw workspace init --file <agent|user|soul|tool|identity>
```

### Session Configuration

```bash
# Session config is set in openclaw.json under the "session" key.
# Key fields:

# dmScope — how DMs are grouped:
#   main: all DMs share the main session
#   per-peer: isolate by sender id across channels
#   per-channel-peer: isolate per channel + sender (recommended for multi-user)
#   per-account-channel-peer: isolate per account + channel + sender (recommended for multi-account)

# reset — primary reset policy:
#   mode: "daily" resets at atHour local time; "idle" resets after idleMinutes
#   When both configured, whichever expires first wins

# resetByType — per-type overrides (direct, group, thread)

# parentForkMaxTokens — max parent-session totalTokens when forking thread session (default 100000)
#   If parent totalTokens exceeds this, starts a fresh thread session instead

# maintenance — session-store cleanup:
#   mode: "warn" (logs only) or "enforce" (applies cleanup)
#   pruneAfter: age cutoff for stale entries (default 30d)
#   maxEntries: max entries in sessions.json (default 500)
#   rotateBytes: rotate sessions.json when exceeding this size (default 10mb)
#   maxDiskBytes: optional sessions-directory disk budget
#   highWaterBytes: target after budget cleanup (default 80% of maxDiskBytes)

# threadBindings — thread-bound session features:
#   enabled: master switch
#   idleHours: inactivity auto-unfocus (0 disables)
#   maxAgeHours: hard max age (0 disables)
```

### Rate Limit & Model Config

```bash
# Set request throttle (interval in ms, max requests per interval)
openclaw config set models.rateLimit.interval 1000
openclaw config set models.rateLimit.maxRequests 10

# Check for recent 429 errors
openclaw logs | grep -i "429\|rate.limit" | tail -10
```

Multi-key rotation requires editing `openclaw.json` directly — set `models.providers.<provider>.apiKeys` array and `rotateKeys: true`.

### Cache Management

```bash
# View cache statistics
openclaw cache stats

# Clear specific caches
openclaw cache clear --history
openclaw cache clear --index

# Clear all caches
openclaw cache clear --all

# Set cache limits (recommended)
openclaw config set cache.maxHistory 100
openclaw config set cache.maxIndexSize 1
```

### Cron Tasks

```bash
# List scheduled tasks
openclaw cron list

# Reload cron definitions after changes
openclaw cron reload
```

### Channel Management

```bash
# Quick probe all channel connectivity status
openclaw channels status --probe

# Reconnect a channel
openclaw channel reconnect <channel-name>
```

---

## Version History & Breaking Changes

| Version | Date | Key Changes |
|---------|------|-------------|
| 2026.3.2 | 2026-03-02 | Latest stable. `tools` config required: `profile: "full"`, `sessions.visibility: "all"`. Without this, underlying tools degrade to minimal mode (see `fix_cases.md` Case 2.4). |

---

## Diagnostic Cheat Sheet

Use these commands in sequence for a rapid health assessment:

```bash
# Step 1: Quick status overview
openclaw status --deep

# Step 2: Gateway & service health (structured JSON)
openclaw health --json

# Step 3: Read-only deep diagnostic
openclaw doctor --deep --non-interactive

# Step 4: Check logs for recent errors
openclaw logs

# Step 5: Validate config
openclaw config validate

# Step 6: If issues found, auto-repair
openclaw doctor --repair --fix --no-workspace-suggestions
```

---

## Gateway Health Check

The gateway listens at `http://127.0.0.1:18789` by default.

```bash
# Preferred: use built-in health command (structured JSON output)
openclaw health --json

# Check which process holds the gateway port
lsof -i :18789
```

Always use `openclaw health --json` instead of directly calling the HTTP API.
The JSON output includes gateway reachability, endpoint latency, and service status in a structured format.


path: setup.md
content: # Setup & Prerequisites

> Read this on first activation or when the OpenClaw environment is unverified.
> Execute checks sequentially. Abort and report to the user if any REQUIRED check fails.
> This is a lightweight guard — re-run on every invocation (no persistent marker written).

---

## Step 1 — Required Binaries

Run each command and capture output:

| Binary | Check Command      | Requirement |
|--------|--------------------|-------------|
| `node` | `node --version`   | ✅ Required — must be ≥ 18.0.0 |
| `bash` | `bash --version`   | ✅ Required |
| `curl` | `bash --version`   | ✅ Required |
| `openclaw` | `openclaw --version` | ✅ At least one of these two |
| `clawhub` | `clawhub -V`       | ✅ At least one of these two |
| `jq` | `jq --version`     | ⚠️ Optional — enhances JSON parsing speed |

**Failure conditions — halt immediately and report:**
- `node` missing or version < 18.0.0
- Neither `openclaw` nor `clawhub` found in PATH

**Report format on failure:**
```
❌ Setup Failed: [binary] is missing or incompatible.
  Required: [requirement]
  Found: [actual value or "not found"]
  Fix: [install command for darwin/linux]
```

---

## Step 2 — OpenClaw Home Detection

Resolve `OPENCLAW_HOME` in order:

```bash
# Priority order:
1. $OPENCLAW_HOME environment variable (if set)
2. $HOME/.openclaw (default)
```

Verify the directory exists:
```bash
[ -d "$OPENCLAW_HOME" ] || WARN "OPENCLAW_HOME not found at $OPENCLAW_HOME"
```

If not found: proceed with warning — some data sources will return null.

---

## Step 3 — Expected Directory Structure

Check presence of each subdirectory under `$OPENCLAW_HOME`:

| Directory | Purpose                             | Required |
|-----------|-------------------------------------|---------|
| `agents/` | openclaw agent config               | ✅ Required |
| `logs/` | gateway.err.log and other logs      | ✅ Required |
| `memory/` | Agent memory files                  | ⚠️ Expected |
| `workspace/` | HEARTBEAT.md and active task files  | ⚠️ Expected |
| `cron/` | Scheduled task definitions (*.json) | ⚠️ Expected |
| `completions/` | openclaw bash tool                  | ⚠️ Expected |
| `identity/` | Authenticated device credentials    | ⚠️ Expected |

Missing ⚠️ directories: note as findings in Domain 5 (Autonomous Intelligence) — do not abort.
Missing ✅ directories: include as ❌ finding in Domain 2 (Configuration Health).

---

## Step 4 — Readiness Confirmation

After all checks complete, output a readiness confirmation to the user in REPORT_LANG.
The message must convey: environment verified, OpenClaw home path, Node.js version,
CLI version (openclaw or clawhub), count of directories found, and that data collection is starting.

Example structure (translate all labels to REPORT_LANG):
```
✅ [Environment verified — in REPORT_LANG]
  OpenClaw home: /path/to/.openclaw
  Runtime: node vXX.XX.XX
  CLI: openclaw vX.X.X (or clawhub vX.X.X)
  Directories: X/7 present
[Proceeding to data collection — in REPORT_LANG]
```

---

## Safety Notice

- This skill is **read-only** during the collection phase.
- Fix operations always require explicit user confirmation before execution.
- Credential values are **never** printed — type and file path only.
- No outbound network requests are made outside the local OpenClaw gateway.
- All destructive operations (e.g., `rm`, `chmod`) include rollback commands.


path: README.md
content: # @botlearn/botlearn-healthcheck

OpenClaw Autonomous Health Inspector — collects system data across 5 domains, produces traffic-light reports with scores and fix guidance, and walks the user through repairs.

## How It Works

The health check runs a 6-phase pipeline, fully autonomous:

```
Phase 0: Detect language + operating mode (full check or targeted domain)

Phase 1: Data Collection
    → Run 11 collection scripts in parallel
    → Read 10 config/state files directly
    → Store all data as DATA.* context keys
    → Any failure sets DATA.<key> = null, never aborts

Phase 2: Domain Analysis
    → Analyze 5 health domains (all in parallel for full check)
    → Each domain: base score 100, subtract per-check failures
    → Produce: status + score (0-100) + findings + fix hints

Phase 3: Report Generation
    → Save MD + HTML reports to $OPENCLAW_HOME/memory/health-reports/

Phase 4: Report Analysis
    → Present layered output: one-line status → domain grid → issues → deep analysis
    → Compare with historical reports for trend tracking

Phase 5: Fix Cycle
    → Show fix command + rollback → await user confirmation → execute → verify
    → Never modify system state without explicit confirmation

Phase 6: Fix Summary
    → Actions taken, score changes, remaining issues
```

## 5 Health Domains

| # | Domain | Score Thresholds | What It Checks |
|---|--------|-----------------|---------------|
| 1 | Hardware Resources | ≥80 / 60-79 / <60 | Memory, disk, CPU, Node.js version, cache pressure |
| 2 | Configuration Health | ≥75 / 55-74 / <55 | Config validation, gateway, agents, channels, tools, models, session, security posture |
| 3 | Security Risks | ≥85 / 65-84 / <65 | Credential exposure, file permissions, network bind, VCS secrets |
| 4 | Skills Completeness | ≥80 / 60-79 / <60 | Built-in tools, install capability, skill health, botlearn ecosystem |
| 5 | Autonomous Intelligence | ≥80 / 60-79 / <60 | Heartbeat, cron tasks, memory, doctor output, workspace identity |

## Use Cases

| Scenario | Mode | What Happens |
|----------|------|-------------|
| "health check" / "doctor" | Full Check | All 5 domains analyzed in parallel |
| "check security" / "fix skills" | Targeted | Only the named domain |
| Periodic heartbeat | Full Check | Scheduled automatic inspection |
| After config changes | Targeted | Verify specific domain after modification |

## Fix Cases Knowledge Base

Includes 19 real-world fix cases with proven solutions:

- **Hardware**: Memory pressure, disk critical, Node.js outdated, cache bloat
- **Configuration**: Validation failures, gateway unreachable, channel inactive, tools degraded, API rate limiting (429), model context window too small, fallbacks not configured, concurrency tuning, session optimization
- **Security**: Credentials exposed, files world-readable, LAN without auth
- **Skills**: Broken dependencies, no botlearn skills, missing SKILL.md
- **Autonomy**: Heartbeat stale, no cron tasks, memory bloat, identity missing, OOM/segfault

Each case includes: applicable version, symptom, root cause, diagnosis, fix steps, rollback, and prevention.

## Key Constraints

1. **Scripts First** — Use collection scripts for structured data; read files directly for raw content
2. **Evidence-Based** — Every finding cites the specific `DATA.<key>.<field>` and its actual value
3. **Privacy Guard** — Redact all API keys, tokens, and passwords before output
4. **Safety Gate** — Show fix plan and await confirmation before any system modification
5. **Language Rule** — All output in the user's native language; commands and field names in English

## Triggers

```
health check / diagnose / doctor / check system / system status
troubleshoot / what's wrong / fix my setup
check gateway / check skills / check config / check security / check autonomy / check hardware
体检 / 修复 / 诊断
```

## File Structure

```
botlearn-healthcheck/
├── SKILL.md                       # Entry point: 6-phase pipeline
├── setup.md                       # First-run prerequisites
├── data_collect.md                # Data collection protocol (20 data sources)
├── check_hardware.md              # Domain 1 scoring rules
├── check_config.md                # Domain 2 scoring rules
├── check_security.md              # Domain 3 scoring rules
├── check_skills.md                # Domain 4 scoring rules
├── check_autonomy.md              # Domain 5 scoring rules
├── fix_cases.md                   # 19 real-world fix cases with solutions
├── openclaw_knowledge.md          # Platform defaults, CLI commands, version info
├── flow_report.md                 # Phase 3: report generation
├── flow_analysis.md               # Phase 4: report analysis + trends
├── flow_fix.md                    # Phase 5: fix cycle protocol
├── flow_summary.md                # Phase 6: fix summary
└── scripts/
    ├── collect-status.sh          # Instance status collection
    ├── collect-env.sh             # OS/hardware metrics
    ├── collect-config.sh          # Config validation
    ├── collect-logs.sh            # Log analysis
    ├── collect-skills.sh          # Skills inventory
    ├── collect-health.sh          # Gateway health (fallback)
    ├── collect-precheck.sh        # openclaw doctor output
    ├── collect-channels.sh        # Channel status
    ├── collect-tools.sh           # Tool availability
    ├── collect-security.sh        # Security scan
    └── collect-workspace-audit.sh # Workspace audit
```

## Install

```bash
clawhub install @botlearn/botlearn-healthcheck --force
```

## Version

Current: 0.1.5

## License

MIT


path: flow_analysis.md
content: # Phase 4 — Report Analysis

After report generation, present the analysis to the user and provide actionable insights.

## 4.1 — Output Layers

Present results in sequence. All labels, summaries, and descriptions in REPORT_LANG.
Commands, paths, field names, and error codes stay in English.

### L0 — One-line Status (always show)

```
OpenClaw Health: [X] pass [X] warn [X] error — [summary in REPORT_LANG]
```

### L1 — Domain Grid (always show, domain names in REPORT_LANG)

```
[Hardware]  [STATUS] [XX]  |  [Config]    [STATUS] [XX]  |  [Security] [STATUS] [XX]
[Skills]    [STATUS] [XX]  |  [Autonomy]  [STATUS] [XX]
```

### L2 — Issue Table (only when any warnings or errors exist)

```
| # | Domain | Status | Issue | Fix Hint |
|---|--------|--------|-------|----------|
| 1 | [domain name] | [status] | [issue description] | [fix command] |
```

### L3 — Deep Analysis (only on `--full` flag or explicit user request)

Per flagged domain: Findings → Root Cause → Fix Steps (with rollback) → Prevention.
Load `check_<domain>.md` for comprehensive scoring details and edge case handling.
Load **`fix_cases.md`** for real-world diagnosis patterns and proven solutions.
Load **`openclaw_knowledge.md`** for platform defaults, CLI commands, and version-specific changes.

## 4.2 — Historical Trend Comparison

On subsequent health checks, if previous reports exist in `$OPENCLAW_HOME/memory/health-reports/`,
append a brief **trend comparison** at the end of the MD report:

```markdown
## Historical Trend

| Date | Overall | Hardware | Config | Security | Skills | Autonomy |
|------|---------|----------|--------|----------|--------|----------|
| [previous date] | [status] | [score] | [score] | [score] | [score] | [score] |
| [current date]  | [status] | [score] | [score] | [score] | [score] | [score] |

Change: [+X improved / -X degraded / = unchanged]
```

Only include the most recent 5 historical entries. Read previous `.md` reports to extract scores.

## 4.3 — Follow-up Prompt

After presenting the analysis, ask the user (in REPORT_LANG):

- If issues found: "Found [X] issues. Fix now, or review findings first?"
- If all pass: "All checks passed. View detailed report or archive?"

Wait for user response before proceeding to Phase 5.


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)