plugins/src/wiki/skills/lisa-wiki-setup-automations/SKILL.md
Set up the recurring LLM Wiki ingest automation on the local workstation using the CURRENT runtime's native scheduler — Codex automations (the native automations / automation_update mechanism) or, on Claude, /schedule. This skill is a declarative specification: it states WHICH automation to create, how often, and with which command; it does not template schedule files or run scheduling code itself — the runtime's native automation mechanism does the creating. Creates one automation: wiki-ingest, a full /lisa-wiki:ingest cycle, once a day by default (override with cadence). Named and scoped lisa-wiki-auto-<project>-* so it never collides with or clobbers the base /setup-automations set. The wiki counterpart of /lisa:setup-automations — it lives here because the wiki plugin is standalone and installable without the base plugin. Tear down with /lisa-wiki:tear-down-automations.
npx skillsauth add codyswanngt/lisa lisa-wiki-setup-automationsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill is a specification, not a script. It tells the current runtime which recurring wiki automation to create, on what cadence, and with which command — and the runtime creates it with its native scheduling mechanism. Do not hand-template schedule files or write shell to create them; invoke the runtime's automation tool with the spec below.
It is the wiki counterpart of the base /lisa:setup-automations. It is a separate skill because
the wiki plugin (lisa-wiki) is standalone — it can be installed without the base Lisa plugin, in
which case /lisa:setup-automations is not present to schedule ingest. The two skills are
independent and use disjoint name prefixes, so running both is safe.
automation_update tool over hand-writing ~/.codex/automations/<id>/automation.toml; the TOML is
only its backing store). Set the execution environment to local so it runs on this
workstation. Scope it to a durable project automation checkout, not a transient task worktree: use
${CODEX_HOME:-~/.codex}/worktrees/<project>-automation-main when available, create or refresh
that checkout from the project's origin remote if needed, and verify git -C <cwd> rev-parse --is-inside-work-tree --is-bare-repository reports true then false before saving the
automation. Do not point recurring automations at hashed scratch worktrees or a checkout whose Git
metadata is broken./schedule to create a local recurring routine.cadence (default daily) — how often the full ingest runs. Accepts daily, weekly, or an
every-<n>-hours form. Map to a Codex rrule: daily → FREQ=DAILY;INTERVAL=1; weekly →
FREQ=WEEKLY;INTERVAL=1; every N hours → FREQ=HOURLY;INTERVAL=<n>. On Claude, pass the
equivalent /schedule cadence. Default is daily (FREQ=DAILY;INTERVAL=1).The automation runs one cycle of the full wiki ingest and respects that command's own confirmation
and commit/PR policy (never ask before running; run a full ingest across every enabled
non-external-write source; commit/PR per the ingest skill's bookends; report the cycle summary).
Before running the ingest, the automation must attempt to sync its checkout: fetch the default remote
branch and rebase the current automation branch onto it (for the common GitHub case, origin/main).
If the checkout is already on the default branch, fast-forward/rebase it to the remote default. A
dirty working tree is not by itself a blocker: capture git status --short --branch, leave
pre-existing changes untouched, and continue when sync and ingest can run without overwriting those
paths. Abort only when Git reports an actual sync conflict or ingest would need to modify an
already-dirty path; in that case leave existing queue/wiki state unchanged and report the exact
conflicting path(s).
| Automation | Command it runs | Cadence |
|---|---|---|
| wiki-ingest | /lisa-wiki:ingest (no argument → full ingest across all enabled sources) | once a day (or cadence) |
Naming + scope (so teardown is precise). Name the automation with the stable prefix
lisa-wiki-auto-<project>- (i.e. lisa-wiki-auto-<project>-ingest), where <project> identifies
this repo, and scope each Codex automation to the durable project automation checkout described
above. This prefix is deliberately distinct from the base lisa-auto-<project>- set so
/lisa-wiki:tear-down-automations removes exactly this automation and never touches the base
automations or any other project's. Use a project identifier stable across runs and distinct from
other repos (qualify it, e.g. with the owner — don't rely on a bare repo basename that could
collide).
Idempotent. Re-running this skill updates the existing lisa-wiki-auto-<project>-ingest
automation in place (same name) rather than creating a duplicate.
wiki/ exists with a
wiki/lisa-wiki.config.json. If there is no configured wiki, stop and report that the wiki
must be set up first (run /lisa-wiki:setup); do not schedule ingest against a non-existent wiki.List the automation created or updated (name, the command it runs, the resolved cadence), or report that it was skipped and why (no configured wiki / no runtime scheduler).
development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.