devin-cli

Devin CLI

Devin CLI is a separate coding agent on the same machine. devin acp speaks the Agent Client Protocol over stdio; the bundled helper scripts/devin_acp.py drives one turn, answers permission requests from a local policy, and records everything in a run directory. It uses only the Python standard library (3.10+). Resolve the script relative to this installed skill, not the project being worked on.

Devin must already be installed and signed in. Signing in opens a browser, so the user does it with devin auth login; the helper never authenticates and never changes Devin's configuration. If devin is missing, signed out, or out of quota, report that and the work that remains instead of quietly doing the task yourself.

Run a task

python <script> run --cwd <absolute-workspace> --prompt-file <brief.md> [--run-dir <dir>]
python <script> progress --run-dir <dir>
python <script> run --cwd <absolute-workspace> --resume <session_id> --prompt-file <follow-up.md>

run blocks until Devin ends its turn, so start it with your own background facility (a background shell command, nohup ... &, Start-Process) when you have other work. It prints JSON lines: started with the run directory, session with Devin's session ID, and finished with the summary. It exits 0 only when the turn ended normally. Each run gets its own owner-only run directory holding final.md (Devin's final message), summary.json, events.jsonl, and devin.stderr.log; run refuses a directory that already holds a run. The files contain the brief and Devin's output, so keep them out of shared or tracked locations. --help lists every flag; references/protocol.md covers the ACP details.

Write the brief

Devin sees none of your conversation. A brief that works on the first try states, in this order:

1. The goal and why it matters, in a paragraph.
2. The current state: what already exists, what is committed, where.
3. Files to read first, including the project's conventions.
4. The environment: absolute paths to interpreters and tools, environment variables, and the exact commands that build, test, and validate.
5. Scope: the files or modules this task owns, and what other workers own.
6. Rules: leave changes uncommitted; no branch, stash, reset, or push; the directories it must not touch.
7. Done means: commands that must pass and numbers that must hold (for example, the test count must not drop).
8. What the final message must contain: files changed, counts, every intentional deviation, and anything left unfinished.