Explorbot can learn about your application through knowledge files. This helps agents make better decisions — especially for authentication, special workflows, or app-specific behavior.
explorbot learnOpens a TUI form where you can:
- Enter a URL pattern
- See existing knowledge for that URL
- Add new knowledge
explorbot learn "<url-pattern>" "<description>"Examples:
# Login credentials
explorbot learn "/login" "Use credentials: admin@example.com / secret123"
# General knowledge (applies to all pages)
explorbot learn "*" "This is a React SPA. Wait for loading spinners to disappear."
# Specific page behavior
explorbot learn "/checkout" "Credit card field requires format: XXXX-XXXX-XXXX-XXXX"While exploring, use the /learn command:
/learn # Opens interactive form
/learn Test user: test@example.com # Adds to current page
| Pattern | Matches |
|---|---|
/login |
Exact path /login |
/admin/* |
Any path starting with /admin/ |
* |
All pages (general knowledge) |
^/users/\d+ |
Regex: /users/ followed by digits |
~dashboard |
Contains "dashboard" anywhere in URL |
Knowledge is stored in ./knowledge/ as markdown files with frontmatter:
---
url: /login
title: Login Page
---
Test credentials:
- email: admin@example.com
- password: secret123
Notes:
- Submit button disabled until email validates
- 3 failed attempts triggers captcha
- "Remember me" checkbox persists session for 30 days| Field | Purpose |
|---|---|
url |
URL pattern to match (required) |
title |
Human-readable title (optional) |
| Custom fields | Any additional metadata for agents |
Knowledge files support variable interpolation using ${namespace.key} syntax. Variables are resolved when knowledge is loaded.
Use ${env.VARNAME} to reference environment variables. This keeps secrets out of knowledge files.
---
url: /login
---
Login credentials:
- email: ${env.LOGIN}
- password: ${env.PASSWORD}Missing environment variables are replaced with an empty string.
Use ${config.path} to reference values from explorbot.config.js using dot notation.
---
url: *
---
Base URL: ${config.playwright.url}
Browser: ${config.playwright.browser}Any scalar config value can be referenced. Object values are replaced with an empty string.
| Namespace | Source | Example |
|---|---|---|
env |
process.env |
${env.API_KEY} |
config |
explorbot.config.js |
${config.playwright.url} |
Expressions with unknown namespaces (e.g. ${other.value}) or without a namespace (e.g. ${value}) are left as-is.
Knowledge files can include automation commands that execute when navigating to matching pages. This is useful for handling loading states, cookie banners, or page-specific setup.
| Field | Type | Description |
|---|---|---|
wait |
number |
Wait for specified seconds after page load |
waitForElement |
string |
Wait for element to appear (CSS selector) |
code |
string |
Execute CodeceptJS code after navigation |
statePush |
boolean |
Use history.pushState instead of full navigation |
---
url: /dashboard
wait: 2
waitForElement: '.dashboard-loaded'
---
Dashboard requires data to load before interaction.---
url: /app/*
code: |
I.waitForElement('.app-ready');
I.click('.cookie-accept');
I.wait(1);
---
App pages need cookie consent dismissed and loading complete.Knowledge code has access to CodeceptJS effects for error handling and retries:
| Effect | Purpose |
|---|---|
tryTo(fn) |
Execute without failing - returns true/false |
retryTo(fn, maxTries, interval) |
Retry on failure with polling |
within(context, fn) |
Execute within a specific element context |
Example with effects:
---
url: /dashboard
code: |
await tryTo(() => I.click('.cookie-dismiss'));
await retryTo(() => {
I.click('Reload Data');
I.waitForElement('.data-loaded');
}, 5, 500);
---
Dashboard may show cookie banner. Data loads asynchronously - retry reload if needed.Note
Effects are async - use await when calling them in knowledge code.
For single-page apps where full page reload breaks state:
---
url: /settings/*
statePush: true
---
Settings uses client-side routing. Use pushState to preserve app state.Tip
Use knowledge automation for page-specific behaviors. For agent-specific logic (like running code only during testing), use Agent Hooks instead.
When navigating to a page, automation executes in this order:
- Navigation (
I.amOnPage()orhistory.pushState) wait(if specified)waitForElement(if specified)code(if specified)
---
url: /login
---
Credentials: test@example.com / testpass123
OAuth: Use "Continue with Google" for SSO testing
2FA: Code is always 123456 in test environment---
url: /checkout
---
Required fields: name, email, card number, expiry, CVV
Card format: XXXX-XXXX-XXXX-XXXX
Test card: 4111-1111-1111-1111, any future expiry, any CVV
Promo code "TEST10" gives 10% discount---
url: *
---
- App uses React Router, wait for route transitions
- Loading spinner class: .spinner-overlay
- Modals block interaction until dismissed
- Session expires after 15 minutes of inactivity---
url: /users
---
Test users available:
- admin@test.com (admin role)
- user@test.com (standard user)
- readonly@test.com (view-only permissions)When an agent operates on a page, it receives relevant knowledge based on URL matching:
- Navigator — Uses credentials, knows about special interactions
- Researcher — Understands page structure, hidden elements
- Planner — Incorporates edge cases, validation rules into test scenarios
- Tester — Uses test data, knows expected behaviors
- Start with auth — Add login credentials before exploring protected areas
- Use
*for globals — Document app-wide behaviors (loading states, timeouts) - Be specific — Include exact selectors, formats, and values when known
- Update as you learn — Add knowledge when agents struggle with interactions
./knowledge/
├── login.md # /login page
├── checkout.md # /checkout page
├── general.md # * (all pages)
└── admin_users.md # /admin/users/*
Files are named based on URL pattern. Multiple entries for the same URL are appended to the same file.
- Agent Hooks - Per-agent custom code execution
- Configuration - Full configuration reference
- Page Interaction - How agents interact with pages