plugins/lisa-cursor/skills/setup-automations/SKILL.md
Set up the recurring Lisa automations 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 automations to create, how often, and with which parameters; it does not template schedule files or run scheduling code itself — the runtime's native automation mechanism does the creating. Creates five automations: intake-repair (every 60 min), intake PRD (every 60 min), intake tickets (every 10 min), exploratory-bugs (once a day), exploratory-prds (once a day). Two flags — auto-start-prds and auto-start-tickets — control whether the ideated PRDs / filed bug tickets are created auto-pickup-ready (prd_ready / ready) or left for human review (default false). Tear down with /tear-down-automations.
npx skillsauth add codyswanngt/lisa 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 Lisa automations to create, on what cadence, and with which parameters — and the runtime creates them 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.
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 they run on this
workstation. Scope them 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 local recurring routines, one per automation below.auto-start-prds (default false) — passed as prd_ready to the exploratory-prds
automation. true → ideated PRDs are created prd-ready (auto-picked-up by PRD intake); false →
created as drafts for human review. When true, /lisa:project-ideation still checks the configured
PRD queue before writing: existing prd-ready, prd-in-review, prd-blocked, unresolved
prd-ticketed, or unresolved source-reader pressure can intentionally turn the automation cycle into
a blocked/idle outcome instead of creating another ready PRD.auto-start-tickets (default false) — passed as ready to the exploratory-bugs
automation. true → filed bug/usability tickets are created build-ready (auto-picked-up by ticket
intake); false → created in the backlog for human triage.Defaults match the underlying skills — nothing auto-starts unless explicitly opted in. The two flags affect only the two exploratory automations.
Each automation runs one cycle of a Lisa command and respects that command's confirmation policy
(never ask before running; exit cleanly when the queue is idle; report the cycle summary).
Before running the Lisa command, each automation must attempt to sync its checkout.
Fetch the default remote branch, then rebase onto origin/main or the resolved default branch. 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 the sync and selected Lisa command can run
without overwriting those paths. Abort only when Git reports an actual sync conflict or the selected
command would need to modify an already-dirty path; in that case leave queue state unchanged and
report the exact conflicting path(s).
| Automation | Command it runs | Cadence |
|---|---|---|
| intake-repair | /lisa:repair-intake <queue> | every 60 minutes |
| intake-prd | /lisa:intake <PRD queue> (e.g. github intake_mode=prd) | every 60 minutes |
| intake-tickets | /lisa:intake <build queue> (e.g. github intake_mode=build) | every 10 minutes |
| exploratory-bugs | /lisa-<stack>:exploratory-qa ready=<auto-start-tickets> | once a day |
| exploratory-prds | /lisa:project-ideation prd_ready=<auto-start-prds> | once a day |
For a Codex rrule: every 60 min → FREQ=HOURLY;INTERVAL=1; every 10 min →
FREQ=MINUTELY;INTERVAL=10; once a day → FREQ=DAILY;INTERVAL=1.
Exploratory PRD pressure gate. auto-start-prds=true means "create PRDs in the ready PRD
lifecycle when the PRD queue has capacity," not "always create a new ready PRD." The
exploratory-prds automation uses the same PRD source queue and pressure roles reported by
/lisa:queue-status; if pressure exists, the cycle should report the blocking role/ref and the
smallest next action, usually /lisa:intake <PRD queue>, without invoking research or writing a PRD.
Queue resolution. Resolve the intake/repair queue from .lisa.config.json — source for the
PRD queue, tracker for the build queue (for the common GitHub case these are github intake_mode=prd and github intake_mode=build, matching how the existing Lisa intake automations
are written).
Naming + scope (so teardown is precise). Name each automation with the stable prefix
lisa-auto-<project>- (e.g. lisa-auto-<project>-intake-tickets), where <project> identifies this
repo, and scope each Codex automation to the durable project automation checkout described above.
This lets /tear-down-automations find and remove exactly this set and never touch other projects'
automations or non-Lisa ones. Use a project identifier stable across runs and distinct from other
repos (don't rely on a bare repo basename when it could collide; qualify it, e.g. with the owner).
Idempotent. Re-running this skill updates the existing lisa-auto-<project>-* automations in
place (same names) rather than creating duplicates.
exploratory-qa command (the
expo / rails / harper-fabric stacks). If the project has no exploratory-qa, skip that
automation and note it — do not invent a command that doesn't exist.List each automation created or updated (name, the command it runs, cadence, and the resolved
auto-start-prds / auto-start-tickets values), plus any automation skipped and why.
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.