Skip to main content
A task is one independently controllable execution. It may run inside a Session or start directly from chat, source control, Linear, the API, or the web dashboard. The task workspace remains the place to inspect operational details such as logs, terminal output, diffs, previews, retries, and artifacts. For a delegated task, use the owning Session for conversation, input, reports, and follow-up. For a standalone task, continue from the task view instead. In either case, open the task view as the execution-review surface when you need evidence for your normal review process. A task is complete only when that evidence is clear enough for a teammate to trust, continue, or reject the result.

​
What to check first

Before you dive into details, check the basics:
  • what Roomote was asked to do
  • which environment or repository context it used
  • whether the task is still running, needs input, or has finished
  • whether Roomote used the expected model, source-control context, and compute environment when those details matter
  • whether the end state matches the kind of outcome you wanted: answer, plan, patch, branch, or PR

​
Sessions and the task board

Use the board view on the Sessions page to scan shared work by lifecycle. Roomote places Sessions in Active, Needs input, Blocked, or Ready from their current task, goal, and run state, so your team does not need to maintain a separate status field. Each Session card shows its owner and participants, recent activity, delegated execution count, workspace or pull-request context, aggregate cost, and unread state. Use the Tasks scope when you only want Sessions containing execution work. Board and list choices remain in the URL so views are shareable.

​
Recover from a failed start

When a task cannot start, select Try in a new task to open an editable task launcher prefilled with the original text prompt, selected model, and linked environment. Review or change those values before starting it. This creates a new task instead of retrying the failed task, and attachments are not copied, so reattach any files the new task needs.

​
Task view

The task view gives you the working context for a run:
  • a header breadcrumb linking back to the owning Session (when you opened the workspace from a filtered Sessions view, browser Back returns to that view)
  • conversation history and Roomote updates
  • inline widgets for structured tables, status cards, plans, and other presentational results an agent chooses to show
  • terminal and runtime logs, including individual environment setup-command logs when setup is still running or needs troubleshooting
  • generated artifacts
  • code diffs
  • previews for running apps
  • task metadata and links back to the surface that started the task
If a task started from Slack, Teams, Telegram, Discord, Linear, or source control, use the task view when the chat or provider thread does not show enough detail to review the work. Presentational widgets remain available in the task transcript; when an agent provides a text fallback, Roomote also sends that fallback to the originating Slack, Teams, Telegram, or Discord conversation. For a Markdown plan artifact, Build this starts a Session and delegates the plan to a task inside it. Roomote preserves the selected environment, branch, and model, and retries the same kickoff if the first launch is interrupted. Use the confirmation link to follow the Session, then open the delegated task for its operational details. Generated HTML artifacts open in a sandboxed Preview by default. Switch to Code to inspect the saved HTML source without executing it in the page that runs the Roomote dashboard.

​
Native widget styling

Roomote widgets inherit the task view’s selected light or dark theme. Agents can use the built-in rw-card, rw-stack, rw-row, rw-grid, rw-stat, rw-badge, rw-callout, and rw-muted classes for common layouts without supplying custom CSS. When a widget needs a custom layout, its CSS can use Roomote’s --rw-* theme variables. The main variables are --rw-background, --rw-surface, --rw-surface-muted, --rw-text, --rw-text-muted, --rw-border, --rw-primary, --rw-accent, --rw-success, --rw-warning, and --rw-danger. This keeps the result visually consistent with Roomote and lets the same widget adapt when the viewer changes themes. Widgets work best as compact visual summaries. Agents should keep labels and datasets concise, choose a height that fits the expected content without scrolling, and use normal task narration or an artifact for longer material.

​
Review the evidence

Roomote is most useful when it can show its work. For implementation tasks, look for:
  • commands, tests, or checks it ran
  • logs or errors it used to make decisions
  • screenshots, recordings, or live previews for UI changes
  • a diff or pull request for code changes
  • a clear explanation when something could not be verified
Roomote chooses screenshots, recordings, both, or no visual proof according to what best demonstrates the work. Screenshots suit stable appearance; recordings can show motion and interactions, even when you did not explicitly ask for a video. Roomote skips visual proof when it would not add useful evidence. Judge the evidence against the stated result rather than requiring a recording for every change. Visual proof should use genuine application, authentication, database, and backend state when practical. When an artifact instead uses disclosed simulated state to make a UI reachable, treat it as evidence only for the rendered appearance, layout, or interaction under that setup. It does not verify real data flow, authorization, backend behavior, network behavior, or an end-to-end journey. The task report and artifact metadata should identify the simulation and state those limits explicitly. When an environment setup command fails, open the task Logs panel and select its Setup: <command> entry. The command’s output is available there without needing to enter the sandbox workspace.

​
Continuing work

You can send follow-up instructions while a task is active. If a task has completed and Roomote has a restorable snapshot, a follow-up can resume from that prior workspace instead of starting over. Snapshot retention depends on the sandbox provider: Modal-backed snapshots do not have Roomote’s seven-day application expiry, while other providers may use a bounded window. When a task delegated from a Fast session asks for input, reply naturally in the originating session. If one input request is pending, Roomote applies a matching reply to that request instead of treating it as a separate task instruction. For an objective that may need several agent turns, use Goal Mode. It keeps the complete outcome in context and can continue the task automatically within a bounded continuation budget. Good follow-ups are specific:
  • “Apply the second option and add a regression test.”
  • “Use the existing settings card pattern instead of adding a new component.”
  • “Open a PR with the fix.”
  • “Explain the tradeoff before changing code.”

​
When to resume versus start a new task

  • Resume the same task when the follow-up depends on the existing workspace, context, or unfinished implementation.
  • Start a new task when the work is a separate objective, should use a different environment, or would make the current task thread too broad.

​
Before you merge or ship

Before you merge changes, review the diff and the verification Roomote ran. Roomote can move quickly, but your normal review process still matters. For implementation work, ask Roomote to include the tests or validation it ran in the final task message. If verification is missing, ask Roomote to run the specific command or explain why it cannot. If the task touched user-facing behavior, inspect the preview, screenshots, or product surface before shipping.

​
Multi-person tasks

Different teammates can run separate tasks in parallel. Teammates can also join the same task conversation when the work needs shared context, for example when a PM clarifies requirements and an engineer reviews the implementation plan.