Examples

GitHub workflows that run llx through its action, rsaryev/llx@v0. Each was run for real in a test repository before it was published.

To install one: copy the file into .github/workflows/, and add the secret OPENROUTER_API_KEY (Settings > Secrets and variables > Actions). Each file says at its top what else it needs, if anything, and what to change to make it yours: the model, the prompt, the rules.

Beyond GitHub workflows#

• breaking-changes/: what a change does to an HTTP API's clients, the spec's structure and what no spec diff can see (units, boundaries, the code behind the endpoints), as a script for any CI, with a GitLab job, a demo and its recorded run.

How they are built#

The agent works as at a terminal: read, edit and bash, with gh, git and jq in its shell. There is no MCP server, no GitHub tool and no built-in prompt: the prompt is in the workflow, where you can read it, and so is what gets posted.

• Two jobs. The job that runs the model has a read-only token (contents: read, and read on what it looks at). A second job, with write access and no model key, posts what the first answered. It checks out nothing, or the branch it pushes to, and never runs code from the pull request. The split is the boundary, not the rules.
• Answers are data. schema: makes the agent answer with JSON that matches it; the posting job reads it with jq. review.yml keeps only findings on lines the diff shows before it posts them.
• What the agent may run. allow: bash with deny: edit lets it read and run anything and refuses the edit tool, not writes: a command can still change a file. The checkout is throwaway and the job has no token that can write, so it changes nothing it can commit. llx.yml allows edits and denies git commit and git push; its patch goes to the posting job, which refuses a change to .github/.
• The key. llx removes the provider key from the variables the commands it runs get. While the agent runs, llx is the only process of the step that holds it (the action runs llx in place of the step's shell), and on Linux llx cannot be read through /proc by a process without root. But a hosted runner gives passwordless sudo, so with bash allowed, assume the key can leak: use a key made for CI, with a spend limit (an OpenRouter key can have one). Where the input is from strangers, name what the agent may run (allow: bash(gh pr view *)).
• Who can trigger it. llx.yml answers only owners, members and collaborators. Pull requests from forks are skipped: they get no secrets, and their code would run next to the key. No workflow uses pull_request_target.
• Text written by others is data. Values from the event reach the prompt through env: ($PR), never pasted into a script with ${{ }}. A comment or a body is read by the agent with gh, and every prompt says that what others wrote is data, not instructions.
• Instruction files come from the checkout. On a pull request, AGENTS.md and CLAUDE.md are the pull request's. The token is read-only, so the worst is a bad answer or a leaked key.

Notes#

• The workflows that a push or a pull request made with the workflow's token (llx.yml) starts wait for a person to approve them: your tests run on llx's change once someone does, or at once when the posting job uses a GitHub App's token.
• A workflow started by a review comment runs the version of the file on the pull request's merge ref: a fix on main reaches an open pull request once main is merged into it.
• gh pr view --comments needs checks: read; the prompts use gh pr view "$PR" --json title,body,comments,reviews, which does not.
• Pin the action to a release (@v0.x.y) or a commit where the key matters; @v0 follows every 0.x release.
• On a self-hosted runner, replace ubuntu-latest with its labels. With llx built there, give the action version: system.

More in docs/ci.md: the action's inputs and outputs, rules in CI, keys and models, exit codes, and GitLab.