Skill: ivangdavila/auto-update (version 1.0.0)

--- name: Auto-Update (OpenClaw + Skills) slug: auto-update version: 1.0.0 homepage: https://clawic.com/skills/auto-update description: Auto-update OpenClaw and skills with OpenClaw cron, per-skill defaults, backups, and migration-aware summaries. changelog: "Initial release with explicit openclaw cron setup, per-skill defaults, backups, migration review, and update summaries." metadata: {"clawdbot":{"emoji":"🔄","requires":{"bins":["openclaw","clawhub"]},"os":["linux","darwin","win32"],"configPaths":["~/auto-update/"],"configPaths.optional":["./AGENTS.md","./SOUL.md",".clawhub/lock.json","~/.openclaw/openclaw.json","~/.openclaw/workspace"]}} --- ## When to Use Use when the user wants OpenClaw and installed skills to stay updated automatically. This skill sets up a real `openclaw cron add` job, keeps a small control folder in `~/auto-update/`, remembers which skills should auto-update, backs up important files first, reviews migration risk before skill changes, and summarizes what changed after every run. ## Architecture State lives in `~/auto-update/`. If `~/auto-update/` does not exist, run `setup.md`. See `memory-template.md` for structure. ```text ~/auto-update/ ├── memory.md # global defaults, activation, and summary preferences ├── openclaw.md # OpenClaw update mode, channel, backup scope, feature-review prefs ├── skills.md # per-skill policy, installed version, backup, migration state ├── schedule.md # approved timing, timezone, and scheduler owner ├── backups.md # latest OpenClaw and skill backup inventory ├── migrations.md # pending migration checks and user decisions └── run-log.md # recent runs, versions, and outcomes ``` ## Quick Reference | Topic | File | |-------|------| | Setup guide | `setup.md` | | Memory template | `memory-template.md` | | Defaults and modes | `policy.md` | | Scheduler and timing | `scheduler.md` | | Daily execution order | `execution.md` | | Workspace integration | `workspace-integration.md` | | OpenClaw behavior | `openclaw.md` | | Skill policy ledger | `skills.md` | | Backup inventory | `backups.md` | | Migration gate | `migrations.md` | | Rollback rules | `recovery.md` | | Report templates | `reports.md` | ## Quick Start The default model is simple: - create one OpenClaw cron job - let that cron job read `~/auto-update/*.md` - update OpenClaw and only the allowed skills - back up first, then summarize Visible commands the user should recognize: ```bash openclaw update status --json openclaw update --json clawhub update --all --dry-run clawhub update --all ``` Example daily job: ```bash openclaw cron add \ --name "Auto-Update" \ --cron "0 4 * * *" \ --tz "Europe/Madrid" \ --session isolated \ --wake now \ --announce \ --message "Run the auto-update routine. Before changing anything, read ~/auto-update/memory.md, ~/auto-update/openclaw.md, ~/auto-update/skills.md, and ~/auto-update/migrations.md. Then: 1) inspect OpenClaw update status and apply OpenClaw only if openclaw.md says mode:auto 2) inspect skill updates 3) back up the approved OpenClaw files and each skill that is allowed to change 4) skip any skill marked no, pending, or ask-first 5) apply only the allowed updates 6) verify obvious health 7) write backups.md and run-log.md 8) report updated, unchanged, skipped, and failed items." ``` Safer variant: ```bash openclaw cron add \ --name "Auto-Update (Notify First)" \ --cron "0 4 * * *" \ --tz "Europe/Madrid" \ --session isolated \ --wake now \ --announce \ --message "Run the auto-update review. Read ~/auto-update/memory.md, ~/auto-update/openclaw.md, ~/auto-update/skills.md, and ~/auto-update/migrations.md. Inspect OpenClaw updates and run clawhub update --all --dry-run. Do not apply changes for any item in notify, no, pending, or ask-first mode. Report what would change, what is blocked, and which backups would be created." ``` ## How the Run Decides What to Do Each cron run follows the same contract: 1. read `~/auto-update/memory.md` 2. read `~/auto-update/openclaw.md` 3. read `~/auto-update/skills.md` 4. read `~/auto-update/migrations.md` 5. inspect `openclaw update status --json` 6. inspect `clawhub update --all --dry-run` 7. back up allowed targets 8. apply `openclaw update --json` only if core mode is `auto` 9. apply skill updates only for allowed skills 10. summarize updated, unchanged, skipped, and failed items ## Starter Modes | Mode | OpenClaw | Skills | Best for | |------|----------|--------|----------| | Instant daily | `auto` via daily cron run | Daily auto-update for allowed skills | Users who want hands-off freshness | | All-in with review gate | `auto` via daily cron run | New skills inherit auto-update unless migration risk appears | Users who want speed with safety | | All-out skills | `notify` or `manual` | New skills stay manual until approved | Users who want strict control | If the user says "just handle it," default to Instant daily with migration questions still enabled. ## Core Rules ### 1. Auto-Update Means Real Scheduled Updates - The core promise is actual OpenClaw and skill updates, not only policy notes. - The default mechanism is an OpenClaw cron job created with `openclaw cron add`. - That cron job must read the control files in `~/auto-update/` before deciding what to update. - The same scheduled flow checks, backs up, updates, verifies, and reports for both OpenClaw and skills. - If the user approves a daily schedule, create or update the exact scheduler entry that will run daily. Do not leave the cadence only as a note in `schedule.md`. ### 2. Learn a Default for New Skills - Ask once whether new skills should default to all-in or all-out for auto-update. - On every new skill install, ask two things: do they want a quick explanation of the skill, and should that skill auto-update or stay manual. - Record the answer in `skills.md` so later sessions do not guess. ### 3. Back Up Before Changing OpenClaw or Skills - Before OpenClaw updates, snapshot the tailored files and config the user cares about most. - Before each skill update, save the currently installed skill folder and installed version reference. - Log every backup in `backups.md` and reference it in the post-run summary. ### 4. Review Migration Risk Before Skill Updates - Compare the currently installed skill state with the new version before overwriting it. - Flag path, folder, AGENTS, TOOLS, SOUL, setup, or state-storage changes in `migrations.md`. - If migration is unclear or stateful files may move, ask before applying or before first use of the new version. ### 5. Respect the Actual OpenClaw Update Path - Use the documented OpenClaw path: the cron job should inspect `openclaw update status --json` and, if approved, run `openclaw update --json` from the scheduled turn. - `auto`, `notify`, and `manual` live in `openclaw.md`; the cron message must respect them every run. - After OpenClaw updates, run the boring checks: doctor, restart when needed, and health verification. - If the user wants core-only automation, the cron job should skip skills explicitly instead of removing the shared control flow. ### 6. Turn Release Notes into Useful Suggestions - After OpenClaw updates, summarize what changed in plain language. - Offer an optional follow-up review that maps new features or changes to the user's actual workflow. - Never apply workflow changes automatically just because a release note sounds promising. ### 7. Keep the User in Control - Never auto-migrate state, move folders, delete backups, or rewrite workspace behavior files without approval. - Never silently add scheduler entries or workspace reminder snippets; show the exact proposed lines first. - Never modify this skill's own `SKILL.md`. - Heartbeat is never the primary mechanism for exact daily updates. Use heartbeat only for follow-up: install-time reminders, migration reminders, failed-run review, or post-update suggestions. ## Common Traps | Trap | Why It Fails | Better Move | |------|--------------|-------------| | Updating skills with no version ledger | You lose track of what changed and what to restore | Record installed version and backup before each update | | Treating every new skill like the default | Some should stay manual even in all-in mode | Allow per-skill overrides in `skills.md` | | Overwriting a skill before checking migrations | Stateful paths and workspace hooks can break silently | Diff old vs new, then ask if migration is needed | | Updating OpenClaw with no snapshot | Tailored files can be painful to reconstruct | Back up config and key workspace behavior files first | | Reporting raw changelogs only | Users still do not know what matters to them | Give plain summary plus optional workflow review | ## Scope This skill ONLY: - configures real OpenClaw and skill update flows - keeps local defaults and per-skill decisions in `~/auto-update/` - proposes optional install-time reminder integration for new skills - creates backups, migration notes, and run summaries before and after updates This skill NEVER: - auto-migrates user state or folder structures without approval - forces all skills into auto-update when the user chose all-out - edits AGENTS, cron, launchd, Task Scheduler, or `~/.openclaw/openclaw.json` without a visible plan or standing approval - stores secrets in local memory files - modifies its own skill files ## Data Storage Local state lives in `~/auto-update/`: - `memory.md` for durable defaults and activation notes - `openclaw.md` for core updater mode, channel, backup scope, and feature review preferences - `skills.md` for per-skill auto-update policy and installed version history - `schedule.md` for timezone, cadence, and scheduler ownership - `backups.md` for backup paths and retention notes - `migrations.md` for pending migration checks and decisions - `run-log.md` for compact run history and outcomes ## External Endpoints | Endpoint | Data Sent | Purpose | |----------|-----------|---------| | OpenClaw update sources (website installer, npm, or git remote chosen by the user) | version and package or git requests | Update OpenClaw | | ClawHub registry via `clawhub update` | installed skill metadata and version requests | Check and apply skill updates | | Official OpenClaw docs or release notes | version and release-note lookups | Explain changes after update | No other data is sent externally. ## Security & Privacy - This skill stores local policy and logs in `~/auto-update/`. - It may read `.clawhub/lock.json`, `~/.openclaw/openclaw.json`, and workspace behavior files when needed for approved update work. - It backs up files before updates, but never stores secrets in its own local ledgers. - Scheduler changes, workspace integration, OpenClaw config edits, and risky migrations require approval unless the user has already approved that exact class of action. - It never modifies its own `SKILL.md`. ## Trust By using this skill, update traffic may reach OpenClaw update sources, ClawHub, npm, or the git remote chosen by the user. Only install if you trust those services with update checks and package downloads. ## Related Skills Install with `clawhub install <slug>` if user confirms: - `skill-update` - Review risky skill diffs, migrations, and rollback choices in more depth - `backups` - Strengthen backup and restore practices beyond the default updater snapshots - `heartbeat` - Pair exact-time update jobs with adaptive follow-up checks - `self-improving` - Learn recurring update preferences, failure patterns, and workflow opportunities ## Feedback - If useful: `clawhub star auto-update` - Stay updated: `clawhub sync`


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