Issues in, fixed bugs out. Ashigaru is a set of reusable GitHub Actions workflows that watch a repository's issues, sort bug-class work from feature work, and fix the bugs: it opens the pull request, answers the code review, and lets GitHub merge when the required checks pass. Feature requests are labeled and left for a maintainer. It runs on GitHub-hosted runners with Claude Code, on a Claude subscription token; there is no server to operate.
Named for the ashigaru (足軽), the foot soldiers a daimyo sent into the field.
- Triage: every new issue is read against the code and labeled. Bug, documentation and performance issues go to the code agent; features wait for a person. An issue from someone without write access is labeled too, but is fixed only when a maintainer says so.
- Code: a
ready-to-codeissue becomes a pull request fromashigaru/issue-Nwith auto-merge on. The repository's own pre-commit hooks run before the pull request opens, and failures go back to the same agent session. - Fix: after each review of a pull request the code agent opened, every finding gets an answer in its thread and failed checks get fixed, for at most five rounds.
- Sweep: every hour the oldest untriaged issues across enrolled repositories are queued for triage, and up to five waiting fixes are started, so a backlog drains without spending the model budget.
- Release: a repository that asks for it with a topic gets its merged work released: a release pull request from the changelog, then the tag and the GitHub Release, so a fix does not sit merged and unshipped.
- Review: a pull request from an outside contributor gets one first-pass comment for the maintainers, and everything waiting on a person is listed in a single inbox issue.
- Authority and limits: the job that runs the model holds no credential that can write; the job that writes runs no model. One organization variable stops everything.
Organization, once:
- Create a GitHub App with repository permissions Contents, Issues and Pull requests set to read and write, install it on the organization, and store its private key as the secret
ASHIGARU_APP_KEYand its client ID as the variableASHIGARU_CLIENT_ID(create-github-app-tokenmints every token from the two). - Run
claude setup-tokenand store the result as the secretCLAUDE_CODE_OAUTH_TOKEN. - Set the variable
ASHIGARU_ENABLEDtotrue. - Require your CI and review checks in a branch ruleset the app cannot bypass, and allow auto-merge.
Each repository:
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/crunchtools/ashigaru/v2/examples/ashigaru.yml \
-o .github/workflows/ashigaru.ymlDetails and the full list of inputs are in docs/enrollment.md.
| Page | What it covers |
|---|---|
| docs/triage.md | Categories, the confidence threshold, which labels mean what |
| docs/code.md | The two-job split, the pre-commit inner loop, what is refused |
| docs/fix.md | What triggers a round, how findings are answered, the round limit |
| docs/sweep.md | Backlog selection and the hourly budget |
| docs/release.md | Turning releases on per repository, how the version is chosen and rewritten, the releases record |
| docs/review.md | First-pass review of outside pull requests, and the inbox issue |
| docs/authority.md | Who holds which credential, untrusted input, the switch and the caps |
| docs/enrollment.md | Organization setup, enrolling a repository, inputs, releasing |
A developer machine needs git, podman, pre-commit and gh.
pre-commit install
podman run --rm -v .:/src:Z -w /src docker.io/library/python:3.12-slim \
bash -c 'pip -q install pytest==9.1.1 pyyaml==6.0.3 ruff==0.16.9 && ruff check . && pytest -q'
podman run --rm -v .:/repo:Z -w /repo docker.io/rhysd/actionlint:1.7.12The design follows Fullsend: labels as the state, a triage gate that routes bugs to a code agent and parks features, and deterministic scripts that hold push and merge authority. The label names are theirs, so a repository can move between the two.
AGPL-3.0-or-later