What routines can do
- Code review: reviews pull requests against their ticket and acceptance criteria.
- Pre-refinement: reads new tickets against the code and earlier work, and proposes a developer note.
- Team estimation: proposes story points on your own scale, with its reasoning as a comment.
- Autonomous development: builds a ready ticket on a branch of its own, with tests and your quality checks.
- Release notes: writes the notes for a released version from its tickets.
- Definition of ready: checks tickets before refinement or a sprint for missing acceptance criteria, scope, designs and dependencies, and proposes one comment per ticket with what to add.
- Standup digest: prepares the daily standup: what moved since yesterday, what is blocked or stale, pull requests waiting for review, and the risks to the sprint.
- QA pre-check: opens the pages a ticket touches on your test environment as an anonymous visitor, checks the acceptance criteria it can see, with screenshots, and proposes one comment per ticket.
- Release risk: assesses the next release: tickets not yet accepted, changes that need release instructions, risky files and missing tests, with a proposed go or no-go.
- Watch: checks public pages, such as a price page, and reports what changed.
- Scraper watch: reads your web server’s logs with a read-only analyzer, finds callers that harvest prices or products, keeps a list of suspects and proposes blocks. Only after an admin approves, Gunnie.ai blocks addresses in Cloudflare, on its own list and never a caller on the known list, or makes the users of the scraper’s company inactive in the shop. A block in Cloudflare and a block of users in Magento are separate proposals, each approved on its own; one approval never does both. An admin can lift either block again on the Suspects page. Gunnie.ai never changes the company itself, its prices or its orders.
When a routine runs
- On a schedule: chosen days at a set time, Amsterdam time.
- On every new or updated pull request, for code review; checked every five minutes. A pull request is reviewed again only when it has new commits.
- When a ticket enters a status, such as Refinement, for pre-refinement, estimation, the definition-of-ready check, the QA pre-check and building; checked every five minutes. Switching it on only notes the tickets already there; after that, each ticket that enters the status counts once while it stays there.
- By hand, with Run now, which shows the expected cost first.
A routine only reaches the projects and repositories in its own scope, within what the organisation’s connections allow.
Which pull requests a code review picks
- Every open pull request in the routine’s repositories, unless you narrow it down.
- Target branches: only pull requests into these branches, such as master or acceptance.
- Ticket statuses: only pull requests whose Jira ticket, named in the title or the branch, is in one of these statuses, such as Code Review. A pull request whose ticket moves into such a status is reviewed then, even without new commits.
At most two reviews run at once, and a check starts at most two. The others wait in a queue, oldest first, and start on their own as soon as there is room. Routines and Reviews show them as Queued, with the reason. A review that the budget or the credit stops is tried again at a later check.
Proposals, not changes
Whatever a routine wants to change in your systems becomes a proposal on the Approvals page, word for word. The run’s result lists its proposals and their state: waiting, written or rejected. A build is pushed as a branch of its own only after approval and only when an admin allows pushes; it is never merged and never opened as a pull request by Gunnie.ai.
Posting a review on the pull request. On request, Gunnie makes this available for your organisation, and an admin switches it on per code review routine: each finished review of that routine then waits on Approvals, with its verdict, its findings per level and every comment as it will be posted. Once an admin approves it, Gunnie.ai posts a comment per finding and the summary on the pull request, as an approval or a change request. Nothing is posted without that approval, and nothing at all if the pull request changed since the review. It needs a code host connection that may write; for now on Bitbucket. Your admin can ask Gunnie for it.
The verdict as a build status. On request, Gunnie makes this available for your organisation, and an admin switches it on per code review routine. The routine then sets a build status on each commit it reviews, by itself and without an approval: in progress while it reviews, passed when it approves, failed on changes requested or blocking. Require its key (gunnie-ai-code-review, or one you choose) in your merge check, so a new commit waits until Gunnie.ai has reviewed it: in GitHub as a required status check; in Bitbucket, which counts builds rather than one key, by setting the minimum successful builds to your other builds plus this one, with no failed builds. Bitbucket only blocks the merge on Premium plans; on Free and Standard, merge checks are advice. It never approves, comments or merges. On Bitbucket and GitHub; not yet on GitLab.
Following a routine
- Every run shows its result in the control panel under Routines, and code reviews on the Reviews page.
- With Post to Slack on, a code review routine posts each finished review: the pull request, the verdict and how many findings per level, with a link to the result. A clean review is one short line. The findings themselves stay in Gunnie.ai.
- With Post to Slack on, every other routine posts a summary of each run and its waiting proposals to your organisation’s Slack channel, with links to the result and to the approvals. Messages tag only the person who has to act; a run with nothing to act on posts one quiet line, and only a failed run tags the admin. Someone whose Slack address differs from the one in Jira or the code host goes under Systems, Slack, People to tag.
- The call log lists every tool call a run made, and the big screen shows runs starting and finishing as they happen.
Budgets and cost
- Every routine has a monthly budget; a build also has a limit per run.
- Your organisation has a monthly budget across all reviews and routines.
- From 80% the call log notes it; at 100% no new runs start until next month.
- The cost of every run is in the control panel, and the Value page shows runs, approved proposals, cost and an estimate of time saved with its assumption.
Who sets them up
Admins create, change and switch routines on and off in the control panel. Routines run on Claude through Gunnie’s own accounts, never on a key of yours.