Canonical-URL: https://www.starko.one/blog/ask-fix-prototype-starko-ai-handoff
Published: 2026-10-30
Author: Stefan Vukmanovic

# Ask, Fix or Prototype: Talking to Starko AI, and the Handoff

When you mention Starko AI on a ticket, you now pick what you want before you send: Ask, Fix or Prototype. Ask answers and can only propose a run. Fix makes your comment the brief for a run. Prototype publishes HTML mockups and writes no code. Whatever the mode, a finished run can report what a human still has to do, on the ticket, in Slack, in the ⌘L assistant and on the pull request.

These changes shipped between 26 and 30 October 2026.

## Why an eager agent is worse than a lazy one

An eager agent spends your run budget on a guess. Before these changes, "@Starko AI" in a ticket comment went through one prompt rule that decided between answering a question and starting a fix run, and the tool that hands off to a run sat in the agent's free toolset.

That is the wrong default. A run is the expensive part of the factory, the part we describe step by step in [how a Starko AI run works](/blog/from-support-ticket-to-pull-request-how-a-starko-ai-run-works). The person who typed the comment already knows whether they wanted an answer or a pull request.

So we made the choice structural instead of prompted. The person picks the mode, the tools follow the mode, and in Ask the model can propose a run but cannot start one. Nothing in the prompt has to be clever about it, because the tool is simply not there.

## Ask, Fix or Prototype: what each mode does

Ask answers, Fix builds, Prototype publishes mockups. Three pills appear on the comment composer while your draft mentions Starko AI. Your last choice is remembered per browser, and the default is Ask. One exception: a bare mention stays Fix, because the "Fix with Starko AI" action inserts exactly that.

| Mode | What Starko AI does | What comes back |
| --- | --- | --- |
| Ask | Answers. No tool in this mode can start a run. | A reply and, when code work is wanted, a Start Starko AI run or Prototype the UI button. |
| Fix | Takes the comment as the brief. No assistant turn. | A steer to the running session, a continuation of the last run, or a fresh run. |
| Prototype | Reads the app and publishes one HTML page per direction. Writes no code. | Live mockup pages on the ticket, image stills in Slack, and a question naming the variants. |

### Ask: an answer, and at most a proposal

Ask has no tool that starts a run. It answers, and when the answer is "this needs code", it calls a proposal tool instead. The reply then carries a button, Start Starko AI run or Prototype the UI, and clicking it sends the brief verbatim to a run.

One exception is deliberate. If a run is parked waiting for information, Ask can resume it instantly with your answer. That tool exists only while the run is parked.

### Fix: the comment is the brief

Fix skips the assistant turn entirely. Your comment becomes the brief and rides the kickoff as its own fenced block. Where it goes depends on the ticket's state. If a session is already running, the comment reaches it as a steer, and a follow-up never starts a second run. If the last run has finished, it continues on the same branch and pull request. Otherwise a fresh run starts. When the agent refuses the brief, the refusal lands as a Starko comment on the ticket.

### Prototype: pages, not code

Prototype uses the same dispatch as Fix, with the brief tagged as a prototype. That tag swaps the usual pull request and evidence contract for a prototype contract: read the app, publish one page per direction, write no code, and end by asking which variant to build. The mockups are live HTML pages linked from the ticket. Each page keeps a PNG still beside it, served behind a 30-day signed link, which is how the directions reach Slack as images. Prototype is allowed on continuations too.

## What Starko AI hands back: "What you need to do"

A finished run can now report up to three steps that only a human can take. Before this, the ticket comment listed what the agent did, its concerns and deviations, while the Slack card had the reviewer's one-liner and "Reply merge it". Neither said what the person had to do next. The agent buried that in prose, with lines like "Still open: the publication hasn't been applied".

The handoff contract now has a repeatable next-step line, capped at three. The prompt rules are strict: imperative, specific, and only things a human must do, such as running a migration, setting an environment variable or reconnecting an integration. "Review" and "merge" are never allowed as steps, because a pull request already asks for those.

The same list appears everywhere a run reports:

- On the ticket comment, as a numbered "What you need to do" list above concerns and deviations.
- On the Slack pull request card, which now carries what it did, what you need to do and the concerns the agent flagged, then the "Reply merge it" footer. If the run reported nothing, the card stays short.
- In the ⌘L pull request notice and the run panel.
- In the pull request body, where the evidence section opens with "Before this ships, a human must:".

A continuation sees the previous run's next steps, and so does the reviewer agent, so an open step does not quietly vanish between runs. Runs that finished before this change keep their old handoff shape; only new runs produce the line.

## What Starko posts in Slack when a ticket is created

A ticket created in a project bound to a Slack channel now posts a notice in that channel, at most once per ticket. The headline names the type: "A new bug has been reported" or "A new question has been asked". The type comes from intake classification first, then from the kind tag. If neither exists, the notice says "A new ticket has been reported". The message links the title and shows the reference, the project and the priority.

Two rules protect ticket creation. Nothing is sent without a connection, so a project with no channel, a ticket with no project or a workspace that removed its Slack install stays quiet. And a Slack failure never blocks the ticket: the notice runs after classification in a fire-and-forget workflow and never throws. The price of that order is a short delay in repository-linked projects, usually a few seconds, so the headline can say "bug" instead of "ticket". A once-per-ticket marker is claimed before every post, so a retried or duplicated workflow cannot announce twice.

### A plain reply reaches the foreman

The foreman now follows the notice thread. A plain reply under it, with no mention, reaches Starko. "Fix this" proposes a Starko AI run on that ticket through an approval card. "What is this" reads the ticket and answers. "Assign to Ana" or "not now" proposes a ticket update. Notices posted before this change keep their unfollowed threads, so mention Starko there.

### Cards you can read in the thread pane

The approval card and the run card used to read like a form dump in Slack's thread pane: label, value, label, value. We rewrote them. The approval headline is one plain sentence, and the details below it are one block with a label and value per line. The profile reads "Feature · Small". The run card shows Reproduction, Fix and Review on one line.

Activity lines changed the most. They used to echo the raw sandbox shell, down to the working directory change. Now they say "read file", "searched file for X", "listed dir" or "ran git status". The one-liners in ⌘L follow the same rule: "on this ticket", the repository's short name, no raw ids.

At merge time, the Ask, Fix and Prototype work had its unit tests green, but the browser and Slack end-to-end paths were still to be exercised on preview. The new-ticket notice was tested against a stubbed Slack call, not a real workspace.

![The foreman in Slack: a run started from a thread, next to the project timeline](/blog/foreman.png)

## How this fits the factory

The mode picker and the handoff list both move judgement to the person and work to the agent. You decide whether a comment is a question, a brief or a request for mockups. The agent reports what it could not do itself. The bill stays where it was: [you pay per merged pull request](/blog/why-starko-bills-per-merged-pull-request), which is why an Ask that only proposes a run matters.

If your team works in Slack, the [Slack channel page](/channels/slack) covers the foreman setup. The changelog entries on [Starko in Slack](/changelog/starko-in-slack-foreman-assistant), [replying @starko on a ticket](/changelog/starko-mention-continuation) and [Starko AI inside the ticket conversation](/changelog/starko-ai-comment-identity) show how the earlier pieces arrived.

## Frequently Asked Questions

### Does Ask ever start a run by itself?

No. In Ask mode the comment agent has no tool that can start a run. When code work is wanted it proposes one, and the reply carries a Start Starko AI run or Prototype the UI button. The run starts only when a person clicks.

### What happens if I pick Fix while a run is already working?

The comment reaches the running session as a steer, and a follow-up never starts a second run. If the last run has already finished, Fix continues it on the same branch and pull request. If there is nothing to continue, a fresh run starts.

### What goes into "What you need to do", and what is left out?

Up to three imperative steps that only a human can take: run a migration, set an environment variable, reconnect an integration. Reviewing and merging are never listed, because the pull request already asks for those.

### Why does the new-ticket notice sometimes arrive a few seconds late?

In a repository-linked project the notice waits for intake classification so the headline can say "bug" or "feature request" instead of "ticket". In a project without a repository it goes out right away. If classification fails, the notice still goes out, and it is posted at most once per ticket.