A foreman for your repository.

mesthiri triages your issues, implements the small ones, and opens pull requests for you to review. It runs inside the CI you already have: no server, no database, nothing listening on a port.

It never merges anything.

Read the guide See the source

Where it stands

Every milestone has landed, and the test suite drives a live pi process against a stub model server. What has never happened is a run against a real model or a real repository. Until it has, read the guide as a design preview rather than instructions: every transcript in it is designed, not captured.

Six stages, each a CI job

  1. Triageissue events, and a schedule

    Classifies each incoming issue, checks its claims against a checkout of your code, and proposes a priority from your rubric.

  2. Prioritizea schedule

    Scores and ranks the ready backlog.

  3. Codea label, or /implement

    Drives a coding agent to a tested change. The job, not the agent, pushes it and opens the pull request.

  4. Reviewmesthiri's own pull requests

    Reads the diff for correctness, security, performance, and whether it does what the issue asked.

  5. Fixreview findings, or /fix

    Applies the findings and re-runs the tests until they pass.

  6. Retroa schedule

    Reads completed runs and files process-improvement proposals as issues on your repository.

Five of the six also answer a slash command from someone whose own permission on the repository covers it. Prioritize only runs on a schedule: it ranks a backlog, which is not a thing you ask for one of.

What it will never do

  • Merge anything. There is no code path that calls the merge endpoint, and your branch protection is what enforces it.
  • Touch a denied path, including its own configuration.
  • Act on tier 2 work without a human authorizing it.
  • Take instructions from issue text. Issue and pull request bodies are data. A comment telling it to ignore the rubric changes nothing.
  • Reach GitHub from inside the agent. The agent holds no credential and has no route to the forge. It writes files; the job decides what happens to them.
  • Work on itself. mesthiri is never installed on its own repository.

How you get there

  1. See what it would say about your repository without installing anything. It reads your open issues, applies your rubric, and writes nothing.

    mesthiri try owner/repo --rubric docs/dev/github-issues.md

  2. Register two GitHub Apps, one that reads and one that writes, and paste three secrets. The command prints exactly what to put on the form, and stops where a person has to be present.

    mesthiri apps create

  3. Open the pull request that turns it on. Everything starts in dry-run: triage comments its reasoning and applies no labels until you change one line.

    mesthiri install owner/repo --operator "Your Name <you@example.org>"

The guide walks through each step, and through what to do when something goes wrong.