veris-reference

Provides on-demand reference knowledge for testing applications against Veris service twins.

Updated Aug 21, 2026
One-click install
npx skills add https://github.com/veris-ai/plugins --skill veris-reference-veris-ai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: veris-reference
Source: https://github.com/veris-ai/plugins/tree/main/veris/skills/veris-reference
Command: npx skills add https://github.com/veris-ai/plugins --skill veris-reference-veris-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Engineers testing applications against Veris sandbox twins need detailed operational knowledge—seeding state, arming faults, intercepting traffic, reading receipts—without loading every reference document into context at once. This Skill supplies the exact reference file a setup, build, or fix command needs for the step it is on. ## Core Features & Use Cases - On-demand reference routing: Maps each workflow situation (twin inspection, state seeding, faults, webhooks, hosted runners, troubleshooting) to the specific Markdown file to read. - Execution tier guidance: Documents the container, host, direct, and hosted (Daytona/E2B) tiers for running unmodified application code against a twin with production hostnames. - Evidence and fault discipline: Explains receipts, trace watermarks, fault rows, credential modes, and the sandbox clock so test results are attributable to the current run. - Use Case: While fixing a bug where a lost Stripe response duplicates an invoice, the fix command reads faults.md to arm a hang fault with phase: after, then run.md to execute the application's own test through veris run and interpret the receipt. ## Quick Start Ask the veris setup, build, or fix command to handle your task, and it will read the appropriate reference file from this Skill for each step.

Frequently Asked Questions about veris-reference

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test my application against a Veris sandbox twin?▼

Use `veris run` to execute your unmodified application code with production hostnames while outbound HTTP(S) is rerouted to the sandbox. The run ends with a receipt of what the twin received, and `--require-service` fails the run if expected traffic never arrived.

How do I simulate vendor failures like timeouts or 429 errors?▼

Add a fault row to the twin's faults table with `veris sandbox data add`, specifying method, path, and an outcome such as `hang`, `error` with a status, or `latency_ms`. Then drive the application's real code path through it and verify with the trace and stored state.

When should I use the direct tier instead of veris run?▼

Use the direct tier when the application reads every vendor base URL from environment variables, or when a twin is a data plane like Postgres that cannot be intercepted. Verify in code that no hardcoded vendor hostname remains, then wire variables from `veris sandbox exports`.

Can I run Veris tests in a hosted environment without Docker?▼

Yes, the hosted tier runs tests in a Daytona or E2B box attached to your existing twin, routing egress through the Veris gateway. The twin's trace with watermarks replaces the CLI receipt as evidence that the application reached the twin.

Why does veris run exit with code 3?▼

Exit 3 means the run never proved its traffic: an empty receipt on a fresh run, an unmet `--require-*` assertion, or every TLS handshake to a twin rejected. The output names the next step, and troubleshooting.md explains each cause.