This server lets you launch and monitor AI-driven issue-fix runs and promote approved pull requests to production.
Start a dev run with work_ticket: clone a repo, fix a GitHub issue using Claude Sonnet, run quality gates, and open a PR asynchronously.
Track progress with status: get a run digest including current phase, recent agent actions, gate result, and PR URL.
Promote a reviewed PR with promote: deploy via the repo’s deploy path only when the supplied approval_token matches the recorded human-approval marker.
Allows creating pull requests from GitHub issues, running repository gates, and promoting to production on approval.
Reports live CI/build check status for pull requests.
Handles human approval prompts for promoting changes to production.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ashigaru work crunchtools/ashigaru #12"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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-code issue becomes a pull request from ashigaru/issue-N with 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.
Related MCP server: devflow-mcp
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_KEY and its client ID as the variable ASHIGARU_CLIENT_ID (create-github-app-token mints every token from the two).
Run claude setup-token and store the result as the secret CLAUDE_CODE_OAUTH_TOKEN.
Set the variable ASHIGARU_ENABLED to true.
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 |
Categories, the confidence threshold, which labels mean what | |
The two-job split, the pre-commit inner loop, what is refused | |
What triggers a round, how findings are answered, the round limit | |
Backlog selection and the hourly budget | |
Turning releases on per repository, how the version is chosen and rewritten, the releases record | |
First-pass review of outside pull requests, and the inbox issue | |
Who holds which credential, untrusted input, the switch and the caps | |
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
GATED. Promote a reviewed PR to production via the repo's deploy path.
Refuses unless approval_token matches the human-approval marker recorded
for this PR (set only through a confirmed Signal approval). This is the hard
gate on the one irreversible action — the coding agent never reaches it.
Inputs: pr (required), approval_token (required). Returns: object
Return an on-demand digest of a run: current phase, recent agent actions, gate result, and PR URL. This is what Kagetora answers from when you ask "what's the runner doing?".
Inputs: run_id (required). Returns: object
Start a dev run: clone , fix GitHub issue # with Claude (Sonnet), run the repo's quality gates, and open a PR. Returns a run_id immediately; the run continues in the background. Poll status(run_id) for progress.
Inputs: repo (required), issue (required). Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 3 tools
Each tool serves a unique purpose: starting a run, monitoring status, and promoting to production. There is no overlap in functionality.
All names are simple and readable, but there is a slight inconsistency: 'promote' and 'status' are single words while 'work_ticket' is a compound. However, the style is uniform overall.
With only 3 tools, the server feels minimal for a deployment pipeline. While it covers the essential steps, additional tools like cancellation or listing runs would be expected for broader utility.
The tool set covers the core workflow (start, check, promote), but lacks common operations such as canceling a run, retrying, or viewing history. The surface is functional but not comprehensive.
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
An MCP server that gives your AI access to the source code and docs of all public github repos
A MCP server built for developers enabling Git based project management with project and personal…
Create, deploy, and operate MCP servers directly from your GitHub repositories.
