Engineering,on autopilot.

Moa runs your whole GitHub workflow — from triage to merge — and gets sharper every run. You keep the merge button.

6
workflows, one engine
0
API keys to set up
1
merge button — yours
mainfeat/issue-142THE AGENToracles/ts · rust · …cited · read-onlyISSUElabeled · moaMERGEchecks greenREAD-ONLYREADtask + sourcesGROUNDEDCONSULTask the oracleREAD-ONLYPLANform the approachWRITESEXECUTEwrites the codecommitsREAD-ONLYREVIEWfindings · verdictread-onlyoraclewrites
The lifecycle

One issue, all the way to merge.

Moa picks up the issue, writes the fix, reviews the PR, gets CI green, and merges. The agent does the thinking; everything around it just works — so the work keeps moving from open to merged without you babysitting it.

readannotates only — never changes your codewriteswrites code to a branch
Issue
GitHub issue opened
Triage
label · comment
read
Solve
branch · code · verify
writes
Pull Request
branch pushed
Review
findings · verdict
read
Fix-CI
read logs · push
writes
Address
resolve threads
writes
Merge
checks green
Review → request changes loops back to Address.Fix-CI / Address push new commits — the PR is handled again.Triage only annotates; it never opens a branch.
Safe by design

The agent only reasons. The machine does the rest.

It writes code and reviews diffs — that's all it can do. It never pushes, never merges, never touches your repo directly. Everything that changes GitHub is plain, predictable code. That line is what makes Moa safe to leave running.

The machine
deterministic code
  • gitbranches, commits & pushes
  • githubissues, PRs, reviews, labels, checks
  • verifyruns the build — node, rust, go, python
The agent
reasoning only
  • readsissues, PR text, review threads
  • writescode, or a review of a diff — nothing else
  • runs asread-only or autonomous — you choose

The agent never pushes. It can't reach the network either — so a malicious issue or comment can't trick it into leaking or fetching anything.

Six workflows

One engine. Six kinds of work.

Triage, solve, review, fix CI, address feedback, merge. Same engine every time — start one from the dashboard, the moa CLI, a GitHub label, or let an event kick it off automatically.

one engine
Triage
$ moa wf triageread-only

Triage

Reads a new issue, sorts it, adds the right labels, and leaves a comment. Never touches code.

read issuecategorizeapply labelscomment

read-only reviews · writes code on a branch · triggered by button, label, or webhook.

Engineering memory

It remembers every move — and learns from it.

Every run leaves a trail Moa can follow later — issues, PRs, reviews, fixes, and the files behind them, all connected. Nothing's forgotten between runs, so it stops repeating mistakes and you can ask your codebase what actually happened.

the graph, as Moa builds it
repoissuePRreviewCIcommitfileroot cause
Captures every action
Triage, solve, review, fix CI, merge, audit — each is recorded automatically, connected to the work it came from.
Ask in plain English
"Why did this fail?" · "Has this bug happened before?" · "Which files break the most?" — answered from what Moa has seen, with links back to the source.
Learns from failures
Before fixing CI, it looks up how the same failure was solved last time — and writes the new fix back. Every run makes the next one smarter.
Report issue

See something off? Just say it.

Describe a bug or paste a whole spec. Moa investigates it in the real code, then files one clean issue — or several — depending on what it actually finds.

A bug → one issue
Describe what you saw. The agent reproduces it in the code, finds the root cause and the files involved, and files a clean, specific issue.
A requirement → several
Paste a spec instead. It reads the repo and splits the work into the natural set of independently-shippable issues — you don’t pick which; it decides.
Or it audits on its own
No input needed: it scans a repo, grounded in past hotspots from memory, and files only real problems as one rolling issue. Nothing, if the repo is clean.

Every issue it files is remembered — so the next audit already knows what was flagged.

Oracles

Give the agent a domain expert on call.

Working in React, Postgres, or Terraform? Give Moa a knowledge base for that domain and the agent checks it before writing a line — so it follows your stack's real patterns instead of guessing. Two ship today, and you can add as many as you like.

100+

domains you can plug in — each is just a folder of docs you drop in.

  • Read-only & sandboxed
    answers only from its knowledge base — nothing else.
  • Consulted, not guessed
    a real step before the agent writes — its answer shapes the plan.
  • Just a folder
    drop in a folder of docs to add a new domain.
shipping today
rust-engineer/INDEX.mdts-engineer/INDEX.md
drop-in domains
reactpostgreskubernetesawsstripe-apigraphqltailwindprismaredisterraformopenapigrpcreactpostgreskubernetesawsstripe-apigraphqltailwindprismaredisterraformopenapigrpc
next.jsdjangogo-stdlibkafkawebgpusolidityswiftuiclickhouseopentelemetrywasmsqliteprotobufnext.jsdjangogo-stdlibkafkawebgpusolidityswiftuiclickhouseopentelemetrywasmsqliteprotobuf
Examples of the kind of knowledge base you can plug in — the agent checks the matching one before it writes.
How the agent thinks

Understand first. Write last.

Every run reads, checks what it needs, and plans before it changes a single line. Writing is the last thing it does — never the first.

1. Read
read-only

Reads the task and the relevant project sources to understand what it is being asked. Changes nothing.

2. Consult oracles
deterministic

Checks the right knowledge base when it needs to, so the plan is grounded in your stack — not guessed.

3. Plan
read-only

Forms a concrete plan from what it read and learned. Still no edits.

4. Execute
write

Carries out the plan — writes the code or produces the review. The only state that can change anything.

Review and triage stay read-only the whole way through — they look, report, and never change a line of your code.

One run

Isolated. Cancellable. Timed out if it hangs.

Every run is sandboxed and tracked step by step. Cancel it whenever you want; if it stalls, it stops itself. Nothing leaks between runs.

queued
waiting for a free slot
01
running
agent working, step by step
02
succeeded
PR, comment, or labels done
03
failed
errored, timed out, or nothing to change
canceled
you stopped the run
why it's safe to leave running
Isolated
Each run works in its own throwaway copy of the repo — runs never step on each other, and every one starts from a clean slate.
Cancellable
Kill any run instantly. Nothing is left half-applied, and nothing reaches your repo until you approve it.
Self-limiting
If a run hangs, it times out and stops on its own — it can never get stuck spinning in the background.