The Lead (Beta)

The Lead is your own chat for the whole workspace. Ask it what needs you or how a pull request is doing, and it answers across every project. Ask it to add work to the Backlog, start it or message a session, and it does that as you. When a session needs you, a card lands in the chat. Open it from Lead in the sidebar. It is in Beta.

Ask across projects

The Lead answers from what the workspace holds right now. That covers sessions, their pull requests and checks, what needs you, and recent Activity. It can also read a project's code to answer a question about it.

Every session it names comes back as a chip, the same one a session shows when its agent files work to the Backlog. It shows the session's status and title. On a session that is active or under review, Message this session points the composer at it, as on a card in the panel. Click a chip's title to open the session over the Lead. Its dialog leads on to the chat. When it names several in a row, Copy all links copies them all. On an empty chat, try one of the starters it offers, such as "What needs me?" or "Triage the open pull requests".

The panel on the right has two tabs. Sessions opens on your own sessions in the workspace, in five groups. Each group shows its count, and a group with nothing in it is not shown.

Group	What it holds
Needs you	Cards waiting on you, in the order the Lead ranked them, then your sessions that wait on you with no card
Shipping now	Sessions an agent is working in, and ready pull requests that still wait for an approval
Ready to merge	Approved pull requests that passed their checks and QA, and pull requests in line in the Merge Queue. A new message, a Ship, or a sync into the session moves it back to Shipping now and closes its Approve and Merge cards
Merged today	Pull requests merged today. Shown only when the Completed status filter is on
Backlog	Tickets not started yet. It shows five, then Show N more

Widen the Assignee filter to see everyone's. The status filter starts on Backlog, Active and Under Review. Turn on Completed to see Merged today. Search and the filters apply to every group. Click a card to open its session.

Artifacts lists the prototypes the Lead drew for you. See Prototypes.

Mention a session or an artifact

Type @ in the composer to name the exact session or artifact you mean. The menu lists the workspace's most recent chat sessions, then its most recent artifacts, including the ones a cron run wrote. Keep typing to filter by title across every project. Arrows move, Enter or Tab picks, Escape closes.

The pick becomes @Title on a filled background. Backspace next to it removes the whole mention, and editing inside it turns it back into plain text. Once sent, the mention links to the session, or to the artifact open in its session or cron run.

The Lead gets a reference to each mention, not its content, and reads the item itself before it answers. Archived sessions and their artifacts are not offered. A mention whose session or artifact is later archived or deleted stays in the message, struck through, and says why when you hover it.

Ask it to act

The Lead has no modes. Every message is just talking to it. It acts on sessions only when you ask for exactly that. It files, starts and sends messages and skills into sessions, changes a session's status, and queues your own approved pull request to merge. Ask it to run /kosuke:sync-branch in a session, and it sends that skill there.

It does not read back credits or sandboxes, and it does not wait for a typed yes. Asking is the yes. When a request could mean more than one thing, it says what it would do and waits for your answer.

Whatever it does, it does as you. Sessions it files, starts or sends to record you as the one acting, and Activity shows those actions as yours.

The Lead never edits a repository itself. To change code, it starts a session.

On its own, the Lead follows what happens to your sessions and decides what needs you. It writes your cards, orders them, decides which ones are worth a notification, and closes the ones that no longer need you. It also takes the steps nobody has to tap for: it sends a review that asks for changes into its session, and asks your reviewers again after the session addressed it. It proposes one Backlog ticket to start when you are idle. It never merges unless you ask, and it does not groom the Backlog. See Decide one card at a time. For scheduled work, such as backlog triage, use a cron. A cron can send proposals to your Lead. See Proposals from a cron.

Prototypes

Ask the Lead to show you a change before it becomes a ticket, for example "Group the Sessions list by status. Show me two ways first." It draws a prototype, a page that runs in the browser, and its reply carries a card such as "Prototype · 2 variants · version 1". Press Open on the card.

The prototype opens in the Artifacts tab on the right:

• Each variant is a tab, such as A · Status sections and B · Pinned Needs you. Scripts in the page run, so tabs and buttons inside it work.
• Choose puts "Go with variant B" in the composer and sends nothing. Add what else you want changed, then send.
• Ask the Lead for changes and it publishes the next version. A card always opens the current one. Earlier versions stay under the version menu, such as v2.
• The expand button at the top of the panel opens the prototype full screen, with the variants side by side or one at a time, and a Choose on each.

The Artifacts tab opens on Not filed, the prototypes you have not put on a ticket yet. Its badge counts those. Prototypes on a ticket fold under On a ticket, and ones left for 30 days fold under Older than 30 days. Search covers all of them.

To put a prototype on a ticket, ask the Lead to write the ticket, or press Attach to ticket… and pick a Backlog ticket. The ticket gets its own copy as an artifact: the variant you chose, or every variant. Its build agent reads that copy when the session starts.

A prototype runs in an isolated frame. It cannot read your Kosuke login or call Kosuke. Nobody else can see your prototypes until you put one on a ticket, and then they see the ticket's copy.

Add work and ship it

Write "add a crons page to the backlog" and the Lead files your text as a Backlog ticket, exactly as written. The ticket is assigned to you unless you name someone else or ask for it to be left unassigned. It reads no code for this and starts no sandbox.

To start a ticket, hover its card in Backlog, press Ship and pick Full or Only QA, or tell the Lead "start it". The session starts with /kosuke:ship as its first message. Only QA sends /kosuke:ship --no-review, which skips the review. The tap is the yes.

/kosuke:ship is a skill that runs inside the session and carries the ticket to a pull request that is ready to merge:

1. It grounds the ticket. It reads the code, asks you what it needs to know, and writes the spec with acceptance criteria. On a complex ticket, another model attacks the spec and it writes a phased plan.
2. It runs /kosuke:prototype when the ticket changes a screen.
3. It builds the change and opens a draft pull request.
4. It runs /kosuke:adversarial-review when the diff needs one, or marks the pull request review: skipped with its reason, and /kosuke:automated-qa. It decides about the review again, and runs QA again, whenever a fix changes the code.
5. It waits for the checks.
6. It marks the pull request ready.

Along the way it fixes what the review, the checks and QA find, and runs them again. It keeps going while QA runs make progress. It stops with a failure when the checks or QA still fail after a fix and a fresh run, or after one QA run when nothing in the branch can fix what fails. /kosuke:ship stops only when it needs a person, and each stop has a reason.

Stop reason	Why it stopped	What the Lead usually puts in front of you
prototype	A prototype waits for your approval	The prototype, with Approve and Change something
question	It needs a decision from you	The question, to answer in place
failure	The checks, QA or a sync still fail after a fix, or nothing in the branch can fix them	What failed, with the QA report and Send back to fix
ready	Checks are green, QA passed, and the review passed or was skipped	Who to ask for a review, with Ask

/kosuke:ship saves its stage. Sending /kosuke:ship into the session again resumes from that stage. Your answer on a card does that for you.

Decide one card at a time

Every session sends the Lead what happens to it, whether it runs /kosuke:ship or not: a turn that ended, and how; a question its agent asked; a pull request opened; checks that went red or green; a review; a branch that fell behind; labels that changed; three days with no activity; a step of the Merge Queue. The Lead reads these and decides what needs you. When something does, it puts one card in Needs you and in the chat. It writes the card's title, a short line about it, and the one-line reason under it, and it picks the buttons.

Cards post one at a time. Decide one and the next one posts. A card can show:

• A thumbnail of a prototype or a QA report. It opens the artifact at full size.
• A short QA report, one line per section.
• The question a session asked, with its options. On the Sessions tab, keys 1 to 3 answer while the composer is empty.
• The teammates to ask for a review.

Its buttons come from a fixed list. Each one does the same thing on every card:

Button	What it does
A message button, such as Approve, Ship or Send back to fix	Sends its words into the session as you, through the Lead. See Message a session
Change something or Reply	Puts the session's To #N chip in the composer, for your own words
Ask	Requests a review on GitHub, as you, from the teammates on the card
Approve on a pull request	Approves it on GitHub, as you
Merge	Adds your own approved pull request to the Merge Queue
Accept, Start, Delete, Merge or Create on a proposal	Runs the proposal, as you. See Proposals from a cron
Open	Opens the session

Kosuke checks each button when you press it, whatever card offered it. Merge works only on your own pull request, once it is approved. Ask asks only teammates who connected GitHub, never the author. A message goes only into a session that is active or under review. When a check refuses, the card shows the reason and stays.

When the Lead changes a card while it is in front of you, a press on the old one is refused with "This card changed", and the new card takes its place.

Every card has Skip, for "not now". The next card posts at once. The skipped card stays in Needs you at the end of the line and comes back in the chat after the others. You get no notification about it again.

Every card also has Cancel, which removes the card for good. One receipt line takes its place in the chat and the next card posts. Cancel changes nothing in the session: it keeps its branch and its pull request. Something new on the session can bring a new card.

When nobody has written a card yet, a session that waits on you still shows in Needs you, as a plain row with one line of reason and Open. The reasons are the ones the home page uses: checks failed, the last turn failed, the agent asked you something, or /kosuke:ship stopped for you. The pull request may also be approved with green checks and ready to merge, wait on your approval, or have had no activity for three days. On a session /kosuke:ship does not run, the branch of an open pull request may be behind. A session that is still shipping or syncing shows under Shipping now or Ready to merge instead, unless it stopped for you: a turn runs or waits to start, the Merge Queue holds it, or /kosuke:ship is between turns.

The triager and notifications

Your Lead is the triager. Kosuke wakes it when something happens to one of your sessions, when you come back after 30 minutes away, and when your last building session stops with nothing waiting on you. Kosuke keeps what happened until the Lead has read it, so a Lead turn that fails gets it again on the next one.

The Lead keeps working when you are away. It answers what happened with cards, notifications, and the steps nobody taps for. It writes nothing into the chat about them, so the chat shows cards and one-line receipts.

It decides some steps on its own:

• A review that asks for changes, from someone you asked or who can write to the repository, goes into the session, and the session addresses it. A review from anyone else reaches the Lead without its text and goes nowhere.
• Review threads left open on a ready pull request go into the session.
• A Merge Queue conflict sends /kosuke:sync-branch into the session.
• Checks that went red after the Merge Queue updated the branch go into the session.
• After the session addressed a review and is ready again, the Lead asks the same reviewers again.

These messages reach the session from Kosuke, not from you. The Lead writes them in its own words from what happened. Kosuke lets it send into one session once per turn, only into your own sessions, and only about something it was just told about that session. It never merges on its own.

Text inside what reaches the Lead, such as a review comment, a ticket title or a pull request body, is data to it. It never follows instructions written there. Kosuke checks each command it runs while it handles events, and runs only a single plain command from a short list of exact ones.

It ranks your open cards and decides whether a card is worth a notification:

Situation	What happens
You were active in the last 30 minutes	The card posts. No notification
An earlier notification is still unopened	The card posts. No new notification
You are away and someone is blocked	One notification
You are away and nobody is blocked	The card waits until you are back
It looks like your night	The card waits until you are back
The Lead is on your screen	The card posts. No notification of any kind reaches you, on any device

A card notifies you at most once. Each card shows the Lead's one-line reason under it, such as "Not notified. You have not opened the 17:41 one yet." When you come back to waiting cards, the chat shows one "Welcome back" line, then the first card.

A message you send while the Lead handles events waits in Up next and starts its own turn when the events are done. Steer it in instead, and the Lead answers you first, then finishes the events.

The triager runs on Claude models only. With a Codex model picked for your Lead, the Lead writes no cards, sends nothing on its own, sends no notification and makes no proposal. Needs you still lists the sessions that wait on you, as plain rows. Your own messages to the Lead work the same on both. Only Claude lets Kosuke check each command the Lead runs while it handles events, and text that reaches it must never get the Lead to act for someone else. Pick a Claude model to turn the triager back on. What happened in the meantime is not replayed.

Proposals from a cron

A cron can send you a proposal, for something it found and may not do itself. The card lands in Needs you and in the chat like any other, with one line of why, Skip, Cancel and one action.

Card	What accepting does
Delete this ticket?	Deletes a Backlog ticket whose work already shipped. The card names the pull request or session that did it
Merge these tickets?	Folds several Backlog tickets into the one the card shows, and deletes the others
Create this Cron?	Creates the cron the card names
Start this?	Starts a Backlog ticket with /kosuke:ship

The line above the card says who proposes it, such as "The backlog-triage cron proposes". On the Sessions tab, these cards read Delete?, Merge tickets? and Create cron?, and carry the cron's name on their meta row. A start card reads Start? on the Sessions tab and Start this? in the chat, and carries the cron's name in both. The one-line why is the cron's own.

Nothing happens until you accept. The action then runs as you, with your own permissions, and leaves one receipt line in the chat, such as "You deleted Add CSV export". Skip leaves everything as it is. A cron never deletes a ticket, merges tickets or creates a cron itself.

The cron chooses one member for each proposal. So a teammate's Lead may hold a card yours does not. A proposal to merge tickets is withdrawn when one of them was edited after the cron read it.

Message a session

Everything you send to a session from the Lead goes through the Lead. Hover a card in the panel and press the Message icon, or press M on a focused card. A To #1629 chip appears in the composer, with the pull request number or a short title. Write your message and send. Press x on the chip or Esc to go back to a plain Lead message.

The Lead reads the session before it sends: its status, what its agent last said and what anyone wrote to it since. Then it sends your message into that session, as you, with your words unchanged. Sending is the yes: the Lead does not ask you to confirm.

When your message leans on something the session has not seen, such as what you discussed with the Lead, the Lead adds that context below your words. The added part opens with "Context from the Lead:". The Lead's answer says what it read and quotes what it added.

The Lead does not send a message that would misfire. This happens when the session already got that answer, when the session is Completed or Archived, or when your text is a question for the Lead. Its answer then opens with "I did not send", gives the reason and asks what you want. Nothing reaches the session.

A session Under Review is not one of these cases. The Lead sends, and your message resumes the session, as when you write in it yourself: its pull request goes back to draft, and the Lead's answer says the session left review. If Kosuke refuses the send, the Lead tells you what Kosuke answered.

A card's message buttons, such as Ship, Approve on a prototype or Send back to fix, and an answer to a question work the same way. Each one is a targeted Lead message. The Lead reads the session, then relays it. A button that resumes /kosuke:ship adds it after the words, so the session picks up where it stopped. If the Lead does not send a card's message, the card returns to Needs you.

Approve and merge

A session is Ready when /kosuke:ship stops with ready. Its checks are green, and the qa: passed label and a review verdict sit on the latest commit: review: passed, or review: skipped when the agent judged the change needed no review. A skip never stands in for a review that failed.

The Lead usually puts every teammate on the card: each member of the workspace who has connected GitHub, except you. GitHub takes at most 15 reviewers on one pull request, so in a larger workspace the Lead picks the 15 who review that area most. This works the same for a session that never ran /kosuke:ship, once its pull request is ready. You merge your own pull request.

1. On your ready pull request, press Ask on the card, or Ask Nicola to approve in the panel, which names the first teammate. Kosuke requests the review from all of them on GitHub. In the panel, the arrow beside the button asks one teammate instead.
2. Each teammate's own Lead hears that you asked them, and usually gives them an Approve card. When a review asks for changes, your Lead sends it into the session.
3. Once the pull request is approved, your Lead can give you a Merge card. Nobody else can merge it from a card.
4. Merge adds the pull request to the Merge Queue.

Ask, Approve and Merge act on GitHub as you. They post nothing into a session. When GitHub refuses, the card shows GitHub's reason and stays. When GitHub refuses only some of the teammates you asked, the others are asked, and the receipt names who could not be and why.

You can also ask the Lead to merge, in so many words: "merge the pull request of the CSV export". It queues the pull request as you, exactly as your Merge press does, and says so. It does this only when you ask. A question such as "is #1772 ready to merge?" gets an answer and queues nothing. When the pull request is not approved yet, or it is a teammate's, the Lead says why and queues nothing. It also queues nothing when your message reached it while it was handling platform events: it asks you to send the request again in a new message.

The Merge Queue merges one pull request at a time per project:

• Before it merges a pull request, it updates the branch when the base has commits it lacks, and waits for its checks. It updates one branch at a time.
• A conflict keeps the pull request's place in the line and tells your Lead, which sends /kosuke:sync-branch into the session. Checks and QA run again. If the sync changed only merge lines, the pull request keeps its place. If it changed code, it leaves the line, and your Lead decides what comes next, such as asking the same reviewers again.
• Red checks after an update, a review that asks for changes, an open thread, an approval that no longer counts, or a refusal from GitHub takes the pull request out of the line. Your Lead hears why.
• Before every merge it reads the pull request's mergeable state from GitHub.

Run a skill in the Lead

Type / in the composer. The menu lists the skills a chat session of yours carries: the workspace's enabled Custom Skills, and your own Personal Skills over any of the same name. Pick one, add what it needs after its name, and send.

Picking a skill places its invocation before your draft and keeps the text you already wrote.

The skills Kosuke ships are not in the Lead's menu, because each one needs a session's branch, pull request or Preview. To run one, such as /kosuke:open-pr, ask the Lead to send it into a session. Your workspace's own skills and your Personal Skills always show, even one that needs a branch, because Kosuke cannot tell what they need.

• The Lead has no repository of its own and cannot edit repository files. A skill that writes code works only in a chat session.
• Your Personal Skills reach your own Lead only. Nobody else's Lead can read them.
• A skill turned on or off in settings reaches the Lead at its next answer.

The Lead loads no plugins. Plugins run in chat sessions only.

Pick a model

Pick the model in the composer's model picker. It offers the Claude and Codex models you can run, and starts on your last pick or your Default Model. GLM and Kimi models cannot run the Lead. A Codex model answers your messages, but the Lead then stops working on its own. See The triager and notifications.

The picker leaves out the Ultracode and Ultra efforts. If your last pick or Default Model uses one, the Lead runs at the highest effort below it that the model offers. Switching to another provider hands the conversation over, and the transcript marks where.

The Lead needs a Claude or Codex Subscription of yours, or the workspace's Anthropic or OpenAI Credentials. With neither, the page reads "The Lead runs on your Claude or Codex Subscription, or on the workspace's credentials. Connect one to ask it anything." and you cannot send. Connect a Subscription, or ask an admin to add Credentials. See AI providers.

Send while it works

A message you send while the Lead works waits in Up next, the list above the composer, and starts the next turn. Up next works as in a chat session: you can edit, move or delete a message in it, or send it now. See Messages, Up next and steering.

To have the Lead take a message into the answer it is writing, steer it. Press ⌘Enter (Ctrl+Enter on Windows and Linux) as you send, or press Steer now on its row in Up next. Steering works with Claude and Codex models. If the turn ends before it takes your message, the message goes back to the top of Up next.

A card button that sends a message, such as an answer to a question, Approve on a prototype, Send back to fix or Ship, waits in Up next the same way. Delete it there and its card comes back. Accepting a proposal, Start, and Ask, Approve and Merge on a pull request act at once.

Pressing Stop pauses Up next. Send a new message to carry on: it goes out at once, and Up next follows its turn.

You can attach images to a message, and PDFs too with a Claude model. The Lead reads no other file types.

Clear or compact the conversation

Type / in the composer, with any model, to open the menu. It offers the commands marked Runtime, /clear and /compact, with either model. Pick one, or send it as the whole message. With a Codex model, $clear and $compact work too.

• /clear starts a fresh conversation. The Lead's next answer knows nothing said before it. Every earlier message stays on screen above a "New conversation from here" line.
• /compact summarizes the conversation so far to free up context. Add a focus after it, such as /compact focus on the backlog tickets. It takes about a minute, and the composer waits until it is done. The transcript then reads "Conversation compacted" with the token counts before and after, and the ring by the composer drops. With a Codex model, the focus stays in the conversation's history as a note, which Codex may not follow. With nothing to summarize yet, it says "Nothing to compact yet".

Neither command runs while the Lead is answering. Wait for the answer to end, or stop it first.

Kosuke also compacts the conversation on its own. It does so at the next idle moment once the conversation passes 60% of the Lead's context, and at least every 4 hours of activity. Nothing is lost that matters to your queue. What waits on you lives in Kosuke, not in the conversation: cards, their order, skips and notification history are read fresh on every turn.

Who can see it

Each member has one Lead per workspace. Nobody else can read yours or its prototypes, in the app or through the API, workspace admins included. It covers only the workspace it belongs to. Leaving the workspace deletes it.

What it costs

The Lead runs on your own Claude or Codex Subscription when you have connected one. Without one, it runs on the workspace's Credentials. When yours needs reconnecting, it runs on the workspace's Credentials and the transcript says so. Sessions it starts run like sessions you start yourself.

The Lead's sandbox time shows in Settings > Workspace > Usage as Orchestrator, together with Slack requests. After a quiet spell, the first answer takes longer to start, and the transcript reads "Waking the workspace sandbox" while you wait.

To script the same work from your own terminal or agent, use the Kosuke CLI.

Next steps

• Chat sessions and the board
• Crons
• AI providers