Agent Skills

An agent that drives jevitate for you needs to know which command fits the job, what to pass it, and what it must never do on its own. Jevitate ships that knowledge as skills, installed by jevitate init. The agent never drives the browser itself: it picks the command, passes the user's intent, and reports what came back.

Install

jevitate init                       # keys (at a terminal), skills, MCP registration, the repo's .jevitate/
jevitate init --dry-run             # show what it would install or register, change nothing
jevitate init --skip-skills         # everything except the skills
jevitate init --targets claude-code,cursor   # install to these agents, whatever is detected

init installs the same twelve skills to every agent it finds:

init also registers the jevitate mcp server for Claude Code, Cursor and Codex (MCP & CLI).

Update

Skills ship with the CLI, so a new release can change them. Update the CLI, then run init again:

npm install -g @jevitate/cli@latest --prefer-online
jevitate init            # rewrites the skills you haven't edited; skips the ones you have
jevitate init --force    # also overwrite your edits (shows them first with --dry-run)

init remembers what it installed. A skill you haven't edited is updated in place; one you have edited is left alone and reported, unless you pass --force.

The skills

How an agent picks a skill

jevitate-getting-started is the entry point. It checks the setup once per session (jevitate ai status --json; a missing .jevitate/ means the human runs jevitate init), gets a first useful result, then routes:

# keys, and a task a user does
jevitate explore --url http://localhost:3000 --goal "<task>" --success "urlIncludes:/<done-path>" --real --json
# keys, and a question about the app (read-only by default)
jevitate explore --url http://localhost:3000 --goal "find out <question>; report the answer" --real --json
# no keys: misuse planned in code, findings from hard signals
jevitate explore --strategy adversarial --url http://localhost:3000 --fake-ai --json

MCP tools or the CLI

• If the jevitate MCP tools are in the agent's tool list, it uses them. They take the CLI flags in camelCase (--storage-state becomes storageState), run the same command, and return {exitCode, data}. Exit 2 and every refusal come back as MCP errors, never as a pass.
• Otherwise it uses the CLI with --json and reads the exit code too.
• Some things are CLI-only for a person: record, init, ai setup, ui, source trust. Operator settings (shell hooks, browser binaries, secret sources, log sources) are never tool arguments. The skill tells the human the command instead.

Rules every skill enforces

• Human-only decisions. Promoting a Journey or a mission target, approving annotations or a demo, capturing a regression, trusting a third-party Journey, and approving or cancelling an inbox item happen only when the human asked for that action. A test campaign batches them into a few bulk gates rather than asking one at a time.
• Honest outcomes. 0 clean · 1 defects found · 2 inconclusive (proved nothing, never a pass) · 3 hang · 4 intermittent · 64 nothing ran. The agent reports the outcome it got and never rounds it up.
• Authorized targets only. Never widen --allow beyond what the human authorized, and never point authoring runs or demos at production.
• No workaround browser. Raw browser tools don't exist on purpose. When jevitate refuses, the agent never swaps in another browser-automation tool.
• Secrets stay out of chat and the model. Keys are entered by the human with jevitate ai setup; passwords and codes are bound with --secret-field to an environment variable or a cmd: source, never written on a command line.
• Nothing invented. A Journey id, param or route the agent runs comes from journey find (MCP find_capabilities) in the same session, never from memory.

The skill files

The source of each skill is packages/skills/skills/<skill>/SKILL.md in the jevitate repo. That file is the authority; this page summarises it.