Tasks
Tasks are the main execution surface in OpenVibely. The Tasks page is a project board where users create AI coding work, run it, monitor progress, review output, and decide what happens to generated changes.
The Task Board
Open Tasks from the Workspace section of the sidebar. The board shows project work in user-facing categories.
| Board Area | What It Means |
|---|---|
| Backlog | Planned work that is not currently active. |
| Active | Work the project is currently focused on. |
| Completed | Work that has finished and can be reviewed historically. |
Scheduled tasks are managed from the Schedule page. Chat tasks are internal to chat flows and are not normal board cards.
Search, Filters, And Batch Actions
Use board search to find work. Backlog and Completed column menus offer status and priority filters and sorting; Completed also filters merge outcomes. Clear filters to reveal hidden cards again.
Command-click a card's body on macOS or Ctrl-click on Windows/Linux to select or deselect it without opening the task. Select multiple cards this way or choose Select all in a column menu to run backlog tasks, stop active work, merge eligible completed branches, create pull requests, or delete tasks. Review the selection and any destructive confirmation first. Active retains execution order rather than offering manual sorting.
Creating A Task
Click the plus button (Add Task) to open a new task workspace. Write the request in the thread composer, add attachments, and configure task properties in the Details panel. Send the first message to create the task. Active tasks start execution; Backlog tasks are saved for later. You can configure a schedule before the first send.
| Field | User Impact |
|---|---|
| Title | Names the work on the board and task detail screen. |
| Prompt | Tells the model what to do. |
| Model | Overrides the default model for this task when needed. |
| Agent | Uses a reusable execution profile, or lets the router select automatically. |
| Category | Places the card in Backlog or Active. |
| Priority | Helps order and triage work. |
| Tag | Marks the task as a feature or bug when useful. |
| Auto-merge | Independently merges after successful completion, after an attached goal is achieved, or both. Both triggers are off by default. |
| Attachments | Adds files as extra task context. |
Existing tasks open directly to their thread. Edit properties in the resizable Details panel, switch to Changes for code review, and use the panel's Files, Schedule, Lifecycle, and Chaining views for supporting work. The panel remembers whether it is open across tasks and projects.
Swarm Tasks
Enable Swarm mode when one request should be delegated across multiple task roles. A planner creates independent worker scopes, an optional reviewer checks the combined result, and an optional merger integrates approved work. Each child is a real task with its own thread, model assignment, worktree, diff, retry, and follow-up history.
Set the maximum planned worker count and default isolation in the task workspace, then create the parent in Active or Backlog. Active starts planning; Backlog defers the planner until you run the task or move it to Active. The board groups child status under the parent while still linking to every child task. Uploaded attachments and follow-up requests remain available to the swarm's execution roles.
Max workers limits planned slices, not actual concurrency. Global, project, and per-model limits on the Workers page still determine how many children execute at once. See Swarm Orchestration for roles, isolation, reruns, review, and merge behavior.
Running And Monitoring
Tasks move through statuses such as pending, queued, running, completed, failed, cancelled, and blocked. The page listens for live task events so board state can refresh while work is happening.
Task cards use state icons so execution and review outcomes can be scanned without opening every task. In addition to normal lifecycle states, the icons distinguish achieved goals, merged work, merge failures, and merge conflicts. Hover an icon or focus it with assistive technology to read its state label.
On task detail pages, open the task name in the breadcrumb to search and switch tasks without returning to the board. Running tasks are grouped first, followed by recent tasks or search matches. The current task remains available even when it would fall outside the normal result window, and an open selector refreshes as task state changes.
While a thread response is active, the send control becomes Stop response. This stops the active model run and records cancellation in the thread. It is different from cancelling a queued follow-up before it starts or cancelling the entire task from the board/detail controls.
Around normal execution, lifecycle hooks can recall memory, prepare useful skills, and learn from completed work. Follow-up messages continue from the existing task thread and respect worker capacity, so they may queue when project or model execution slots are full.
Use task detail views to inspect execution output, thread messages, attachments, changed files, review comments, lifecycle activity, and worktree state.
Inspect and edit the Task Goal from the Details panel. Its state distinguishes active, paused, achieved, blocked, cleared, and failed objectives.
Use Command/Ctrl+K to open the breadcrumb selector, Command/Ctrl+Shift+Up or Down to step through tasks, Command/Ctrl+Shift+B to toggle Details, and Command/Ctrl+Shift+D to switch between the thread and Changes. These shortcuts work from the task composer when no foreground dialog is open.
Auto-Merge Triggers
Tasks expose two independent, default-off worktree merge triggers. Auto-merge to target branch on successful completion runs after a successful task turn. Auto-merge to target branch when goal is achieved waits until the stored Task Goal reaches achieved, including when the Goal Agent confirms it after lifecycle review. Enable either or both to match the workflow; paused, blocked, cleared, and failed goals do not trigger a goal-achieved merge.
Both settings use the guarded worktree merge flow. Conflicts, stale branches, missing worktrees, and other unsafe states remain visible for manual recovery instead of being forced through.
Reviewing Work
When a project has a repository attached, task execution can produce worktree-backed changes. Review those changes before merging or creating a pull request.
| Review Surface | Use It For |
|---|---|
| Thread | Follow the conversation and follow-up messages around the task. |
| Execution detail | Inspect model output, errors, and run history. |
| Changes | See modified files, live or preserved diffs, file-level cards, and review comments. |
| Review comments | Track comments attached to generated code. |
| Worktree actions | Merge, clean up, resolve conflicts, or create a PR when supported. |
Task Card Worktree Actions
Eligible worktree-backed task cards expose Local actions without requiring you to leave the board. Choose Merge commit, Fast-forward only, Rebase, or Squash merge according to the history your project needs. OpenVibely shows conflicts or stale-branch state rather than completing an unsafe operation; resolve the issue and review the updated diff before trying again.
When GitHub is configured, the card's GitHub action can open a pull request for the task branch or take you to the already linked pull request. These actions remain review steps: verify the target branch, changed files, and task status before publishing or merging.
Diff Review
Open a task detail page and select Changes to inspect generated code. Worktree-backed tasks can show live branch and uncommitted diffs while work is still active, then fall back to preserved execution diffs after merge or cleanup. The diff viewer groups changes by file, supports large-file lazy loading, and lets reviewers attach comments before sending feedback back to the agent.
Related Pages
| Page | Why It Matters |
|---|---|
| Swarm Orchestration | Coordinates planner, worker, reviewer, and merger child tasks. |
| Runtime Capabilities | Explains which task management actions a run may receive. |
| Task Goals | Persistent objectives that drive autonomous continuation across turns. |
| Task Lifecycle | Explains statuses, hooks, and terminal states. |
| Task Threads & Follow-Ups | Explains how one task continues through follow-up turns. |
| Task Diffs & Review | Explains the Changes tab, live diffs, file cards, and review comments. |
| Lifecycle Hooks | Explains supporting memory, skill, routing, and learning hooks. |
| Git Worktrees & Merge Safety | Explains isolated repository changes. |
| Scheduled Task Runs | Runs tasks later or repeatedly. |
| Task Chaining & Branch Lineage | Connects dependent task work. |