Rovara Code Docs
Documentation /Work with Rovara Code

Tutorial

Your first Quick task

Approve one plan, let Rovara Code code, check and review the change, then review its draft PR.

On this page

Before you start#

Published native workflow · current source reference

Rovara v0.3.4 includes the native workflow. This page follows the inspected mainline source, which may include later changes. Deployment settings and feature flags still apply. Release and coverage details →

You need access to a registered project and its Slack channel, or a coding-tool connection. Starting tasks from Slack needs shared tasks turned on for the Slack service; if AgentX asks an admin to turn them on, see Starting tasks from Slack.

Use Slack’s mention picker to select the app installed in your channel. Its default name still uses AgentX.

Quick is the simplest planning path

Use it for a well-defined fix. For ambiguous or larger work, choose Full.

1. Request a bounded change#

In the project-bound channel, start the request with quick: to go straight to Quick:

@AgentX quick: Make the docs Copy button reset its label after copying.
Announce success accessibly, preserve manual copy if the clipboard fails,
and add checks for success, reset and failure.

Without a prefix, AgentX sorts the request first. A question is answered in the thread. A small change gets a card, “Looks like a small change. I’ll use Quick.”, with Start, Use Full instead and Just answer. An unclear request offers all three. You can also reply quick, full or answer in the thread.

Only the person who asked can choose, and the card waits for a day. Nothing that changes code starts without that click. Other prefixes: full: starts Full, workflow: asks Quick or Full with no suggestion, and chat: goes to the chat agent.

2. Read the plan#

AgentX inspects the request with read-only tools and posts an approval card: what is waiting, up to three summary lines and a link to the plan (a Slack Canvas, or the task page when the workspace cannot create Canvases). Open review opens the task page.

  • Does it describe the change you actually want?
  • Are the acceptance checks useful?
  • Are assumptions or dependencies missing?

Reply in the thread with anything the plan should know. Every reply, yours or a teammate’s, is saved for the task’s next step. Replies never move the task; only the owner’s buttons do.

3. Approve the current version#

Press Approve on the card or the task page. The project’s readiness checks always run; you can add any optional checks the project offers. Your choices are saved with the decision.

To change the plan, press Request changes on the task page with at least one comment or a note. AgentX writes the next version and answers each comment “Done:” or “Not changed because:”. A decision applies to the version it names; an old card cannot approve a newer plan.

4. Let the checks and reviews run#

After approval, AgentX codes the plan in the project’s remote workspace and runs the required and chosen checks on that exact code. When they pass, it starts the separate code and security reviews by itself.

Only problems the change introduced block. An older problem outside the changed lines is noted but does not block. If a check or review blocks, the thread lists the problems with Send back to coding, Retry reviews and Close task. Send back gives the problems to coding, and the checks and reviews run again on the new code.

From a coding tool, the owner can also accept a blocking finding with a reason, which the draft PR then lists. How to read the reviews →

5. Review the draft PR#

When the checks and both reviews pass, AgentX opens a draft PR of exactly the checked code and posts the link in the thread. Its description says what the approved plan set out to do and which checks and reviews passed, and links the task page. If the PR did not open, the thread offers Retry opening the pull request.

Review repository CI and the diff in GitHub. You decide what gets merged.

6. Handle reviewer feedback#

When reviewers comment on the PR, AgentX reviews the comments and posts “PR feedback is ready” in the thread, with its recommendations and the highest priority. Approve the fixes you want, answer its questions, or dismiss. Approved fixes go through checks and reviews again and are pushed to the same PR.

Follow the feedback tutorial →

7. Finish and preserve the work#

The task finishes when GitHub reports its PRs merged. It gives back its workspace, frees its place in your open-task limit, and shows as closed. Canvas copies are cleaned up after the task’s documents and decisions are saved.

To stop a running task from its Slack thread, the owner sends @AgentX stop. A plain stop without the mention is saved as a reply. Workspace and closeout guide →

Docs updated 14 October 2026 How these docs are maintained Report a docs issue

Search documentation

↑ ↓ Navigate · Enter Open · Esc Close