Tasks, Git, and GitHub

Create durable tasks

Use New task on the project dashboard when work should remain visible outside one chat. Give the task a title, optional description and acceptance criteria, and either a flow or explicit single-agent configuration.

Tasks can also come from finished Product Design build prompts, existing artifacts, or a venture's build handoff.

Understand task states

Tasks move through backlog, queued, starting, running, completed, failed, canceled, and integration-related states. The queue itself can be idle, running, or paused.

• Run queues selected tasks and starts the queue.
• Queue adds selected tasks without starting.
• Run in parallel creates one parallel stage and starts it.
• Queue in parallel creates the stage but leaves the queue idle or paused.
• Pause queue prevents the next task or stage from starting; it does not silently discard work.

Run sequential work

Sequential stages are appropriate when the next task depends on the current checkout. The queue starts the first available task, opens a linked execution thread, and moves forward when the task completes.

Run parallel worktrees

Parallel stages run independent tasks in isolated Git worktrees and branches. This prevents simultaneous agents from writing into the same checkout.

1. Select at least two tasks.

   They should be independent at the repository level.

2. Run or queue them in parallel.

   Motriz provisions the isolated workspaces and creates an execution thread for each task.

3. Review each completed thread.

   Inspect its changes, validation, and branch.

4. Integrate the branches.

   Merge, cherry-pick, or otherwise combine the desired work into the project checkout.

5. Resume the queue.

   Dependent stages continue against the integrated checkout.

Open Git and GitHub controls

Git controls are available for Git workspaces. They show the current branch, default branch, dirty state, upstream, ahead/behind counts, remote URL, remote head, and the most recent sync result.

Commit local changes

Motriz can commit all dirty files on the current branch or create a new branch first. Enter the branch name and commit message, or ask the app to suggest text from the current changes.

Review the Changes tab before committing. Motriz does not stage only a subset from this control; the action is intentionally described as committing all dirty files.

Push and pull

• Push to origin publishes the current branch and sets its upstream when needed. Pushing alone does not open a pull request.
• Pull uses a fast-forward-only pull from the configured upstream. A dirty worktree blocks the operation.
• Remote fetch failures appear in the status instead of being treated as a clean sync.

Open a pull request

Pull request controls support GitHub.com remotes. The current branch must be a feature branch rather than the default branch.

1. Review or edit the title and body.

   Motriz can suggest them and can use a local PR template when the body is blank.

2. Choose Open PR.

   Motriz pushes the current branch, then creates a ready-for-review GitHub pull request.

3. Inspect status.

   The PR surface shows checks, reviews, and conversation status where GitHub returns them.

Merge and clean up

Choose the merge method, confirm the action, and let Motriz verify the PR head before merging. After a successful merge, the cleanup flow can check out the default branch, pull the latest changes, and delete the feature branch.

A dirty worktree blocks checkout, pull, and cleanup. Commit or deliberately discard those changes outside Motriz before retrying.

Recover failed tasks

Open the linked thread to see the exact run error and partial changes. Correct configuration or repository state, then retry the task. If parallel work completed but requires integration, integrate its branch before retrying downstream work.