Skip to main content
Keystroke is built for coding agents. The keystroke CLI works headlessly out of the box: every command runs non-interactively, invoke and inspect commands print JSON, and the docs are a command away so your agent can learn how Keystroke works as it builds. This page covers agent-specific behavior. For installation and the full command list, see the CLI reference.

​
Baseline context and docs

keystroke init scaffolds an AGENTS.md guide (symlinked to CLAUDE.md) with concise baseline context — the CLI, project layout, discovery, and working habits — that most coding agents read automatically. The CLI keeps AGENTS.md in sync with your installed version whenever you run a command in the project. Use keystroke docs search and keystroke docs query for deeper reference. For anything deeper, your agent reads the docs directly from the CLI — no auth, no project required:

Docs for agents

How your agent searches and reads the Keystroke docs while it builds.

​
A deploy-first build loop

Most agent work follows one loop: edit src/, deploy to your platform project, then run and inspect what’s deployed with the CLI. Deploy often — run a full deploy, or --filter to redeploy a single module fast. Before wiring in an integration, inspect its action schema, run keystroke credentials list, and execute the action once against the intended account with keystroke apps execute. This catches missing permissions and account-specific IDs before they are embedded in an agent or workflow. Do not run lint, typecheck, or build as separate steps before deploy. keystroke deploy gates on lint and typecheck automatically — attempt deploy, read the failure, fix, and redeploy.
Use keystroke test when you want a fast local loop on unit or integration tests — it is not a deploy prerequisite. After a deploy, runtime commands target that project automatically — your agent has no config to manage. Keep work-in-progress out of deploys with @keystroke ignore (see deploy individual files). app execute resolves credentials like the runtime does — project default → org default. In a linked project the project scope resolves automatically; otherwise pass --project <slug>. Pin a specific instance (and the only way to use a user credential) with --credential <slug>; see Actions. If the project already exists but its code isn’t on this machine, keystroke pull --project <slug> downloads the active deploy source and installs dependencies — a common way for an agent to bootstrap a working tree before the loop above.

​
Headless mode

Every command runs without prompts, so agents and CI never block on input.
  • keystroke init my-app --yes skips all prompts. The CLI also goes headless automatically in a non-TTY environment (piped output, CI runner).
  • Destructive commands require explicit confirmation via -y, --yes instead of an interactive prompt:
If a required value is missing in headless mode, the command exits with an error describing what’s needed rather than waiting for input.

​
Machine-readable output

Invoke and inspect commands (workflow, agent, trigger, history, credentials, health, and friends) print JSON to stdout so your agent can parse results directly. No flag is needed; JSON is the default for these commands.
Errors are written to stderr, and the process exits non-zero on failure: Lifecycle commands (init, dev, start, build, deploy) print human-readable status instead; they drive your project rather than return data.

​
Injecting secrets from the environment

Agents should never hardcode secrets. When setting a credential, read the value from an environment variable with @env::
--set key=@env:VAR reads VAR from the shell, falling back to the project’s .env when it isn’t set in the environment. Use --set key=value only for non-sensitive literals.

​
Move or copy credentials across scopes

Prefer these over creating a second connection when the secret or OAuth account already exists:
You must be allowed to manage the source and access the destination (project membership for project targets; user scope is always the authenticated user). Full detail: change scope and duplicate.

​
Headless OAuth

Connecting a provider opens a browser by default. In a headless environment, print the authorize URL instead so it can be handed to a human to complete:

​
Closing the loop

After invoking a workflow or agent, start with a concise summary, then request richer detail only when you need it:
--summary and --field avoid digging through nested envelopes. --include pulls in steps, messages, events, and traces when you need the same visibility you’d get in the web app. Workflows use durable runs; agents use durable sessions.

​
Report build friction

The Keystroke team cannot see errors, confusion, or workarounds inside a local coding session. When your agent encounters unclear docs, confusing CLI behavior, unexpected framework constraints, repeated trial and error, or missing capabilities, it should send a short report after completing the work and before its final response:
The command requires authentication and an active organization. The report body is freeform, and the platform adds the signed-in user’s identity and organization automatically. Reports should read like a note to a team member with zero context: plain language first, one numbered item per issue, technical detail after the plain explanation — keystroke feedback create --help prints the full writing guide. Do not include secrets, credentials, private source dumps, proprietary code, or personal data from project files or user inputs. Your agent does not need to mention the report in its response to you unless you ask. See feedback create for the command reference.

​
Authentication and CI

Deploying and invoking a deployed project require a one-time browser login:
The token is stored in your operating system’s secure credential store and reused on every subsequent command, so an agent that runs after you’ve logged in can deploy and operate cloud projects without re-authenticating.

CLI reference

Every command and flag.