@action-llama/action-llama 0.12.1 → 0.13.0

package/docs/examples/reviewer/README.md

@@ -1,22 +1,39 @@
 # Reviewer Agent
 
-A code review agent that reviews open pull requests, approves good ones, requests changes on problematic ones, and auto-merges approved PRs with passing CI.
+A code review agent that automatically reviews open pull requests, runs checks, fixes failures, and merges approved PRs.
 
 ## Setup
 
 1. Copy `agent-config.toml` and `ACTIONS.md` into `agents/reviewer/` in your project
 2. Edit `agent-config.toml`:
-   - Set `repos` to the repositories you want reviewed
-   - Adjust `schedule` as needed (default: every 5 minutes)
+   - Set `orgs` to your GitHub organization
+   - Set `author` in `[params]` to filter PRs by author (optional)
 3. Run `al doctor` to verify credentials
 
+## Trigger modes
+
+**Webhook (recommended):** Fires on PR events (`opened`, `synchronize`, `ready_for_review`) and when check suites complete. Requires a GitHub webhook configured in `config.toml` — see [Webhooks docs](../../docs/webhooks.md).
+
+**Scheduled:** Runs on a cron schedule (default: hourly). Searches for open PRs across the configured organization.
+
 ## How it works
 
-Each run, the agent:
+Each run, the agent works on one PR:
+
+1. Finds a PR to review (from webhook trigger or scheduled search)
+2. Acquires a resource lock to prevent duplicate reviews
+3. Clones the repo and checks out the PR branch
+4. Reviews code for security issues and quality
+5. Runs tests, lint, and build — fixes failures (up to 3 rounds)
+6. Squash-merges if all checks pass, or comments with issues found
+
+## Custom Dockerfile
 
-1. Lists all open PRs across configured repos
-2. Reads the diff for each PR
-3. Evaluates correctness, style, tests, security, and performance
-4. Submits a review: approve + merge, request changes, or comment (if CI is failing)
+The reviewer agent uses the `gh` CLI, which isn't in the base image. Add a `Dockerfile` to the agent directory (only needed for [Docker mode](../../docs/docker.md)):
 
-The agent reviews **all** open PRs in a single run and never approves a PR with failing CI.
+```dockerfile
+FROM al-agent:latest
+USER root
+RUN apk add --no-cache github-cli
+USER node
+```

package/docs/examples/reviewer/agent-config.toml

@@ -1,11 +1,21 @@
 credentials = ["github_token", "git_ssh"]
-schedule = "*/5 * * * *"
+schedule = "0 * * * *"
+scale = 4
+timeout = 1800
 
-[params]
-repos = ["acme/app"]
+[[webhooks]]
+source = "github"
+orgs = ["your-org"]
+events = ["pull_request"]
+actions = ["opened", "synchronize", "ready_for_review"]
+
+[[webhooks]]
+source = "github"
+orgs = ["your-org"]
+events = ["check_suite"]
+actions = ["completed"]
 
-[model]
-provider = "anthropic"
-model = "claude-sonnet-4-20250514"
-thinkingLevel = "medium"
-authType = "api_key"
+[params]
+# Organization to monitor during scheduled runs (webhook runs use repo from trigger)
+org = "your-org"
+author = "your-github-username"

package/docs/vps-deployment.md

@@ -38,7 +38,7 @@ Requirements:
 
 #### Provision a new Vultr VPS
 
-Automated provisioning with Vultr as the first supported backend:
+Automated provisioning with Vultr as a supported backend:
 
 1. Configure `vultr_api_key` credential first: `al creds add vultr_api_key`
 2. Run `al setup cloud` and select "Provision a new Vultr VPS"
@@ -46,6 +46,16 @@ Automated provisioning with Vultr as the first supported backend:
 4. Instance is created with cloud-init that installs Docker automatically
 5. Action Llama waits for the instance to become ready
 
+#### Provision a new Hetzner VPS
+
+Automated provisioning with Hetzner Cloud:
+
+1. Configure `hetzner_api_key` credential first: `al creds add hetzner_api_key`
+2. Run `al setup cloud` and select "Provision a new Hetzner VPS"
+3. Pick server type, location, OS image, and SSH key
+4. Server is created with cloud-init that installs Docker automatically
+5. Action Llama waits for the server to become ready
+
 ### How It Works
 
 | Operation | Implementation |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@action-llama/action-llama",
-  "version": "0.12.1",
+  "version": "0.13.0",
   "description": "Automated development agents triggered by cron or webhooks. BYOM — bring your own model.",
   "type": "module",
   "license": "MIT",

package/docs/examples/devops/ACTIONS.md

@@ -1,33 +0,0 @@
-# DevOps Agent
-
-You are a DevOps monitoring agent. Your job is to detect new errors from CI/CD failures and production error tracking, then file actionable GitHub issues for each unique problem.
-
-Your configuration is in the `<agent-config>` block at the start of your prompt.
-Use those values for repos, sentryOrg, and sentryProjects.
-
-`GITHUB_TOKEN` is already set in your environment. Use `gh` CLI directly.
-If Sentry is configured, `SENTRY_AUTH_TOKEN` is set in your environment. Use `curl` for Sentry API requests.
-
-## Workflow
-
-1. **Poll for CI errors** — run `gh run list --repo <repo> --status failure --json databaseId,name,headBranch,conclusion,url,createdAt --limit 20` for each repo.
-
-2. **Poll Sentry errors (if configured)** — run:
-   ```
-   curl -s -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
-     "https://sentry.io/api/0/projects/<sentryOrg>/<project>/issues/?query=is:unresolved&statsPeriod=24h"
-   ```
-
-3. **Deduplicate** — search existing issues to avoid duplicates: `gh issue list --repo <repo> --label agent-filed --state all --json title --limit 100`. Skip errors that already have matching issues.
-
-4. **File GitHub issues** — for each new error, run `gh issue create --repo <repo>`:
-   - **CI failures** — `--title "[CI Failure] <workflow> on <branch>" --body "<details>" --label ci-failure,agent-filed`
-   - **Sentry errors** — `--title "[Sentry] <title>" --body "<details>" --label production-error,agent-filed`
-
-## Rules
-
-- Always check deduplication before filing — never create duplicate issues
-- Include enough context for a developer to start investigating
-- For Sentry errors, include the permalink for full details
-- For CI failures, include the run URL for log access
-- Do not attempt to fix errors yourself — just file issues

package/docs/examples/devops/README.md

@@ -1,23 +0,0 @@
-# DevOps Agent
-
-A monitoring agent that detects errors from CI/CD failures and Sentry production alerts, then files deduplicated GitHub issues for each unique problem.
-
-## Setup
-
-1. Copy `agent-config.toml` and `ACTIONS.md` into `agents/devops/` in your project
-2. Edit `agent-config.toml`:
-   - Set `repos` to the repositories to monitor
-   - Set `sentryOrg` and `sentryProjects` for Sentry integration (or remove if not using Sentry)
-   - Adjust `schedule` as needed (default: every 15 minutes)
-3. Run `al doctor` to verify credentials
-
-## How it works
-
-Each run, the agent:
-
-1. Polls for recent CI failures across configured repos
-2. Polls Sentry for unresolved errors in the last 24 hours (if configured)
-3. Deduplicates against existing `agent-filed` issues to avoid duplicates
-4. Files new GitHub issues with appropriate labels (`ci-failure` or `production-error`)
-
-The agent only files issues — it does not attempt to fix errors itself.

package/docs/examples/devops/agent-config.toml

@@ -1,13 +0,0 @@
-credentials = ["github_token", "git_ssh", "sentry_token"]
-schedule = "*/15 * * * *"
-
-[model]
-provider = "anthropic"
-model = "claude-sonnet-4-20250514"
-thinkingLevel = "medium"
-authType = "api_key"
-
-[params]
-repos = ["acme/app"]
-sentryOrg = "acme"
-sentryProjects = ["web-app", "api"]