Self Improver Lite

Runs lightweight self-audits of OpenClaw behavior, finds repeated failures, proposes safe config/process improvements, and tracks what changed. Use after inc...

Security Scan

The skill's instructions and requirements are coherent with its stated purpose, but it assumes system-level access and leaves some decision logic vague — require explicit confirmations and limits before use.

Purpose & Capability

The name and description promise lightweight self-audits and safe, minimal changes; the SKILL.md only asks for collecting service status/logs, grouping failures, proposing fixes, and applying low-risk changes such as session cleanup and service restarts — all consistent with a self-improvement/audit tool for an OpenClaw deployment.

Instruction Scope

The runtime instructions are focused on relevant artifacts (systemctl is-active and journalctl -u for the gateway service) and produce structured outputs (grouping, templates). However, the guidance is high-level in places: it authorizes 'apply only low-risk fixes automatically' and lists allowed automatic changes without precise, auditable commands or decision thresholds. That vagueness gives the agent discretionary power over restarts, session cleanup, and config tuning unless the platform enforces confirmation/limits.

Install Mechanism

Instruction-only skill with no install spec and no code files — lowest-risk delivery model. Nothing is downloaded or written to disk by the skill itself.

Credentials

The skill declares no credentials or env vars (proportional). But it implicitly requires access to systemd/journalctl and permission to restart services or edit runtime config to apply fixes. Those are reasonable for an on-host self-audit tool but are privileged operations that should be explicitly authorized and constrained by the user or platform.

Persistence & Privilege

always:false and no install means the skill won't be force-included, which is appropriate. The skill does assume the ability to perform system-level actions during runs; because agents can invoke skills autonomously by default, ensure per-action approvals or conservative autonomy settings so restarts and cleanup are not performed unexpectedly.

Assessment

This skill appears to do what it says: read recent service status/logs, identify recurring failures, and propose or perform small, reversible fixes (e.g., session cleanup, gateway restart, safe config tweaks). Before installing or running it in production: (1) Confirm where the agent will run and whether it has systemd/journalctl access; (2) Require explicit user approval for any restart, config edit, or cleanup action (the SKILL.md's 'auto-allowed' list should be enforced by the platform, not left to the skill); (3) Ensure backups and rollback paths exist and are tested; (4) Restrict the agent's ability to read broader logs or sensitive files beyond the service units it needs; (5) Run initially in a staging environment to validate the decision thresholds and outputs. If you want stronger guarantees, ask the developer to replace vague rules ('low-risk fixes') with explicit, auditable command lists and per-action confirmation prompts.

Goal

Continuously improve reliability without risky autonomous changes.

Trigger Cases

• Bot is silent or unstable
• Same error appears repeatedly (rate_limit, orphaned, timeout, sendMessage failed)
• After major config updates
• Scheduled weekly health review

Audit Steps

1. Collect evidence:

systemctl is-active openclaw-gateway ollama
journalctl -u openclaw-gateway -n 120 --no-pager

2. Group failures by pattern and count.
3. Identify top 1-3 root causes.
4. Propose minimal, reversible fixes.
5. Apply only low-risk fixes automatically.
6. Record summary and next actions.

Auto-Allowed Changes

• Session cleanup when orphaned user message loops
• Gateway restart for stuck polling
• Context window/maxTokens tuning within known-safe ranges
• Fallback chain reordering (no key changes)

Requires Explicit User Approval

• New API provider onboarding
• Social network account actions
• Financial/crypto operations
• Credential rotation or deletion
• Any destructive file cleanup beyond sessions/log rotation

Weekly Review Template

## Weekly Self-Audit
- Period: <dates>
- Uptime notes: <short>

### Top Errors
1. <error> — <count>
2. <error> — <count>

### Changes Applied
- <change 1>
- <change 2>

### Measured Impact
- Response latency: <before -> after>
- Failed runs: <before -> after>

### Next Improvements
- <single highest-impact next step>

Guardrails

• Never expose secrets in reports.
• Always keep a rollback path (backup old config before edits).
• Prefer one change per cycle to keep causality clear.