# TryCase > TryCase tests connected GitHub pull requests and returns verdicts, screenshots, and captioned demo videos. ## Documentation - [CLI and agent skill documentation](https://www.trycase.dev/docs): Human-readable installation, command reference, workflow, output contract, safety rules, and exit codes. - [TryCase CLI skill](https://www.trycase.dev/skills/trycase-cli/SKILL.md): Portable SKILL.md for coding agents. - [Pricing](https://www.trycase.dev/pricing): Plans and end-to-end testing-hour allowances. - [FAQ](https://www.trycase.dev/faq): Runtime accounting, limits, retries, and subscriptions. ## Machine discovery The installed CLI is the authoritative source for its current command contract: ```sh npx -y trycase@latest capabilities --pretty ``` Normal commands emit one versioned JSON envelope. `verify follow` emits NDJSON state-change events and a final envelope. Errors are JSON on stderr with stable process exit codes. ## Important constraints - TryCase verifies pushed GitHub pull requests; it does not verify uncommitted local changes. - Never pass authentication tokens as CLI arguments. Use interactive device authorization or set `TRYCASE_TOKEN` and `TRYCASE_API_URL` together. - Treat results as provisional while `terminal` is false. - If `requiresAttention` is true, surface `attentionReason` and `actionUrl` to the user. - For missing secrets, use `secret list ` to inspect requested names, then `secret set --env-file --name --yes` (or `--from-environment`) after the user approves the exact names and local sources. Add `--host NAME=hostname` when an opaque key must reach an external service that TryCase cannot infer. Select verified development/test values only. Never print values or pass them as command arguments. Only pending requested names are accepted; deployment approval remains separate in the web app. See [the secrets workflow](https://www.trycase.dev/docs#secrets). - Use a stable `--request-id` when retrying an ambiguous `verify run` or `verify message` request.