Skip to content
Wachiman Docs

Install and use

Install Wachiman

The three steps to add Wachiman to a repository, and where the canonical caller workflow lives.

Installing Wachiman means adding one short caller workflow to your repository, saving your model API key as a repository secret, and naming the one GitHub login that may ask for reviews by comment. Everything runs in your own GitHub Actions with your own key.

The three steps

Section titled “The three steps”
  1. Add the caller file. Copy the public template into .github/workflows/ of your repository. It is a short file: the triggers, the secret it passes, the permission ceiling, and a uses: line that points at the reusable workflow in the public repository.
  2. Add the secret. Save your Anthropic API key as the repository secret ANTHROPIC_API_KEY.
  3. Set the operator. Replace the placeholder operator: value with your own GitHub login. Only that login’s comments can start a review on demand, and the jobs fail with an error while the placeholder is still there.

The canonical caller file is the template in the public repository. This page does not copy it, so there is only one version to read and only one place to fix it.

Which ref to use

Section titled “Which ref to use”

Pin an exact release tag such as v1.4.0, not the floating v1. A pinned tag decides which release runs with your key, and a new release does not reach you until you change that line. The floating v1 tag can move to each compatible release without any change in your repository.

Release tags are covered by a repository ruleset that blocks moving or deleting them, but repository admins can bypass it, so pinning a tag is a decision to trust the maintainers. If you need a reference that nobody can move, use a full commit SHA instead.

Configure Dependabot’s GitHub Actions updates in your repository to propose newer workflow refs as pull requests, and review each one before you merge it. To go back to an earlier release, edit the ref in your caller file and merge that change; this does not undo reviews already posted, money already spent, or a key that leaked.

The first pull request

Section titled “The first pull request”

The first eligible pull request gets an automatic review: it must not be a draft, must come from the same repository, and must pass the operator and key checks. Comment commands such as /wachi review start working once the caller workflow is on your default branch, because GitHub runs issue_comment workflows from there. Replying in a review thread never starts a run by itself.

In the repository

Section titled “In the repository”