Codaban can take an issue from idea to open PR. You drive it with @codaban comments on the issue — the same model as the review commands.
I don’t trust my own first draft. So I review it like someone else wrote it.
Available on both Forgejo and GitHub. On GitHub the runner works with short-lived per-installation tokens and commits are attributed to the App bot (codaban[bot]).This flow used to be driven by plan / todo labels. It is now comment-driven — applying those labels does nothing. Each command is one deliberate run, one explicit spend. An optional fast / standard / smart tier rides any verb.

​
Plan

Comment @codaban plan on an issue. Codaban spins up an isolated runner with the repo checked out, studies the codebase read-only — it cannot write, commit, or push — and posts the implementation plan as an issue comment. The plan ends with a next-steps line telling you how to proceed.
  • After planning, Codaban suggests a model tier for the implementation by labeling the issue junior / middle / senior — unless you already set one, or named a tier on the command. Your choice always wins.
  • Want changes to the plan? Reply on the issue with your corrections, then @codaban implement — your follow-up comments are folded into the implementation prompt as higher-priority guidance and override the plan where they conflict. Or just re-run @codaban plan.
Codaban won’t run your tests. The runner has no database, test runner, or services set up. Its plan describes what you or CI should verify. It does not run any of it.

​
Implement

Comment @codaban implement with the plan comment in place, and Codaban:
1

Creates a branch

Named {change-type}/{issue}-{slug} — change type from the issue’s feat / fix / … label, chore by default.
2

Implements the plan

All git operations are scripted. The coding agent never touches git itself, so it can’t invent branches or commits.
3

Opens a PR

With a generated description, linked to the issue so it auto-closes on merge, and tagged with the change-type label (created on demand).
One shot: @codaban handle chains plan → implement without waiting for your approval. If the plan finds the work is already done — it reads the working tree — handle stops there and posts a single ”✅ Already resolved — nothing to do” note instead of spending a second run to report no changes. @codaban implement without a plan comment falls back to implementing straight from the issue description. That’s a slower first pass, and empty issues get a polite error comment instead.

​
Iterate

Review the bot’s PR like any other. Codaban iterates when:
  • you comment @codaban iterate (alias address) on its PR — the explicit form, on both Forgejo and GitHub, or
  • (GitHub) you tick a ”🔧 Fix this” or “Fix all findings” checkbox on a review finding, or
  • you submit a review requesting changes on its PR.
It pushes a follow-up commit addressing the feedback, posts a status comment, and replies on each inline review thread it addressed. The session is persistent per issue — iteration builds on the implement context rather than starting cold.
What does not trigger a commit. A plain reply on one of Codaban’s review threads is conversation — Codaban replies but pushes nothing. A plain top-level PR comment does nothing at all: no reply, no commit. Assigning the bot to a PR doesn’t trigger it either.Earlier versions auto-fired the fixer on any comment or assignment, which surprised people by rewriting code on ordinary chatter.
An issue timeline in three steps: a developer comments @codaban handle this, Codaban posts a numbered plan and proceeds without waiting for sign-off, then reports the pull request it opened with a test that fails on main and passes on the branch.

One issue, end to end: the ask, the plan, the pull request.

​
Lifecycle

Runners are torn down when the issue closes or the PR is merged or closed. Per-issue session state is retained for about 30 days, so reopening an issue resumes where it left off.