A task is a branch in its own worktree with an agent living in it. That is also everything a pull request needs, so Termic lets you open one from the task and then watch it without leaving the window. When a reviewer comments, the comment goes to the agent that already has the code checked out.
GitHub and GitLab are both supported. Termic never talks to either API itself: it shells out to the CLI you already have signed in, gh or glab, which is also why self-hosted GitHub Enterprise and self-managed GitLab work with no extra configuration.
What you need
ghfor GitHub, orglabfor GitLab, installed and authenticated (gh auth login/glab auth login).- The task’s repository has a remote pointing at a host that CLI is signed in to.
Termic detects which provider a repository belongs to from its remote URL, so a project on github.com, one on a company GitHub Enterprise host and one on a self-hosted GitLab can sit side by side in the same sidebar. If the matching CLI is missing or signed out, the panel says so instead of failing quietly.
On GitLab, every label below reads merge request rather than pull request. The behaviour is the same.
Opening one
From a task with commits on its branch, open the PR card in the right panel and choose Create pull request, or run it from the command palette with ⌘K.
The form is short on purpose:
- Title, prefilled from the branch’s last commit subject. One commit per worktree branch is the common case, and that subject is usually already the right title.
- Description, optional.
- Base branch, prefilled from the task’s own base branch.
- Draft, a checkbox.
There is a second button: Ask the task’s agent to write the description and create it. It types a prompt into the task’s running agent tab telling it to read everything the branch changes (git diff from the merge base, plus untracked files), then run gh pr create or glab mr create itself with a concise title and a reviewer-friendly description of what changed, why, and how to verify it. The agent already has the diff in context, so it usually writes a better description than you would from memory. It needs a live agent tab in the task; if there is not one, the dialog says so and you use the plain Create button instead.
Watching it
Once a PR exists, the card in the right panel tracks it and reports:
| State | Meaning |
|---|---|
| Draft | Opened as a draft |
| Review required | No review submitted yet |
| Changes requested | A reviewer asked for changes |
| Approved | Approved by a reviewer |
| Checks running | CI is still going |
| Checks passing | Every check green |
| Checks failing | At least one check red |
| Merged / Closed | Terminal states |
The card refreshes on its own while you have the task open, and the header has a refresh button for when you want it now.
Comments go to the agent, not to you
This is the part that makes the loop short. When a reviewer leaves a comment, Termic can hand it to the agent working in that task’s worktree, so the fix happens in the branch the comment is about, by the thing that wrote it.
Two design decisions are worth knowing:
Comment bodies are not inlined into the prompt. The agent is told a comment exists and to fetch it itself with its own tooling. Pasting review text straight into a prompt is how you get an agent following instructions from a comment thread it should have been reading as data. Making it go and fetch keeps that boundary visible.
Only commenters with standing are acted on, by default. On most repositories anyone who can see a pull request can comment on it, regardless of whether they can push. A comment that reaches an agent reaches something with real shell access in your checkout, so Act on comments from defaults to Collaborators only: the comment author must be an owner, member or collaborator. Everyone is available per project if you want it, and you should decide that deliberately.
Both live in Settings → Repositories → your project → Git, along with Watch PR comments to turn the watching off entirely.
Starting a task from an issue
The other direction: an issue becomes a task.
The command palette (⌘K) has its own row, New task from an issue…. It is a separate row rather than a mode of “New task” because you are picking work before you name anything. Choose the project, then pick from its open issues in a picker that opens beside the form rather than inside it, so you can still see what you are filling in.
Picking an issue composes a first message from its title, body and the thread’s own URL, and drops it into the New Task dialog’s first-message box. Nothing is sent yet. You read it, edit it, and press Create like any other task. The task gets its own worktree and branch, and the agent’s first prompt is the issue.
When it merges
A merged PR usually means the task is finished, so When a pull request merges (per project, in the Git settings tab) offers three answers:
- Ask (toast), the default. A toast appears with an Archive button.
- Archive automatically. The task is archived for you.
- Do nothing.
Archiving removes the worktree and keeps the sessions, exactly as it does when you archive by hand. See Tasks & worktrees.
Per-project Git settings
Every project has its own Git tab under Settings → Repositories:
| Setting | What it does |
|---|---|
| Remote | Which remote the project’s PRs and base branches resolve against |
| Branch new tasks from | The base a new worktree is cut from |
| Watch PR comments | Whether comments are watched at all |
| Act on comments from | Collaborators only, or Everyone |
| When a pull request merges | Ask, archive automatically, or do nothing |
Related
- Tasks & worktrees: the branch and worktree a PR is opened from.
- Git: staging & commits: staging and committing before you open one.
- History & compare: reading everything the branch adds up to before you open a PR.
- Inline comments: commenting on code in the app and sending it to the agent.
- Sandbox overview: what an agent acting on a review comment can and cannot reach.