Skip to main content

​
Agent Playbook

Use these as the universal setup prompt set for coding agents and human developers. The primary path is agent-first.

​
Primary setup command

docex setup --use-case "vision analysis for security scanning" --framework auto --top-up 5 --json
The --top-up value is a USD wallet recharge amount. The agent should show the approval URL to the human, wait for wallet recharge approval, then wire the returned DOCEX_API_KEY and DOCEX_BASE_URL into the server runtime.

​
Per-agent prompts

​
Codex

Setup docex in this app for receipt scanning with server-side uploads and normalized JSON output

​
Claude Code

Install and wire Docex into this codebase. Run docex setup, wait for browser approval, add env config, upload handling, and a server-side vision analysis flow for invoice images.

​
OpenCode / Cursor

Add Docex to this project for vision and OCR analysis. Detect the framework, run docex setup, add API key wiring, and scaffold a working analysis route.

​
Human quickstart

  1. Ask your coding agent to run docex setup
  2. Approve GitHub auth and a prepaid wallet recharge in the browser
  3. Let the agent add DOCEX_API_KEY and DOCEX_BASE_URL
  4. Call run() with a file and prompt

​
Expected agent behavior

  1. Detect the package manager from lockfiles or project conventions
  2. Detect the app shape (Next.js App Router, Express, or unsupported)
  3. Install docexdev with the user’s package manager
  4. Run docex setup --use-case "<workflow>" --framework <auto|next|node> --top-up 5 --json
  5. Show the browser approval URL to the human if setup is still pending
  6. Add DOCEX_API_KEY and DOCEX_BASE_URL to server-side environment wiring
  7. Create or update a thin shared Docex client wrapper
  8. Scaffold one server-side analysis entrypoint that accepts a file and prompt
  9. Tailor the prompt and output handling for the user’s vision use case
  10. Run a smoke analysis or explain the exact command to run once a fixture is provided
  11. Explain the exact files changed and how to test the integration

​
Constraints

  • Prefer prompt-guided analysis by default
  • Keep output normalized JSON unless the user explicitly asks for plain text
  • Use server-side Docex calls only — do not expose DOCEX_API_KEY to browsers
  • Treat the dashboard as approval, billing, usage, and debugging support, not the primary setup path
  • Preserve existing project conventions where possible
  • If the stack is unsupported, do not fake a full scaffold. Add the package, env guidance, and the smallest working integration point