Ad-hoc runs — mention TaskGoblin directly

The direct asks: mention the goblin on a merge request, in Slack, on a Teams channel, or reply on an issue. These are never gated by a loop — and the ones you repeat are telling you which loop to build next.

# Ad-hoc runs

[Loops](/en/docs/loop-engineering) cover the work that should happen whether or not anyone asks. This page covers the other half: asking directly.

Ad-hoc runs are for the things that genuinely are one-offs, and for steering work already in flight — *"address the review comments"*, *"add a test for that edge case"*, *"what would it take to pull this apart?"*. Unlike loops, they are **never gated**. If a person asked, a goblin answers.

## Mention it on a merge request or pull request

Leave a comment mentioning the goblin on an existing MR or PR:

- On **GitLab**, `@taskgoblin` in a merge-request note.
- On **GitHub**, `@taskgoblin` in a pull-request or issue comment.

Use it to iterate: `@taskgoblin please address the review comments`, or `@taskgoblin add tests for the edge case in the last commit`. The goblin checks out the existing branch and pushes a follow-up commit to it — it does not open a competing branch.

## Reply to a review comment

When a review loop has left inline comments, reply `@taskgoblin fix` to any one of them. That scopes a run to exactly that finding: the goblin implements it, pushes the commit, and marks the comment resolved. You are not re-litigating the whole review, just accepting one of its suggestions.

## Ask in Slack or Microsoft Teams

Mention the goblin in a **Slack** thread or a **Microsoft Teams** channel, group chat, or direct message. It replies where the conversation is happening, so the answer lands in front of everyone already discussing it.

Chat is the right surface when a request starts as a discussion rather than a ticket — *"is this feasible?"*, *"why does this endpoint 500 for enterprise accounts?"*. The goblin reads the thread before answering, so you do not have to summarise what everyone just said.

## Follow up on an issue

On a **Linear** issue the goblin is already working, or a **Jira** issue where you mention it in a comment, just describe the change. The run resumes on the same branch with the full history of the work so far — no re-explaining, no fresh start.

## Run as many as you like at once

There is no queue. Every ad-hoc run gets its own thread, branch, and cloud sandbox, so nothing steps on anything else. Hand off five at once and five goblins work in parallel, each opening its own merge request.

## What every ad-hoc run has in common

- **The goblin arrives with context.** It reads the issue, the thread, the diff, and your organisation's conventions before it starts.
- **Work happens in an isolated cloud sandbox**, on a dedicated branch, never on your machine.
- **The result comes back where you asked** — a merge request, a review comment, or a reply in the thread.

## When an ad-hoc run wants to be a loop

Ad-hoc runs are the honest measure of what your team keeps needing. Watch for the ask you type more than twice:

- Mentioning the goblin on every pull request to review it → that is the **review event loop**, already installed.
- Asking on Friday for a summary of the week's merges → a **schedule loop**.
- Pasting the same context every time because it never remembers your conventions → that is not a loop, that is [organisation memory](/en/docs/the-brain); write it down once.

The goblins can create loops themselves mid-run, so *"do this every Monday from now on"* is a perfectly good thing to say out loud in a thread.

## Where to go next

- **[Event loops](/en/docs/event-loops)** — the unprompted half: reviews, assignments, labels.
- **[Schedule loops](/en/docs/schedule-loops)** — recurring work on a cadence.
- **[How a run works](/en/docs/how-the-agent-works)** — what happens between your mention and the merge request.

Loops cover the work that should happen whether or not anyone asks. This page covers the other half: asking directly.

Ad-hoc runs are for the things that genuinely are one-offs, and for steering work already in flight — "address the review comments", "add a test for that edge case", "what would it take to pull this apart?". Unlike loops, they are never gated. If a person asked, a goblin answers.

Mention it on a merge request or pull request

Leave a comment mentioning the goblin on an existing MR or PR:

On GitLab, @taskgoblin in a merge-request note.
On GitHub, @taskgoblin in a pull-request or issue comment.

Use it to iterate: @taskgoblin please address the review comments, or @taskgoblin add tests for the edge case in the last commit. The goblin checks out the existing branch and pushes a follow-up commit to it — it does not open a competing branch.

Reply to a review comment

When a review loop has left inline comments, reply @taskgoblin fix to any one of them. That scopes a run to exactly that finding: the goblin implements it, pushes the commit, and marks the comment resolved. You are not re-litigating the whole review, just accepting one of its suggestions.

Ask in Slack or Microsoft Teams

Mention the goblin in a Slack thread or a Microsoft Teams channel, group chat, or direct message. It replies where the conversation is happening, so the answer lands in front of everyone already discussing it.

Chat is the right surface when a request starts as a discussion rather than a ticket — "is this feasible?", "why does this endpoint 500 for enterprise accounts?". The goblin reads the thread before answering, so you do not have to summarise what everyone just said.

Follow up on an issue

On a Linear issue the goblin is already working, or a Jira issue where you mention it in a comment, just describe the change. The run resumes on the same branch with the full history of the work so far — no re-explaining, no fresh start.

Run as many as you like at once

What every ad-hoc run has in common

The goblin arrives with context. It reads the issue, the thread, the diff, and your organisation's conventions before it starts.
Work happens in an isolated cloud sandbox, on a dedicated branch, never on your machine.
The result comes back where you asked — a merge request, a review comment, or a reply in the thread.

When an ad-hoc run wants to be a loop

Ad-hoc runs are the honest measure of what your team keeps needing. Watch for the ask you type more than twice:

Mentioning the goblin on every pull request to review it → that is the review event loop, already installed.
Asking on Friday for a summary of the week's merges → a schedule loop.
Pasting the same context every time because it never remembers your conventions → that is not a loop, that is organisation memory; write it down once.

The goblins can create loops themselves mid-run, so "do this every Monday from now on" is a perfectly good thing to say out loud in a thread.

Where to go next

Event loops — the unprompted half: reviews, assignments, labels.
Schedule loops — recurring work on a cadence.
How a run works — what happens between your mention and the merge request.