CLI Reference
The zil CLI provides nine commands for the agent development lifecycle.
zil init
Scaffold a new Zil agent project.
zil init <name> [options]Arguments
| Argument | Description |
|---|---|
name | Project name (kebab-case, 3–64 characters) |
Options
| Option | Values | Default | Description |
|---|---|---|---|
--llm | gemini, anthropic, openai, vertex | gemini | LLM provider |
--framework | adk, openhands | adk | Agent framework backend |
--mcp | none, filesystem, git, custom | none | Include MCP server scaffolding |
--agents | comma-separated names | — | Sub-agent names for multi-agent scaffold (e.g. vta,vtd) |
--skills | comma-separated names | — | Skill names to scaffold in skills/ (e.g. fd-submit-changes,fd-run-tests) |
--service | none, webhook | none | Service mode: webhook scaffolds FastAPI app.py + runner.py with HITL support |
--no-evals | — | — | Skip eval suite scaffolding |
--no-otel | — | — | Skip OpenTelemetry instrumentation |
--non-interactive | — | — | Use defaults for all prompts |
Examples
# Interactive mode (prompts for LLM provider)
zil init my-agent
# Non-interactive with defaults
zil init my-agent --non-interactive
# Specify LLM provider directly
zil init my-agent --llm vertex
# Multi-agent project with webhook service
zil init my-agent --agents vta,vtd --service webhook
# Scaffold with skills
zil init my-agent --agents vta,vtd --skills fd-explore-repo,fd-submit-changes
# Include MCP server scaffolding
zil init my-agent --mcp filesystemGenerated files
zil init produces a complete project with:
manifest.yaml— the Zil agent descriptoradapters/llm.yaml— LLM provider configurationadapters/embed.yaml— embedding provider configurationidentity/persona.md— agent personaidentity/instructions.md— behavior instructionsidentity/guardrails.yaml— hard rules and constraintsevals/config.yaml— eval engine configuration (framework + judge LLM)evals/baseline.yaml— eval suite definitionevals/cases/— example eval test casesobservability/config.yaml— OpenTelemetry configuration{module_name}/__init__.py— Python package init{module_name}/agent.py— agent entry point (useszil.create_agent()){module_name}/.env.example— API key templateDockerfile— multi-stage container build.github/workflows/zil-pipeline.yaml— CI/CD pipelineREADME.md,.gitignore,requirements.txt
With --agents, additionally generates:
agents/{name}/identity/— per-agent identity directories (persona.md,instructions.md,guardrails.yaml)spec.agentsentries inmanifest.yaml
With --service webhook, additionally generates:
{module_name}/app.py— FastAPI webhook entry point with/human/respondHITL endpoint{module_name}/runner.py— execution runner for webhook-driven agents
With --skills, additionally generates:
skills/{name}/SKILL.md— skill stub filesspec.skillsreference inmanifest.yaml
Where {module_name} is the agent name converted to snake_case (e.g., my-agent → my_agent).
Auto-install
After scaffolding, zil init offers to create a .venv and install dependencies from requirements.txt. This includes zil-ai[adk] which pulls in the SDK and Google ADK.
In --non-interactive mode, auto-install runs automatically.
zil validate
Validate a Zil agent project against the manifest schema.
zil validate [options]Options
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory to validate |
--format | text, json | text | Output format |
Exit codes
| Code | Meaning |
|---|---|
0 | Valid — all checks passed |
1 | Invalid — one or more errors |
2 | Warnings only — valid but with recommendations |
What it checks
- Schema validation —
manifest.yamlagainst the Zil v1 JSON Schema - Identity files —
persona.md,instructions.md,guardrails.yamlexist - Guardrails validation —
guardrails.yamlstructure, enforceable rule count, regex validity, output protection warnings - Adapter references — LLM and embedding adapter YAML files exist
- Eval suite —
baseline.yamland referenced case files exist - Observability config —
config.yamlexists, checks for recommended attributes - Environment variables —
spec.envdeclarations, adapter cross-references - MCP tools — source directories exist, entry_point files present, source location convention, env var references
- Multi-agent —
spec.agentsidentity directories, LLM model references, MCP server name references, skill references - Runtime dependencies — warns on unknown dependency types, flags
npm-globalwithoutapt-nodesource(Node.js) - Cost config — budget consistency checks, cross-reference with resource limits
Examples
# Validate current directory
zil validate
# Validate a specific directory
zil validate --project-dir ./my-agent
# JSON output for CI/CD pipelines
zil validate --format=jsonJSON output
{
"valid": true,
"exit_code": 0,
"errors": 0,
"warnings": 0,
"checks": [
{ "status": "pass", "message": "manifest.yaml — schema valid" },
{ "status": "pass", "message": "identity/persona.md — present" }
]
}zil audit
Run an agent-native security audit. Unlike generic dependency scanners, zil audit focuses exclusively on LLM agent-specific attack surfaces.
zil audit [options]Options
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory to audit |
--format | text, json | text | Output format |
--fix | — | — | Show actionable fix suggestions |
Exit codes
| Code | Meaning |
|---|---|
0 | Pass — no critical findings or warnings |
1 | Critical — one or more critical findings |
2 | Warnings only — no critical findings but recommendations exist |
What it checks
| Check | Description |
|---|---|
| Guardrail coverage | Scores coverage across 5 dimensions: injection detection, PII output, PII input, output constraints, denied topics |
| Injection resilience | Runs 20 adversarial prompts through the guardrail engine across 6 attack categories |
| Output leakage | Checks if system prompt, persona, or instructions could leak through output undetected |
| Indirect injection surface | AST-scans tool functions for external data ingestion (HTTP, DB, file reads) without guardrail filtering |
| Instruction consistency | Detects contradictions between permissive persona language and restrictive guardrails |
| Context window risk | Measures system prompt size as a percentage of the model’s context window |
| Identity hardening | Checks persona and instructions for anti-patterns (vague boundaries, missing refusals) |
Examples
# Audit the current project
zil audit
# Audit a specific project
zil audit --project-dir ./my-agent
# Show fix suggestions
zil audit --fix
# JSON output for CI/CD
zil audit --format=jsonSample output
╭─ Zil Security Audit ─────────────────────────────╮
│ Project: my-agent v1.0.0 │
╰───────────────────────────────────────────────────╯
Guardrail Coverage ─────────────────────────────── 4/5
✓ Prompt injection detection enabled
✓ PII output detection enabled
· PII input detection disabled (optional)
✓ Output constraints: max 4000 chars
⚠ Denied topics: none configured
Injection Resilience ──────────────────────────── 19/20
✓ Ignore instructions (4/4)
✓ DAN jailbreak (3/3)
⚠ System prompt extraction (2/3) — 1 bypass
✓ Tag injection (4/4)
✓ Rule override (3/3)
✓ Instruction forget (3/3)
Output Leakage ─────────────────────────────────── PASS
✓ System prompt not reproducible in output
Indirect Injection Surface ─────────────────────── WARN
⚠ tool: fetch_data() — returns external data (HTTP)
✓ tool: calculate() — pure computation
Instruction Consistency ────────────────────────── PASS
✓ No contradictions between persona and guardrails
Context Window Risk ────────────────────────────── PASS
✓ System prompt: ~500 tokens (0.4% of 128,000 context)
Identity Hardening ─────────────────────────────── PASS
✓ Refusal boundaries — present
✓ Scope definition — present
✓ Response format — present
Summary: 0 critical, 2 warningszil pack
Build a .zil archive from a validated agent project.
zil pack [options]Options
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory to package |
--output-dir | path | dist/ | Output directory for the archive |
--skip-evals | — | — | Skip eval suite (warns loudly) |
--sign | — | — | Sign the archive with cosign after building |
--key | path | — | Path to cosign private key (default: keyless/OIDC) |
What it does
- Validates the project (calls
zil validateinternally) - Runs the eval suite — refuses to pack if below the pass threshold
- Generates an SBOM in CycloneDX 1.5 format
- Creates a tar.gz archive with the standard
.zillayout
Archive structure
my-agent-1.0.0.zil
├── manifest.yaml
├── adapters/
├── identity/
├── evals/
├── observability/
├── {module_name}/
├── BUILD_META.json
├── SBOM.cyclonedx.json
└── EVAL_RESULTS.json (if evals ran)Examples
# Package with all defaults
zil pack
# Skip evals during development
zil pack --skip-evals
# Custom output directory
zil pack --output-dir ./artifacts
# Sign with keyless (Sigstore OIDC)
zil pack --sign
# Sign with a private key
zil pack --sign --key cosign.keyzil inspect
Inspect a .zil archive without extracting it.
zil inspect <archive> [options]Arguments
| Argument | Description |
|---|---|
archive | Path to the .zil file |
Options
| Option | Values | Default | Description |
|---|---|---|---|
--show | file path | — | Print a specific file from the archive |
--json | — | — | Machine-readable JSON output |
--verify | — | — | Verify the cosign signature of the archive |
--key | path | — | Path to cosign public key for verification |
Examples
# Summary view
zil inspect dist/my-agent-1.0.0.zil
# Show a specific file
zil inspect dist/my-agent-1.0.0.zil --show manifest.yaml
zil inspect dist/my-agent-1.0.0.zil --show identity/persona.md
# JSON output for CI/CD
zil inspect dist/my-agent-1.0.0.zil --json
# Verify signature (keyless)
zil inspect --verify dist/my-agent-1.0.0.zil
# Verify with public key
zil inspect --verify dist/my-agent-1.0.0.zil --key cosign.pubOutput
Zil Package: my-agent
Version: 1.0.0
Description: A customer support agent.
Framework: adk (python)
Created: 2026-05-07T22:37:15+00:00
Size: 0.1 MB
SBOM: 5 dependencies
Evals: 96.0% (passed)
Components
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━┓
┃ Component ┃ Files ┃ Size ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━┩
│ adapters/ │ 2 │ 305 B │
│ identity/ │ 3 │ 1.4 KB │
│ manifest.yaml │ 1 │ 502 B │
│ my_agent/ │ 4 │ 1.0 KB │
│ SBOM.cyclonedx.json │ 1 │ 1.0 KB │
└─────────────────────┴───────┴────────┘zil push
Push a .zil archive to an OCI-compatible registry.
zil push <archive> --registry <url>Arguments
| Argument | Description |
|---|---|
archive | Path to the .zil file |
Options
| Option | Values | Default | Description |
|---|---|---|---|
--registry | URL | — | OCI registry URL (required) |
Supported registries
- Google Artifact Registry
- GitHub Container Registry (GHCR)
- Amazon ECR
- Docker Hub
- Any OCI-compatible registry
Authentication
Uses ambient credentials:
gcloud auth configure-dockerfor Artifact Registrydocker loginfor Docker Hub / GHCR- Environment variables (
ORAS_*) for custom setups
Examples
# Push to Google Artifact Registry
zil push dist/my-agent-1.0.0.zil \
--registry us-docker.pkg.dev/my-project/agents
# Push to GHCR
zil push dist/my-agent-1.0.0.zil \
--registry ghcr.io/my-org/agentsThe resulting reference is <registry>/<agent-name>:<version>, e.g.:
us-docker.pkg.dev/my-project/agents/my-agent:1.0.0
zil eval
Agent evaluation command group — run suites, add cases, record sessions, generate tests.
zil eval <subcommand> [options]Subcommands
| Subcommand | Description |
|---|---|
run | Run the evaluation suite against the agent |
add | Interactively create eval cases by chatting with the agent |
record | Record a chat session and convert turns into eval cases |
generate | Use the judge LLM to synthesize eval cases from agent identity |
zil eval run
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory |
--suite | string | baseline | Suite to run |
--verbose / -v | — | — | Show per-case details |
--json-output | — | — | Output results as JSON (for CI) |
--threshold | float | — | Override pass threshold |
zil eval add
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory |
--group | string | accuracy | Target case group name |
--suite | string | baseline | Suite to register the group in |
zil eval record
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory |
--group | string | recorded | Target case group name |
--suite | string | baseline | Suite to register the group in |
--auto-accept | — | — | Save all turns without per-turn confirmation |
zil eval generate
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory |
--count / -n | int | 10 | Number of cases to generate |
--group | string | generated | Target case group name |
--suite | string | baseline | Suite to register the group in |
--category | string | — | Focus area (e.g. accuracy, guardrails, edge-cases) |
--no-review | — | — | Save all generated cases without review |
Exit codes
| Code | Meaning |
|---|---|
0 | Suite passed (for run) / command completed |
1 | Suite failed or error |
Examples
# Run baseline eval suite
zil eval run
# Verbose with per-case details
zil eval run --verbose
# JSON output for CI
zil eval run --json-output
# Interactive case builder
zil eval add --group edge-cases
# Record a session
zil eval record --auto-accept
# Generate cases from identity
zil eval generate --count 20 --category guardrails --no-reviewJSON output (from zil eval run --json-output)
{
"suite": "baseline",
"score": 0.92,
"passed": true,
"threshold": 0.85,
"total_cases": 5,
"passed_cases": 5,
"failed_cases": 0,
"groups": [
{
"name": "accuracy",
"pass_rate": 1.0,
"weight": 0.5,
"cases": [...]
}
]
}zil serve
Start the agent as a REST/A2A server. Exposes the agent via REST endpoints with SSE streaming, manifest-declared webhooks, and optionally the A2A protocol for agent-to-agent communication.
zil serve [options]Options
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory |
--port | integer | 8000 | Server port |
--host | string | 127.0.0.1 | Bind address |
--no-a2a | — | — | Disable A2A protocol endpoints |
--reload | — | — | Auto-reload on code changes (dev mode) |
--docker | — | — | Build and run in a Docker container |
--trace | — | — | Enable OTLP trace export to the configured endpoint |
--trace-console | — | — | Print spans to stderr (no collector needed) |
Endpoints
| Method | Path | Description |
|---|---|---|
GET | /health | Health check |
POST | /invoke | One-shot invoke — send a message, get a streaming SSE response |
POST | /sessions | Create a new session (returns session ID) |
POST | /sessions/{id}/messages | Send a message within an existing session (SSE stream) |
GET | /sessions/{id}/stream | Reconnect to an active SSE stream |
DELETE | /sessions/{id} | Close and clean up a session |
GET | /.well-known/agent.json | A2A Agent Card (auto-generated from manifest) |
POST | /tasks/send | A2A task endpoint (synchronous) |
POST | /tasks/sendSubscribe | A2A task endpoint (SSE streaming) |
SSE event stream
Both /invoke and /sessions/{id}/messages return a Server-Sent Events stream. Each event is a JSON-encoded SessionEvent:
data: {"type": "tool_call", "tool_name": "search", "args": {"q": "zil"}}
data: {"type": "tool_result", "tool_name": "search", "result": "..."}
data: {"type": "text", "text": "Based on the search results..."}
data: {"type": "done", "metadata": {"session_id": "abc-123"}}Event types: text, tool_call, tool_result, error, done. See Frameworks for details.
Examples
# Start on default port
zil serve
# Custom port and host
zil serve --port 3000 --host 0.0.0.0
# With tracing
zil serve --trace
# Dev mode with auto-reload
zil serve --reload
# Disable A2A protocol
zil serve --no-a2aDocker mode
Build and run the agent in a Docker container, replicating the production environment locally:
# Build image and run container
zil serve --docker
# With full observability (Grafana OTEL-LGTM stack)
zil serve --docker --trace
# Custom port
zil serve --docker --port 3000Dockerfile auto-regeneration — zil serve --docker regenerates the Dockerfile from manifest.yaml before every docker build, ensuring that spec.runtime.dependencies and spec.tools.host_dependencies are always reflected in the container. You don’t need to manually edit the Dockerfile.
Docker runs also load both .env and .env.local files for complete environment configuration.
When --docker --trace is used, a Grafana OTEL-LGTM container is started alongside your agent, providing:
- Traces (Tempo) — every agent invocation, LLM call, and tool execution
- Metrics (Mimir) — request counts, latencies, token usage
- Logs (Loki) — structured log aggregation
| Service | URL |
|---|---|
| Agent server | http://localhost:8000 |
| Grafana dashboard | http://localhost:3000 |
Default Grafana login: admin / admin.
To explore traces in Grafana:
- Go to Explore (compass icon)
- Select Tempo as the data source
- Click Search → Run query
Both containers stop on Ctrl+C.
zil deploy
Deploy the agent to Google Cloud Run with project/region resolution, pre-deploy eval gating, and automatic project context bundling.
zil deploy [options]Options
| Option | Values | Default | Description |
|---|---|---|---|
--project-dir | path | . | Project directory |
--project | string | — | GCP project (or GOOGLE_CLOUD_PROJECT env var) |
--region | string | — | GCP region (or GOOGLE_CLOUD_REGION env var) |
--service | string | agent name | Cloud Run service name |
--trace | — | — | Enable Cloud Trace telemetry |
--skip-evals | — | — | Skip pre-deploy eval check |
--from | ref | — | Deploy from a .zil file or OCI registry reference |
--env-file | path | — | Dotenv file with env var values (for CI/automation) |
--allow-unauthenticated | — | — | Allow unauthenticated access to the Cloud Run service |
--memory | string | 1Gi | Cloud Run memory limit (e.g. 512Mi, 1Gi, 2Gi) |
--cpu | string | 1 | Cloud Run CPU allocation (e.g. 1, 2, 4) |
--output | text, json | text | Output format — json for machine-readable deploy results |
Prerequisites
-
gcloud CLI installed and authenticated:
gcloud auth login gcloud config set project YOUR_PROJECT_ID -
Required GCP APIs enabled:
gcloud services enable \ run.googleapis.com \ artifactregistry.googleapis.com \ cloudbuild.googleapis.com -
Agent framework installed (e.g.,
zil-ai[adk]).
Walkthrough
# Deploy with explicit project and region
zil deploy --project my-project --region us-central1
# Use env vars instead of flags
export GOOGLE_CLOUD_PROJECT=my-project
export GOOGLE_CLOUD_REGION=us-central1
zil deploy
# Deploy with Cloud Trace telemetry
zil deploy --project my-project --region us-central1 --trace
# Skip evals for a quick re-deploy
zil deploy --project my-project --region us-central1 --skip-evals
# Deploy from a local .zil archive
zil deploy --from dist/my-agent-1.0.0.zil \
--project my-project --region us-central1
# Deploy from an OCI registry
zil deploy --from us-docker.pkg.dev/my-project/agents/my-agent:1.0.0 \
--project my-project --region us-central1What happens during deploy
- Eval gate — runs the eval suite. If evals fail, deployment is blocked (exit code 1). Use
--skip-evalsto override. - Env resolution — collects environment variables from
--env-file, process env, or interactive prompts. Injects them via--set-env-vars. - Dockerfile generation — if
spec.tools.host_dependenciesorspec.runtime.dependenciesare declared, generates a custom Dockerfile with the correctRUNstanzas. See Runtime Dependencies. - Cloud SQL auto-wiring — if
SESSION_DB_URIcontains a Cloud SQL connection string, automatically extracts the instance name and passes--add-cloudsql-instancestogcloud run deploy. gcloud run deploy --source— builds the container image via Cloud Build, deploys to Cloud Run, and routes traffic.- Cleanup — removes bundled files from your local source tree.
JSON output
Use --output json for machine-readable deploy results (ideal for CI pipelines):
zil deploy --project my-project --region us-central1 --output json{
"agent": "my-agent",
"version": "1.0.0",
"service": "my-agent",
"project": "my-project",
"region": "us-central1",
"url": "https://my-agent-abc123-uc.a.run.app",
"endpoints": {
"adk_web": "https://my-agent-abc123-uc.a.run.app/dev-ui",
"webhook": "https://my-agent-abc123-uc.a.run.app/webhook",
"hitl_respond": "https://my-agent-abc123-uc.a.run.app/human/respond"
},
"cloud_sql_instance": "my-project:us-central1:my-instance",
"deployed_at": "2026-05-21T14:30:00Z"
}Pre-deploy eval gate
By default, zil deploy runs the eval suite before deploying. If evals fail, the deploy is blocked:
→ Running pre-deploy eval check...
✗ Eval suite failed: 72.0% (threshold: 85.0%). Deploy blocked. Use --skip-evals to override.Use --skip-evals to bypass:
zil deploy --project my-project --region us-central1 --skip-evalsSecrets on Cloud Run
The .env file is excluded from the container for security. Set secrets via environment variables or Secret Manager:
# Environment variables
gcloud run services update my-agent \
--set-env-vars="GOOGLE_API_KEY=your-key" \
--region=us-central1
# Secret Manager (recommended)
echo -n "your-key" | gcloud secrets create google-api-key --data-file=-
gcloud run services update my-agent \
--set-secrets="GOOGLE_API_KEY=google-api-key:latest" \
--region=us-central1Observability on Cloud Run
With --trace, spans are exported to Google Cloud Trace. View them at:
GCP Console → Observability → Trace Explorer
Metrics and logs are automatically available in Cloud Run’s built-in Observability tab.