adk-evals
Complete reference for writing, running, and iterating on evals (automated conversation tests) for ADK agents. Covers eval file format, all assertion types, CLI usage, and per-primitive testing patterns.
What this skill does
# ADK Evals Skill
## What are Evals?
Evals are automated conversation tests for ADK agents. Each eval defines a scenario — a sequence of user messages or events — and asserts on what the bot should do: what it says, which tools it calls, how state changes, which workflows run, and more.
Evals run against a live dev bot (`adk dev`), so they test the full stack — not mocks.
## When to Use This Skill
Use this skill when the developer asks about:
- **Writing evals** — file format, assertions, turn types, setup
- **Running evals** — CLI commands, filtering, output interpretation
- **Testing specific primitives** — how to test actions, tools, workflows, conversations, state
- **The testing loop** — write → run → inspect traces → iterate
- **CI integration** — exit codes, `--format json` flag, tagging strategies
- **Eval configuration** — idleTimeout, judgePassThreshold, judgeModel
Or when you are developing an ADK bot and need to write the equivalent of unit/end-to-end tests.
**Trigger questions:**
- "How do I write an eval?"
- "How do I test my workflow?"
- "How do I assert that a tool was called with specific params?"
- "My eval is failing, how do I debug it?"
- "How do I test that the bot stays silent?"
- "How do I run evals in CI?"
- "How do I seed state before an eval?"
- "How do I trigger a workflow in an eval?"
## Available Documentation
| File | Contents |
|------|----------|
| `references/eval-format.md` | Complete file format — all fields, turn types, assertion categories, match operators, setup, outcome, options |
| `references/testing-workflow.md` | Running evals, interpreting output, using traces, the write → test → iterate loop, CI integration |
| `references/test-patterns.md` | Per-primitive patterns for actions, tools, workflows, conversations, and state |
## How to Answer
1. **Writing an eval** → Read `eval-format.md` for structure and assertions
2. **Running evals** → Read `testing-workflow.md` for CLI commands and output
3. **Testing a specific primitive** → Read `test-patterns.md` for the relevant section
4. **Debugging a failure** → Combine `testing-workflow.md` (inspect traces) + `eval-format.md` (check assertion syntax)
---
## Quick Reference
### Eval file structure
```typescript
import { Eval } from '@botpress/evals'
export default new Eval({
name: 'greeting',
type: 'regression',
tags: ['basic'],
setup: {
state: { bot: { welcomeSent: false } },
workflow: { trigger: 'onboarding', input: { userId: 'test-1' } },
},
conversation: [
{
user: 'Hi!',
assert: {
response: [
{ not_contains: 'error' },
{ llm_judge: 'Response is friendly and offers to help' },
],
tools: [{ not_called: 'createTicket' }],
state: [{ path: 'conversation.greeted', equals: true }],
},
},
],
outcome: {
state: [{ path: 'conversation.greeted', equals: true }],
},
options: {
idleTimeout: 60000,
judgePassThreshold: 4,
},
})
```
### Turn types
| Turn | When to use |
|------|------------|
| `user: 'message'` | Standard user message |
| `event: { type, payload }` | Non-message trigger (webhook, integration event) |
| `expectSilence: true` | Assert bot does NOT respond |
### Assertion categories
| Category | What it checks |
|----------|---------------|
| `response` | Bot reply text (contains, not_contains, matches, llm_judge) |
| `tools` | Tool calls (called, not_called, call_order, params) |
| `state` | Bot/user/conversation state (equals, changed) |
| `workflow` | Workflow execution (entered, completed) |
| `timing` | Response time in ms (lte, gte) |
### CLI commands
```bash
adk evals # run all evals
adk evals <name> # run one eval
adk evals --tag <tag> # filter by tag
adk evals --type regression # filter by type
adk evals --verbose # show all assertions
adk evals --format json # JSON output for CI
adk evals runs # list recent runs
adk evals runs --latest # most recent run
adk evals runs --latest -v # with full details
```
---
## Critical Patterns
✅ **Every turn needs `user` or `event`**
```typescript
// CORRECT
{ user: 'hello', expectSilence: true }
{ event: { type: 'payment.failed' }, expectSilence: true }
```
❌ **`expectSilence` alone is not a valid turn**
```typescript
// WRONG — missing user or event
{ expectSilence: true }
```
---
✅ **Assert tool params to verify correct extraction**
```typescript
// CORRECT — verifies the LLM extracted the right values
{ called: 'createTicket', params: { priority: { equals: 'high' } } }
```
❌ **Only asserting the tool was called**
```typescript
// INCOMPLETE — doesn't verify params were correct
{ called: 'createTicket' }
```
---
✅ **Use `outcome` for post-conversation state and workflow assertions**
```typescript
// CORRECT — final state checked once after all turns
outcome: {
state: [{ path: 'conversation.resolved', equals: true }],
workflow: [{ name: 'ticketFlow', completed: true }],
}
```
---
✅ **Seed state to test conditional behavior without running setup turns**
```typescript
// CORRECT — start in a known state
setup: {
state: {
user: { plan: 'pro' },
conversation: { phase: 'support' },
},
}
```
❌ **Using conversation turns to set up state (slow and fragile)**
```typescript
// WRONG — depends on the bot correctly processing setup turns
conversation: [
{ user: 'I am on the pro plan' }, // hoping bot sets user.plan
{ user: 'I need help with billing' }, // actual test turn
]
```
---
## Example Questions
**Writing evals:**
- "Write an eval that tests my createTicket tool is called with the right priority"
- "How do I assert that the bot stays silent after an internal event?"
- "How do I test a multi-turn conversation where context is retained?"
**Running evals:**
- "How do I run only regression evals?"
- "How do I see which assertions failed and why?"
- "How do I integrate evals into GitHub Actions?"
**Debugging:**
- "My eval says the tool wasn't called but I think it was — how do I check?"
- "How do I inspect what the bot actually did during an eval?"
**Per-primitive:**
- "How do I test a workflow that uses step.sleep()?"
- "How do I test that state changed from the seeded value?"
---
## Response Format
**Match depth to the question.**
### Simple questions ("what assertions are available?", "how do I run evals?")
Answer directly — show the relevant table or CLI command. Don't generate a full eval file for an informational question.
### Writing an eval
1. Show the complete `new Eval({})` call with realistic field values
2. Include imports (`import { Eval } from '@botpress/evals'`)
3. Briefly explain non-obvious assertions — skip if the assertion is self-explanatory
4. Suggest the CLI command to run it: `adk evals <name>`
### Debugging a failing eval
1. Ask for or show the failing assertion (`expected` / `actual` diff)
2. Suggest opening traces in the Dev Console to see what the bot did
3. Identify whether the issue is in the eval assertion or the bot's behavior
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.