About veris-reference
A reference collection for Veris workflows, organized by the step or topic that setup, build, and fix need. It documents twin operations, execution tiers, evidence, hosted runners, and troubleshooting rather than providing a command itself.
Key features
- 01Guides organized by workflow topic
- 02Documents twin operations and state
- 03Explains direct, container, and hosted runs
- 04Covers evidence and troubleshooting
- 05Includes hosted-provider recipes
Use cases
- 01Looking up the right guide during Veris setup
- 02Understanding sandbox state and reset operations
- 03Interpreting run receipts and test evidence
- 04Following a hosted runner recipe
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ veris-ai/ plugins --skill veris-referenceAfter installing, type/veris-referencein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
daytona.mddirect.mde2b.mdevidence.mdfaults.mdhosted.mdopencode.mdproof.mdrun.mdsession.mdstate.mdtroubleshooting.mdtwin.mdwebhooks.mdagents/openai.yamlscripts/check-setup.pyledger.shrecord.shDetails
From the project READMENot a command. setup, build and fix link to the file a step needs:
| file | read it when |
|---|---|
twin.md | a design rests on a claim about the vendor, or you need to see what the vendor did: manual, schema, operations, data, trace |
state.md | seeding rows and files, isolation inside a sandbox, reset, snapshots and the baseline |
run.md | exercising the change with veris run: the two tiers, the image, what the run hands the workload, the flags that change the verdict, exit codes, what a green proves |
direct.md | the app reads every vendor base URL from the environment and needs no proxy |
session.md | current tools/context indicate an existing plugin-managed sandbox: verify identity, reuse interception, attribute receipts and sync changes |
opencode.md | the existing session is OpenCode: provider tools, credentials, trust, control access and lifecycle differences |
hosted.md | the engineer requests remote tests, or code needs redirection and Docker is unavailable: provider recipes, remote workload preparation, trace evidence, project notes and cleanup |
daytona.md | the hosted tier selects Daytona: published SDK, existing-twin attachment, images, upload, trust, egress, callbacks and deletion |
| e2b.md | the hosted tier selects E2B: published SDK, existing-twin attachment, templates, upload, trust, network policy, callbacks and deletion |
faults.md | the task is about a failure, or a case needs a condition the vendor will not produce on demand: fault rows, credentials, the clock |
webhooks.md | the application receives callbacks |
troubleshooting.md | what the receipt, an exit code, a trace tier, a certificate error, a vendor-shaped error, a 401/404 from /veris/* or a sandboxed agent's doctor lines mean |
evidence.md | writing a concise result with existing evidence and material limitations |
proof.md | interpreting test evidence, investigating retry/identity behavior, or using optional audit helpers |
In a verified plugin session, session.md replaces CLI operations
and lifecycle with the discovered session interfaces. Otherwise twin operations use veris; veris <command> --help documents its flags. Hosted
runner commands are documented in their provider recipe. Every twin operation has a
verb, including file upload (sandbox files import), a per-twin reset
(sandbox reset <twin>) and the operations list (sandbox services operations); never
curl a twin's control URL. The CLI sends the Veris API key itself, so the key is never
exported or printed. The control URL is not the address the app calls, and a vendor
hostname's /veris/* is the vendor's own 404; details in state.md,
The control URL and its key.
scripts/ holds optional record.sh and ledger.sh audit helpers; setup step 9
explains staging when an investigation needs them. Ordinary development does not
require a task ledger or a separate proof phase.