just-vibeGeneral · apply by default
/automate
Turn a repetitive process into a script or workflow
Use for a repeatable local workflow; github-actions owns scheduled CI workflow files, and any other scheduled service requires an actual separately scoped runtime.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select automate from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv automate, /just-vibe automate and /jv:automate in Claude. See shortcut setup and context examples.
/just-vibe:automate Create a repeatable local script to validate our release artifacts./just-vibe:automate Automate report generation when an earlier run left half the output./just-vibe:automate Inspect automation requirements without installing a scheduler or contacting services.What the agent does
- Observe the current steps, isolate the deterministic operations, and define inputs, output ownership, locking and idempotency.
- Implement input validation, failure reporting with meaningful exit statuses, and the defined repeat behavior.
- Test with controlled fixtures and rehearse interruption between durable steps.
Inputs
- repeated process, trigger, inputs, destinations, and error expectations.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Script or workflow implementing the process; registering schedules or enabling external triggers requires that requested action.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; repeated process, trigger, inputs, destinations, and error expectations.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Runnable entry point with usage, input contract, required permissions, repeat-run policy, failure/exit behavior and execution evidence.
How the work is checked
- Repeated execution has deliberate duplicate handling; partial failure exits clearly and preserves recoverable state.
When to stop or clarify
- Do not embed credentials, create unsolicited scheduled jobs, or automate ambiguous human decisions without an explicit rule.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Identify repeated inputs/actions, idempotency, scheduling need, target and partial-failure behavior.
- Method
- Build explicit arguments and stable operation identities with bounded execution and observable results.
- Pitfall
- A script that retries uncertain mutations or interpolates user text into shell source can amplify failures.
- Check
- Run success, repeat and interrupted cases on safe fixtures; creating a script does not mean a recurring scheduler exists.
Situational decisions
When a previous run left partial output: Detect its identity and either resume or stop with a reconciliation instruction; never treat partial output as success.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.