Sensei

Sensei is your own chat across every workspace you belong to. It has no workspace of its own. You have one Sensei, not one per 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 task, and it does that as you. Every message you send from New thread starts a thread of its own, so Sensei works on several at once. When something needs you, Sensei draws a card for it in that thread, with the buttons to decide it. Open Sensei from Sensei at the top of the sidebar.

After you sign up or sign in, the app opens Sensei. So do / and any address the app does not know.

Your first run

When you finish onboarding, Sensei opens a thread named Welcome to Sensei. It holds a greeting, a box that says what a thread is, and your first card, What do you want to do first? The card says it is your first card. Pick one, then press Answer:

• Work on my code asks you to connect GitHub, then shows a Repository card that names your workspace and lists the repositories Sensei can write to. Import one, and Sensei asks for your first change with suggestion pills. Send one, and a task starts: the first time, a box says what a task is, with its steps Plan, Build, Test and Ready. When the task is ready, a Merge card asks for your first real decision. After the merge, Sensei suggests what to try next.
• Build a new app shows a Describe card. Write what the app does, and it is created as a YOLO project in your workspace, with a link to its chat. Sensei does not follow that chat, and it has no Merge card.
• Help with my day asks you to connect Gmail and Google Calendar. Connect one or both, and Sensei answers from them.
• Show me around first shows what a thread, a task and a card are, then the first card again.

The first time a new topic starts a thread of its own, Sensei's first message there says why. A reply you type in a thread stays in that thread.

If Sensei free cannot run your turns and you have no Subscription, the Welcome thread first asks you to connect Claude Code, Codex or Gemini, with no Not now. The first card waits until one is connected.

A member with a Welcome thread never sees Get started below. Members who finished onboarding before the Welcome thread existed keep it.

Connect from Sensei's message

When a request needs a connection you have not made, Sensei's message carries a Connect button for each one, with its logo and name, and Not now. Sensei uses this block whenever it needs a missing connection, not only in your first run: GitHub for code work, a Personal integration such as Gmail, Google Calendar, Slack, Linear, Jira, Figma, Notion, 1Password, Xero, QuickBooks, Zoho CRM, Zoho Books, Zoho Invoice, Mercury or FreshBooks, or a Subscription.

Press Connect and the provider's own sign-in opens in a pop-up. In the desktop app, an integration opens in your default browser instead, where consent and any tenant choice finish. One sign-in runs at a time. When it finishes, the server checks what the sign-in saved, and the button becomes a check with the account name. Sensei then carries on in the same thread. Not now lets Sensei carry on without it. A block that nothing can go on without has no Not now.

Higgsfield, Typefully and Cloudflare connect in Settings > You > Integrations. For a workspace integration such as Sentry, PostHog, Search Console, an ad platform, E2B or Sensei admin data, Sensei points to Settings > Workspace > Integrations. Choose Personal there for your own work; only you manage those connections.

With no workspace named, Sensei uses your personal integrations and the Personal space's workspace integrations. Naming a workspace reaches that workspace's integrations plus your personal ones, never the Personal space's. A restricted integration needs a grant for the workspace the call runs in, including Personal; a Superadmin can grant a Personal space in the admin panel.

A Connect item checks only the connection its own attempt made. Abandoning Add, or adding an account that is already connected, leaves it unchecked. A duplicate shows why it was refused.

Get started

A Get started card sits above Sensei's composer until you dismiss it. It shows how many of its three steps are done, such as "1 of 3", with a bar that fills as you go.

Step	Its line	Its button	Done when
Connect your subscription	Use your Subscriptions for Sensei, or Sensei free while you hold none. Workspace Deploys use workspace Credentials.	Connect opens Settings > You > AI Providers	A Subscription of yours is connected
Import a repository	"Sensei deploys it for you. You do not have to wait."	Import opens the Import Project dialog for the workspace from your sign-up	A project exists in any workspace you belong to
Start the first task	"Tell Sensei what to ship in storefront."	Start puts "Ship this ticket in storefront: " in the composer	You started or filed a task

A step waits on the ones before it. Until you connect a subscription, Import reads "After you connect a subscription." Start waits on both earlier steps. Start sends nothing. Finish the sentence with what you want shipped, then send it.

When all three are done, the card shrinks to one line, "You are set up. Sensei takes it from here." It stays until you press its X or leave the page, and then Get started is gone for good. Press the X to dismiss it at any step. Get started is yours, not a workspace's. Once it is done or dismissed, it never comes back, even when you join or create another workspace.

Use the personal model picker for your Subscriptions, or Auto - Sensei free while you hold none. Connecting the first Subscription moves Free threads to Auto over Subscriptions from their next turn. Importing a workspace repository needs workspace Credentials for its first Deploy.

Threads

Every message you send from the New thread composer starts a thread, one topic with its own replies. The composer closes when you send, and a banner links to the new thread. To continue a thread, reply in it: a reply stays in its thread. Thread mode in the desktop app's Spotlight starts a new thread too.

Threads run at the same time. Send two messages within a few seconds, and both read "Working". Neither waits for the other.

The app also opens a thread for anything that needs you and has none yet. That covers a session, a project's Deploys, a Cron and a message from a cron or an agent. A project has one thread for its Deploys, "Deploys of" and the project. A Cron has one thread, reused on every failed run. Each message has its own thread, and so does each project's QA guide. A review request on a teammate's pull request goes in a thread for that session. Sensei does not open these threads and does not answer in them unless you write there. It reads the events written in them in an Event Turn, and draws cards.

A thread has one of three states. A member Turn or Up next message makes it Working, unless every member row came from a card button and a card is open; otherwise an open card takes priority:

State	Meaning
Needs you	An open card
Working	A member Turn is pending or running, a message waits Up next, or your own session is Active or Under Review
Done	Everything else

Sensei answers at most ten of your threads at once, counting the threads where it reads new events. An eleventh stays Working with a spinner while it waits, and starts when one of the ten ends, oldest first.

An open thread shows, from the top, a back button, its title and its state, then one chip for each session it holds. Press the arrow on a chip to open the session's page, or click its title. Below are your first message, "N replies", Sensei's replies and the app's receipts. Cards sit inline in the thread's timeline at the time they arrived, as described in Decide what needs you, so a message you send after a card shows below it. A reply you write here stays in the thread. Tick Also send to Sensei to show it on the Sensei page too. The tick clears after each reply.

A receipt is one line the app writes, with no Sensei reply behind it. It says that something opened or closed, such as "Merged", or that something happened that asks nothing of you, such as a first deploy.

On a wide screen the thread replaces the panel on the right, beside the page. In the iOS app and in a narrow window it fills the screen. Press the back button to return. The open thread is in the address, so a link or a notification on a computer lands on it.

A session belongs to one thread. A message that names a session, such as with a mention or a To #N chip, stays where you sent it, even when the session belongs to another thread. When one message asks for several things, such as "Ship these: A, B and C", Sensei does the first in your thread and starts a thread for each of the others, marked "Split from your message". A message that fits an open thread better can be moved there. Sensei says so when it moves one, and it never moves one once it has changed something.

Everything you said before threads existed is in one thread named Earlier. Reply there and Sensei answers with the memory it had.

A thread knows its own history. Sensei also sees a short list of your other open threads, and reads one on request.

What the counts mean

A thread is marked exactly when its state is Needs you: a card is open. Its row has a dot and a plain title. Events and receipts do not mark it or move it up the list.

The sidebar Sensei row counts Needs you threads.

Filter the threads

The Threads filter offers Project, then the states Needs you, Working and Done as checkboxes, all three checked by default. Needs you and Working show counts under the current Project filter and search. A row shows one state, with a spinner beside Working while a Turn runs or a message waits Up next. The dot means Needs you. Event lines and Receipts neither mark nor reorder a thread. Your choice stays set across a reload.

Choose Mark done from a row's menu in the Threads list to set aside your own working sessions until new activity. An open card, a running Turn or an Up next message prevents this, with a reason in its tooltip.

Nothing hides or archives a thread on a timer. When what waited on you closes, the thread reads Done and stays listed under Done.

Threads that wait on you come first, in a fixed order: a teammate waiting on you, your blocked builds, failures, merges, then messages. Inside a group, the latest activity comes first. The other threads follow, by latest activity.

Pin a thread

Right-click a thread in Threads, or on a phone press and hold it in Search or choose Pin in an open thread's ⋯ menu. A pinned thread shows a pin beside its title and stays at the top of the list, above every thread you did not pin. Choose Unpin to put it back in its usual place. You can pin as many threads as you like. Among the pinned threads, and among the others, the usual order holds: threads that wait on you first, then the latest activity.

A pin changes the order only. The filter and the search still apply, so a pinned thread must match your selected state like any other thread. A pin is yours, and it shows on every device you sign in on.

Ask across projects

Sensei answers from what your workspaces hold 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. When two workspaces could be meant, it names the workspace.

When an answer needs many sessions or projects read, Sensei can split the reading among helpers. Helpers are sub-agents of its own, on the same model and your Subscription. Each shows in the transcript as a row with its status. A helper only reads, so every action stays Sensei's. Sensei starts helpers only in an answer to your message.

The composer reads "Ask Sensei anything, in any workspace". Before you have written anything, the chat says how much Sensei watches, such as "Sensei is watching 6 projects in 3 workspaces". Only workspaces with projects count.

When an answer to a message you write needs you, it ends with a card in its thread. A question to you is a Yes or Answer card. After an answer, the card offers the next step, such as filing a ticket, with Yes. When nothing follows, or the thread waits on someone else, Sensei draws no card. You mark the thread done yourself with Mark done when nothing needs you anymore. A thread whose session is working gets its card when the session needs you. A question from Spotlight gets no card.

Every task it names comes back as a chip, the same one a task shows when its agent files work to the Backlog. It shows the task's status and title. On a task that is active or under review, Message this task points the composer at it, as on a task in the panel. Click a chip's title to open the task over Sensei. 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 "How are the open pull requests doing?".

The Threads list on the left holds every thread that matches the filter, with the ones that wait on you first and the rest by latest activity. A row shows the thread's title, then Sensei's face, its state, its number of replies, its pull request number and when it last changed. The list has its own search; press / to jump to it. "No threads yet" shows before you send a message, and "No thread matches." when a search finds none. Your own tickets in every workspace are in the Tasks column on the right, which the button at the header's right end shows or hides.

On a phone Sensei opens on Reels, with no Threads list or Tasks column. Tap New thread to write a new thread in a composer that opens under it, or press and hold it to talk. The header holds your avatar, New thread and Search. Search lists Later, Needs you and Recent, and adds Tasks when you type a query. See Use Sensei on a phone for what each row opens and how to go back.

Mention a task, a cron, an artifact, a thread or a member

Type @ in the composer to name the exact task, cron, artifact, thread or teammate you mean. The menu lists your most recent tasks, then your workspaces' crons, with their projects and status, then the most recent artifacts, including the ones a cron run wrote, from every workspace you belong to. Then come your own threads, with their state, and the members of your workspaces, with their email and role. Keep typing to filter by title, a cron by its name, or a member by name or email, across every project. Arrows move, Enter or Tab picks, Escape closes.

You are not in the list. A teammate who shares two workspaces with you shows once for each, and the mention names that workspace.

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 task, the cron, the artifact open in its task or cron run, the thread, or a member's workspace in Settings > your workspace > Members.

Sensei gets a reference to each mention, not its content, and reads the item itself before it answers. A member mention gives Sensei that exact person, so a ticket you ask it to assign goes to them and not to someone with a similar name. Archived tasks and their artifacts are not offered. A mention whose task, cron, artifact or thread is later archived or deleted stays in the message, struck through, and says why when you hover it. So does a member who left that workspace.

Ask it to act

Sensei 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, merges a pull request when you ask, and acts on GitHub as you when you ask, such as marking a pull request ready. See Act on GitHub as you. 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.

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

The app writes what happens to your sessions as events, and Sensei decides what needs you and draws the card, in an Event Turn. See Decide what needs you. Sensei never starts /kosuke:ship on its own judgment, and it files or starts a session only when you ask. It never merges unless you ask, and it does not groom the Backlog. For scheduled work, such as backlog triage, use a cron. A cron can send messages to you. See Messages from a cron or an agent.

Prototypes

Ask Sensei 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 writes it as an HTML file in the Files of the workspace the work is about. When it is unclear which workspace you mean, Sensei asks.

Each variant is its own file in a folder, such as prototypes/board/a-columns.html and prototypes/board/b-rows.html. Sensei's reply links each file as a file card. Press the card to open the file in Files, where the page runs in an isolated frame and its buttons and tabs work. To choose, say so in the chat, for example "Go with b-rows". Ask for changes and Sensei replaces the file, so the card always opens the current version.

On a phone, the design fills the screen. Use the bottom capsule's arrows or state bars to change states. You can also tap either side of the design. The capsule shows the current state and its place, such as "2 of 5". Press the cross to return to the card or file.

The ⋯ button opens a sheet with Flow, Condition, Theme, Reset flow and Show captions. Theme appears when the prototype has a theme control. A phone design uses your phone's width. A wider design scales to fit. A prototype file opened on its own has the same phone controls.

Files are shared. Every member of the workspace can open the prototypes there. The frame cannot read your Sensei login or call the platform. Sensei replaces only files it wrote in that work, or files you asked it to change.

To put a prototype on a ticket, ask Sensei to write the ticket and attach it. The ticket gets its own copy as an artifact. Its build agent reads that copy when the session starts.

Prototypes stored before Files existed were removed. An old reply that held one shows "Prototype removed".

Add work and ship it

Write "add a crons page to the backlog" and Sensei 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, or tell Sensei "start it". The session starts with /kosuke:ship as its first message. The tap is the yes. Sensei then says, for example, "Started Add CSV export in storefront." When the session needs you, Sensei draws a card in the session's thread. Sensei starts /kosuke:ship only when you ask.

Sessions cannot start while a project's first deploy runs. Ask Sensei to start one then, and it files the session to the project's Backlog, marked to start when the deploy lands. It says "Filed Add CSV export to storefront's Backlog. It starts by itself when the first Deploy lands." When the deploy lands, every session marked that way starts with /kosuke:ship, with Sensei as its Assignee. Sensei posts "Started Add CSV export in storefront." If that start is refused, because the workspace is out of credits, it is at its limit of sandboxes running at once, or there is no model to run the session, the session stays in the Backlog. An event about it is written in the session's thread, and Sensei can draw a card whose Approve starts it.

/kosuke:ship is a skill that runs inside the session and carries the ticket to a pull request that waits only for your go-ahead:

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 builds the change and opens a draft pull request.
3. It runs /kosuke:review before QA, every time, with or without Batch merging, and fixes what the reviewer finds. It may skip the review for a change that is only copy, styling or docs, and says so. Then it runs /kosuke:automated-qa on the reviewed code, and records the commit QA passed on, or skipped on when the Testing Checklist has no item. When QA's own fix changes the code, the same QA run tests the items the fix touched and records the pushed head.
4. It waits for the checks.
5. It leaves the pull request a draft. Your go-ahead marks it ready for review.

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 app puts in front of you
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 Fix. When QA was blocked for lack of proof, Retry QA
ready	Checks are green, and QA passed or was skipped on the current head	A card Sensei words from GitHub's review state, such as Request review or Merge. When the ready could not be proven, Fix

Sending /kosuke:ship into the session again resumes where it stopped, read from the branch, the pull request and whether QA passed on its head. Approving a card that answers it does that for you.

Create and switch projects

Sensei can make a YOLO project, import a repository into one and switch a project's mode. See YOLO mode.

• "Build me a booking app" makes a YOLO project from your sentence. Sensei answers with the project's URL, and the chat starts on your sentence when the first deploy lands. If you belong to several workspaces and named none, it asks which.
• "Import acme/storefront in YOLO" imports the repository in YOLO mode. Add what to do first, such as "and add a footer", and the chat starts on it when the first deploy lands. Without "in YOLO" the import is a Collaboration project. If the default branch needs a pull request, Sensei tells you why the import was refused and imports nothing.
• "Switch storefront to Collaboration" switches at once, because nothing closes.
• "Switch storefront to YOLO" first lists the Active, Under Review and Backlog sessions the switch would close or turn into Backlog items. Sensei switches only after you answer yes in a later message.

In a YOLO project Sensei sends your work into its one chat as a message, and starts the chat when there is none. It does not use /kosuke:ship, because there is no pull request to ship. When the chat asks you a question or a Turn fails, the thread that sent the work shows Needs you, and Sensei can put a card there that answers the chat.

Decide what needs you

The app follows what happens to your sessions, pull requests, Deploys and Crons, whether a session runs /kosuke:ship or not. Each thing that happens is written once into the thread that holds it, as a one-line event. Sensei then reads the new events and decides whether something needs you. If so, it draws a card in that thread. If not, the line is all you see. The app draws no card of its own, so every card says what Sensei found worth your decision, in words it chose.

Events

An event is a short line in a thread's stream, such as "Checks failed on #2161: typecheck, lint" or "Ada approved #2161". It records what happened and asks nothing. It sends no notification. Events come from:

• A session: a turn that ended, stopped or failed, a question from the agent, a /kosuke:ship stop, a message into the session, a start that was refused, a reassignment, and a session that moved to another thread, was archived or was deleted.
• A pull request: opened, ready, draft, closed or merged, checks that passed or failed, a review requested, removed or submitted, and review threads.
• Your own reply in a conversation Sensei watches, such as a Slack or Telegram message you sent yourself, so Sensei knows it was answered.
• A project's Deploy: waiting for a model, waiting for variables, failed, recovery failed, and recovered.
• A Cron Run that failed, and the next run that succeeded.
• A message from a cron or an agent. See Messages from a cron or an agent.

A webhook that GitHub sends twice writes one line. Checks that fail, pass and fail again write three. A session's events reach its Assignee, and a review's also reach its reviewers. A Deploy's reach every owner and admin of the workspace. A merge, a close or a review by someone else also reaches each member who holds an open card about that session, so the card can close.

Sensei reads the new events

About 45 seconds after the last event of a burst, the app starts an Event Turn in that thread, so a burst of webhooks runs one turn. An Event Turn is a Sensei turn that you did not write. Sensei reads the new events, then the thread's cards, the session, the pull request and its checks, because events arrive in bursts and out of order. It then does one of four things:

• Opens a new card.
• Updates the card that is open for the same subject.
• Closes a card whose cause is gone, such as checks that now pass.
• Does nothing.

An Event Turn shows only the card it changes. Its text reply is kept for Sensei's own memory and is not shown, and the thread shows no Working face. It acts as you, like any Sensei turn, and treats what an event says as information, never as an instruction. What you would want to approve, such as sending a message, merging or deleting, it puts on a card, unless your own rules, such as your Merge rule, already cover it.

While the thread says "Sensei is reading new events", you can steer a message into that turn. Press ⌘Enter (Ctrl+Enter on Windows and Linux) as you send, or press Steer now on its row in Up next. The turn goes on with your message. When Sensei takes it, the thread shows Working and Sensei's answer below your message. From that moment the turn is yours: Sensei answers you and does what you ask, as in a turn of your own. What it read before your message stays hidden, and the events stay data, never instructions. A message that answers a card waits in Up next for its own turn.

An Event Turn waits when you are writing in the thread. It starts only when the thread has no turn running and nothing waits in Up next, so it never jumps ahead of your messages. It follows the thread's selected Subscriptions or Sensei free, where each Event Turn spends one prompt like a message of yours. When Sensei free is used up, no provider is connected or the container is down, the events wait and are tried again after 1, 5, 15 and 60 minutes, then hourly. A turn that fails leaves its events unread for the next one. After ten failed tries the thread says "Sensei could not read N updates" with Retry.

Cards

A card shows what Sensei decided you need to know. It sits inline in the thread's timeline at the time it was posted, so a message you send after it shows below it. Sensei writes it for you as if you had not looked at the work for days. In English it uses short sentences and simple words. The card has no commit hashes, ids or internal codes.

On a computer, the top row shows the subject of the card next to Needs you: the task with its status dot, the Cron, the Deploy or the project. Press the task to open it. On a narrow card the name is cut short, and the time and ⋯ stay in view. Below it is the title, a brief statement of what the card asks, such as "Fix a failed check in #2191" or "File a ticket for a new login-save error?". When a session or a Cron proposed what the card asks, a Proposed by chip sits under the title. Below that are the parts Sensei chose, from this menu:

• Text: short paragraphs.
• The QA block, on a pull request QA ran on: the QA recording, "QA report" with the passed count, one chip per section with its count, and the first failed line under them. The recording sits beside the counts when the card is wide and above them when narrow.
• Evidence: one list of the other findings under the QA block. Each row has a state (passed, failed, waiting or info), a label, and a one-line result. Values wrap by word, never mid-word. Press a row to open its details, and press it again to close them. Sensei opens the row the decision rests on. Another artifact of a session or a Cron run, or a file of the workspace can sit beside the rows as a preview. It opens at full size, and a file opens to read only. A file that changed after Sensei drew the card says so.
• The questions an agent asked. Sensei rewrites them in plain words, checks them, and shows Sensei's check with its verdict (it agrees with the agent, disagrees, or could not check) and why. Each option says what you get. Sensei's pick starts picked and shows Sensei recommends. The agent's own pick shows The agent's pick when it is another option. An option Sensei advises against shows Sensei advises against.
• The teammates to ask for a review, with why. Only a card that asks for a review lists them.
• What changes in a text, such as a QA Guide, a Memory file or a task description. One line counts the changes, the sections they touch, and the lines added and removed. Press it to read the real lines, by section, with removed lines in red with − and added lines in green with +. Unchanged parts are folded and named. Press one to read its lines, and press Hide to fold it again. A single small change opens by itself.
• A merge plan: pull requests in the order to merge them.
• The Deploy variables form.
• A person: who a message or a request is from, with their role.
• An image, such as a screenshot.
• An event: a calendar slot, with its time and who is invited.
• A ticket: a Backlog ticket, with its title and priority.

A card about a pull request always shows its QA report and the artifacts it has, such as a prototype or findings.

On a computer, above the footer, a line reads "When you tap" and the name of the button, and says what happens. The footer reads a negative button, a Reply button with its icon, and a button named for what it does, such as Fix, Merge or Answer. The negative button reads Reject in red on a card with a button that acts, and a neutral Dismiss on a card without one. Sensei can word it to fit the card, in one word such as Skip or Cancel, and choose red or neutral apart from the words. On a card that drafts a reply to a message, Reply reads Edit, with a pencil. On a computer, the three buttons sit together at the right of a thread card, in one row even on a phone-sized window. In desktop Reels, the negative button sits on the left edge, Reply in the middle and the other button on the right edge. It is never a bare "Approve". Phone cards have the layout described in Reels, including in a thread. The card does not show the detailed instruction that Approve sends. On a computer, open the ⋯ menu and choose Show what the session gets, Show what Sensei runs, Show the ticket prompt or Show what Sensei saves. A card that only points somewhere, such as one that asks you to reconnect GitHub or open billing, has no instruction: it shows Dismiss and its link buttons.

A model may get a value wrong. Reply is how you correct it before anything runs.

A card has at most three buttons, in this order: its negative button, Reply, and its primary button. Each reads one word. Sensei writes the card's own actions: at most one primary, the filled button, and at most one red one, which takes the negative button's place, such as Reject on a review. Each action has a label and the message it sends. Pressing an action sends its message to Sensei in the card's thread, as your own message, exactly as written. Every press closes the card. On a computer, point at an action or move to it with Tab to read the message it sends. A phone does not show it. A card drawn before this rule with more actions shows them all, and the extra ones sit beside the primary on a computer and above the buttons on a phone. A card drawn before actions existed has one button, its verb, which works the same way.

The link buttons sit in the card's ⋯ menu and read Open pull request, Open Cron run and Open project. The ⋯ menu has no Open session: the task chip in the top row opens it. Approve runs the instruction, and Sensei does what the card's title, outcome and request say. A card that asks for a review names the reviewers and why Sensei suggests them. When Sensei can suggest nobody, the card has no button. A merge or an approval pins the commit it was drawn from, in the instruction.

What happened	What the card tends to show	Its button
The checks failed	The failed checks with their links	Fix
QA failed or was blocked	The QA result and what the failures mean	Fix or Retry QA
The agent asked a question	The questions, with the recommended options picked	Answer
A session drew a prototype for you to approve	The prototype and what you decide	Approve
The pull request is ready and GitHub requires a review	A short explanation, the QA Report with its recording, and who to ask	Request review, which asks them with your GitHub CLI and gives the go-ahead to merge once approved
The pull request is approved and has no go-ahead	A short explanation and the QA Report with its recording	Merge
A teammate asked you to review	A short explanation and the QA Report with its recording when QA ran	A button that names your review
Several pull requests are ready	A merge plan	Merge all
A cron or agent found a ticket	Why it exists and what the sender found	File ticket
A Cron Run failed, or a Deploy failed	What failed, and a link	A button that fits, or links only

This is a pattern, not a fixed list: Sensei decides what each card shows.

A question card is interactive. Sensei's recommended options start picked, each pick changes the outcome and the instruction, and Answer sends it. Reply sends your own words to Sensei instead, without the picks.

On a computer, when a card holds two or more questions, it shows one question at a time in a question box. A bar at the top of the box has one segment per question: the one on screen is dark, the ones you have seen are grey, and the rest are light. Tap the right edge of the box for the next question and the left edge for the one before it; tap a segment you have seen to go back to that question. There is no Next button. Each option is one large row, with what it means under its name. Sensei's check folds to one line, and a tap opens its reason. Before the last question, the footer's button reads how many questions are left, such as "2 more questions". On the last question, the card shows "When you tap Answer", one row per question with its pick, and what happens: tap a row to open that question again. Your picks stay while you move, and Answer sends them all. A card with one question has no bar and no tap edges, but the same large rows and folded check.

Under the answers of each question, Add a note opens a field. With an answer picked, your text is a note on that answer. With no answer picked, or after you choose My own answer, your text is your own answer in place of the options. With my pick turns it back into a note. While the field is open, a tap on an answer picks it and stays on the question. After Done, the note shows under the answers with Edit, and the last step shows it under its answer. Sensei receives each note after its answer, and your own answer in place of a pick. This works on a computer and on a phone.

Approve, Reply and Reject

On a card that drafts a message, Sign as Sensei sits under Your reply. It starts from your saved default in Settings > Signature, which is on unless you turned it off. Change it for this reply only: the note says whether your default is on or off, and the draft shows the exact message Send will send, including the marker when on. Slack, WhatsApp, Telegram and LinkedIn use [Sensei]; Gmail uses Sent by Sensei. The outcome line also names the marker. Your choice stays with a phone send while it waits behind Undo.

Approve sends the instruction to Sensei, in the card's thread, as your own message. The thread shows the card's short request, not the instruction. Sensei reads the current state of the session or pull request, then does what the instruction says: it sends words into a session, sends /kosuke:sync-branch, asks for a review, merges, files a ticket, starts one, or retries a deploy. Approve on a card that starts a Backlog ticket opens a new thread named after the ticket, and Sensei starts the ticket there with /kosuke:ship. The ticket's events, questions and cards then show in that thread. The card's thread keeps one line, Started and the ticket's name, with Open thread. When another thread already follows the ticket, Sensei starts it in that thread instead, and the card's thread still keeps the Started line. Nothing reaches a session without a Sensei turn. When the state changed since Sensei drew the card, such as a newer commit or work that already happened, Sensei says what changed instead of running the old instruction.

Reply is the card's button in the web app, with a reply icon followed by the word Reply. It works in the browser on a computer, in the iOS app and in the desktop app. The Watch and the glasses answer a card their own way.

Reply opens the thread's composer empty, with the card as a chip. Write your own words, such as "also cover Cron runs" or "why not wait?", and send them. Nothing is filled in for you. The app stores your words and closes the card at once: its row reads Replied, and the card no longer has its buttons. Sensei then reads your words against the card's current state.

Sensei reads the card's current state, then does one of three things:

• A clear decision, such as "yes", "merge it" or "the second option", takes the card as drawn or one of its paths. A full decision with a clear adjustment, such as "A but without arrow", also counts. A reply that adds more of the same work to the same session, such as "also test the handover" on a Retry QA card, counts too, when it stays within what the card allows. Sensei acts on it at once, within what the card promised plus that adjustment, and reports what it did. It does not ask you to confirm that settled decision again. The card stays Replied. A clear decision counts as your go-ahead, as Approve does.
• A plan change, such as "yes, and also merge it" on a card that only reruns QA, leaves a decision open or asks for something the card did not offer: a different action, another session, or a merge or review. Sensei answers you and puts a new card for you to approve. The replied card stays in the thread as its history.
• A question, such as "why not merge now?", gets an answer. Sensei does not act on it. If the question still leaves a decision open, Sensei puts a new card for you to decide.

Sensei never sends your words to a session as you wrote them. It writes its own message.

If the app refuses your reply, the card stays open and says why. If the card changed since you opened it, the app shows the new card and says that Sensei updated it. Your words stay in the composer, and sending again replies to the new card. A reply the app stores has already closed its card, so there is nothing to undo.

A card you replied to reads Replied. Older cards approved with edited words, and Watch answers sent as text, read Approved with your words.

The negative button closes the card and records the decision, whatever its words: Reject, Dismiss, or Sensei's own. It sends nothing to Sensei. On a card that drafts a reply to a Gmail, Slack, Telegram or WhatsApp message, the negative button, such as Skip, also marks the messages it answers read. If that fails, they stay unread and the card stays closed. On a yes/no card it is the no. Its row in the thread reads Rejected, Dismissed or Skipped, or Sensei's words as they were on the button. Sensei cannot open the same card again for the same state, so it comes back only when the state changes, such as a new commit or a different failing check. If the decision fails, the card comes back with a line saying so, and you can press the button again.

On a phone, swipe a card right to approve it or left for its negative button, or press the buttons. The swipe shows the negative button's words, in red or neutral as the button is. Either way the card goes and Undo shows above the composer for four seconds. Nothing is sent until they pass, and Undo brings the card back. Leaving the thread sends it at once. In the iOS app your phone taps when a swipe will act. A card the swipe cannot act on, such as a Deploy card that asks for values, springs back and says why.

If the turn that carries your Approve cannot start, because no provider is connected, Sensei free is used up or the container is down, the card stays open and says why, with how to fix it. After the send the card closes. If the turn that carried it fails or is stopped, or you delete the message from Up next, the card comes back with "The last attempt stopped" and the reason. Nothing replays by itself. A card changes as events arrive, so a press on a card that changed since you opened it is refused and the new one takes its place.

Only a card's link buttons, the button of a link card and the Deploy variables form act outside a Sensei turn.

Sensei deletes a Backlog ticket only for a card you approved that asks for it, or when you ask it to in a thread, and only a Backlog ticket. It always asks first, naming each ticket, and deletes only the ones you confirm in your next message.

A card closes when Sensei sees its cause is gone. A thread the app opened and you never wrote in disappears from Needs you and Done when Sensei closes its only card, for example because a teammate approved. It sends no notification, stays reachable by search and by link, and comes back when a new card opens in it. A thread where you wrote anything is never hidden.

Reels

Reels shows one card at a time, in an endless feed with the next cards below it. On desktop, press Reels in the page header, or press R. The button counts cards that need you. On a phone, Reels is the whole Sensei page. A thread pushes from the right, and Back or a swipe right returns to Reels.

Press the card's verb, or ⌘→ / Ctrl→, to act. Press the negative button, or ⌘← / Ctrl←, to turn it down. On a phone, swipe right for the verb or left for the negative button. Reply puts a card chip in the composer and sends your message to that card's thread. Without a chip, sending starts a new thread, with a link to open it. On a computer, the thread chip opens the card's thread. Go back to return to the same card, or choose Open in Sensei.

Later hides a card from Reels for 30 minutes. On a computer, press Later beside the thread chip, or ⌘↓. The hold survives a reload on the same device. A new push, check result or review on its pull request brings it back sooner. A new message in its thread also ends the hold. The card returns to its ranked place and keeps its question and picks. Undo brings it back at once. The card stays open in its thread as Needs you. On a computer, Later is disabled on the only open card.

On a phone, Reels has its own layout:

• New thread sits in the header. Tap it to write a new thread in a composer that opens under it. Press and hold it to talk. The capsule shows the time and a sound wave. Lift your finger to finish. Your words wait at the top for four seconds with Undo, then go as a new thread marked Spoken. Tap the words to send at once and open the thread. Slide sideways to cancel, or down to lock recording hands free. When locked, press Send or the cross.
• Every card has the same height, between the header and footer. Scroll inside the card to read its details. The header row shows its thread, project and time. Tap it to open the thread. Later sits beside it.
• The card shows a status, a large title and its text. The text is shown whole when the card has room for everything else on its first screen, and is cut to the most whole lines that leave that room otherwise (at least one line). Read more shows only when the text is cut, and opens the full text in a sheet from the bottom, including on question cards. Drag the sheet down or press its down arrow to close it. When the text is scrolled, first scroll back to the top.
• The card shows the facts needed for its decision, such as QA results, failed checks or a teammate's message. Below them are the details available for that card. These can include QA report, Evidence, About, what happens when you press the verb, and Open. More about this card scrolls to them. Open QA report opens the report as a page. The Open group has the thread, task and other links. What the agent gets shows the detailed instruction.
• The QA recording plays inside the card. It shows only the tests that have a video, and opens on the first failed one. Tap the left side for the previous test, the right side for the next, and the centre to play or pause. Bars show playback progress. The caption names the test and its result. A card with no video at all shows a still. Full screen opens the recording in full screen, using the iPhone video player when needed. If full screen is refused, a message says so. If the recording cannot load, you can still open the QA report.
• A question's options are large rows. No answer starts selected; Sensei's pick carries its tag. Next and a right swipe wait until you pick an answer or write your own. Add a note sits under the answers, as on a computer. With several questions, a bar marks each question and a final step named Check your answers. Tap a single-choice answer to move to the next question or that final step. A question with several picks stays until you press Next. The verb reads Next, then Review on the last question. Check your answers lists every pick, its note and any answer in your own words, with Change. Only there does Answer, or a right swipe, send them all. Tap a bar you have seen to go back. A card with one question has no bars or review step. Answer sends its pick. Sensei's check opens Sensei's verdict.
• A prototype card shows a preview with a bar for each state. Tap either side to change states, a bar to choose one, or the middle to open it full screen. See Prototypes for the phone viewer. Swipes still approve or turn down the card. A right swipe before Check your answers returns the card and says why. A Backlog ticket shows its description in full when it fits, and cuts it only as far as its Priority and In Backlog tiles and More about this card need; then Read more opens the full prompt. A Deploy card shows hidden fields for its values. Save sends them to the Deploy.
• The footer stays at the bottom with four buttons. These are Reject, or the card's negative button, Reply, Talk and the verb. A card without a verb has no primary button. Reply opens the text composer with the card attached. Talk starts recording at once, hands free. A recording bar replaces the buttons, with a timer, sound level, discard and send controls. After you send, the spoken reply waits four seconds with Undo before it goes. A typed reply or new thread shows a link to its thread, with no Undo.
• Later is a button beside the card's header row. Tap it, or pull down from the top of the content. The card slides straight down with a Later stamp. Later works on every card, including the last one. If it fails, the card returns and a message offers Try again. Search folds Later into one row with the count and when the next card comes back. Tap the row to list the cards with their time left, and tap one to bring it back to the top of Reels.
• Undo for a decision, Later or spoken words shows under the header. A card in a thread has the same buttons and left and right swipes. Pull down for Later is available in Reels.
• Threads, thread tasks, tasks and QA reports slide in from the right. Open chat on a task opens its own Chat Session on the phone, with the same composer as a thread. Press Back or swipe right anywhere on the page to return one page. Text fields, sideways scroll areas and cards keep their own drags. A thread on a phone does not show its agent bar, Sensei Delegates or helpers. Unsaved task edits stay until you save or discard them.

Reels shows the newest cards first: a card moves up when it opens, when Sensei changes what it says, or when it comes back to you after a failed Approve or a dropped reply. Activity in its session alone does not move it. A new or changed card goes right after the card you are reading. A history line shows your last decision, with Undo when that decision allows it.

Reels shows only cards. Your Backlog tickets stay on the Backlog board and in their projects. When no card remains, All clear appears. On a phone, pull down there or press Refresh to bring Later cards back first on this device. A failed refresh shows a message and can be tried again. The composer stays available.

Deploy cards

Some cards are about a project's deploy rather than a session. They reach every owner and admin of the workspace. They post in one thread for each project, "Deploys of" and the project, and every later Deploy of that project reuses it.

• A workspace Deploy waits when workspace Credentials cannot run the deploy agent. The card links to the Deploy Chat and asks you to tell a workspace admin to fix those Credentials. A personal-project Deploy follows the owner's Deploy model setting, or the first connected provider in catalog order and its catalog default model when unset, and stops with a notice naming the problem and the setting when that choice cannot run. Limits and failures never move a Deploy to Free.
• The deploy agent asks only for what the app cannot start without. When it does, the card shows the Deploy variables form, with a field for each one and the deploy agent's reason. Save and continue saves what you filled in as the project's environment variables and resumes the deploy. A field you leave empty is not saved. Deploy without them resumes it with none. The values go straight to the Deploy, so no Sensei turn ever sees a secret.
• When a deploy fails, the card says what failed, with the fix the deploy agent proposes and a link to the Deploy Chat.
• When a first deploy fails, the app starts one Recovery Deploy on its own. This is a receipt, and nothing asks for your action. When the Recovery Deploy fails too, Sensei can draw a card with the fix. A Recovery Deploy follows the same credential rule and spends no prompt.
• When a deploy lands, a receipt tells you, such as "storefront is deployed. 3 services are up." This sends no notification. When the deploy agent generated values, used test keys or mocks, or turned features off instead of asking, one line sums them up, such as "3 values stubbed, Stripe checkout off. Add real keys in project settings."

Importing a repository adds one line to your Sensei Chat, such as "You imported storefront into Acme. Its first Deploy started." The line says the deploy started only when it did. See Deploy your project.

Cron cards

A Cron Run that fails writes an event in that Cron's thread. When the cause is one you can fix, such as no AI provider for the workspace, credits at the limit or a project that is not deployed, Sensei can draw a card with a way to fix it and a link to the Cron. The next successful run lets Sensei close it. See Crons.

Notifications

Every card sends one notification when it opens, unless Sensei marks it as one that can wait: such a card shows in its thread and in Reels and sends none. A receipt about something that asks nothing of you, such as a first deploy, sends none, and neither does an event line.

• What it says. The title says in which thread the card is. The body is the card's headline.
• Where. On every device at once: the desktop app, the browser, the iOS app on your iPhone and your Watch.
• When not. The app holds back only the notification for the thread you have open on screen, on any device. A card in any other thread notifies you, whether the app is in front or not, and even while Sensei is open.
• Clicking. On a computer it opens the thread. On an iPhone or iPad it opens Reels on the card, or the card's thread when the card is no longer open. On a phone that thread opens over Reels: Back or a swipe returns to Reels. There, all of Sensei's notifications share one stack.
• Deciding from it. On an iPhone, press and hold the notification, or pull it down, to decide the card without opening the app. See Decide a card from its notification.
• Taking it off. Opening the thread on one device, or the card closing, takes its notification off your iPhone and Watch.

An update to a card notifies again only when what it sends changed: its instruction, the text it compares, or its question and options. Notifications are sent by the app when the card opens, so they do not depend on Sensei's model.

Decide a card from its notification

On an iPhone, press and hold a card's notification, or pull it down. Its buttons are the card's own:

• The verb, such as Merge or Fix, does what the card's verb does in the app.
• The negative button, such as Reject or Skip, closes the card and sends nothing. It is red when the card's own is.
• Reply opens a text field. Your words go to Sensei about the card, and the card closes as replied.

A card with one question of two to four options that takes one answer shows the numbered options and Own answer instead. A number picks that option. In Own answer, the option's number, its title or the words the notification shows for it picks it too, and other words are your answer.

On a locked iPhone, each button asks for Face ID or your passcode first. When a button cannot finish, a new notification says so, for example "This card changed" or "Merge may not have gone through". Tap it to open the card.

The verb shows the card's own word when it is one Sensei uses on its cards, such as Approve, Fix, Merge or Yes. For any other word, the button reads Approve. On a card with actions, the verb is its primary action, or its first, and pressing it sends that action's message. The Watch and the glasses show such a card the same way. Some cards offer no verb on the notification: a card with no verb, a Deploy form, and a card with several questions or a question with several answers. Open those in the app. The Watch shows Open only. These buttons need the iOS app 1.0.36 or later.

Messages from a cron or an agent

A cron, or an agent in a chat session, can send your Sensei a message for something it found and may not do itself: a ticket it wants to file, a ticket to start or delete, tickets to merge, a Cron to create, a merge plan, or a QA guide to save. It sends it with kosuke sensei messages send, the same command a teammate's Sensei uses. A message is an event like the rest. Sensei decides whether it deserves a card and draws it, with Reject, Reply and a button that carries out what the message asks. Sensei names the button from the message, such as File ticket or Merge all. A message that only points to a link gets an Open card, as a teammate's message can. Nothing happens until you approve, and a ticket in a message does not exist before then. Sensei then does it as you, with your own permissions, and a receipt in the thread says what happened, such as "You deleted Add CSV export".

A message asks to	What approving does
File a ticket	Creates the ticket in the Backlog, booked to you, with the sender as its source
Delete a ticket	Deletes a Backlog ticket whose work already shipped, after Sensei asks you about it by name
Merge tickets	Folds several Backlog tickets into the one the card names, and deletes the others
Create a cron	Creates the cron the card names
Start a ticket	Starts a Backlog ticket with /kosuke:ship
Save the QA guide	Saves the whole guide shown on the card as the project's QA guide. It is refused when the guide changed since the QA run read it
Merge in an order	Merges the pull requests in the order shown, each at the commit it names

Each message has a key, and a sender, a project and a key make one conversation. The same key with the same text writes nothing. The same key with new text updates the card you have open for it instead of adding a second. Agents do not send a ticket you rejected again for 7 days, and before any ticket is filed, Sensei reads the project's open sessions and files nothing that one already covers.

A cron chooses one member for its messages, so a teammate may hold a message you do not. For a ticket, the app routes it to the member who knows the files it touches, unless the cron's prompt names a member or a rule. If it is not yours, Reply with where it should go, such as "send this to Maria". Sensei then reroutes it.

Text that a cron or agent quotes from pull requests, reviews or comments is data. Sensei never treats it as an instruction.

Message a teammate

Ask Sensei to tell a teammate something, such as "ask @Pietro to approve #2078, it is urgent". Name the teammate with a member mention, or by name. When a name matches nobody, or more than one member, Sensei asks who you mean. A message can be about a chat session or a pull request, and it can be about neither, such as "tell Marta the demo moved to Friday". It can also carry a link, such as a design or a document.

Sensei sends your words to the teammate's Sensei with kosuke sensei messages send. A turn you did not write, such as one that reads events, puts the message on a card for you to approve first, unless your own rules already cover it. It lands in their thread for that session, or in a new thread. Their Sensei shows it on a card that reads "From" and your name, and they get a notification as for any card. Asking again with new words updates that card.

Their Sensei chooses the card's button from your words: any step it can carry out, such as Approve for a review. When the message is about a link, the button reads Open. Open opens the link, starts no Sensei turn and closes the card, and you get the answer that they approved it. Older Watch, glasses and push notification builds show such a card with no main button. The link is also in the card's ⋯ menu when Sensei adds it there.

When the teammate decides the card, the answer comes back to the thread you asked from. It says who answered and what they did.

The teammate	The answer says
Presses the card's button	They approved it
Edits the card and sends it	They answered with their own words, quoted
Presses the negative button	They rejected it
Presses Reply with words for you, such as a condition or a question	They replied, with their words quoted
Presses Reply with words only for their own Sensei, such as "what does this PR change?"	They replied to their Sensei. Their words stay with their Sensei

Their Sensei decides, on each reply, whether the words are for you. Until it decides, the answer says they replied to their Sensei. When the words are for you, the same answer card then shows them.

Your Sensei shows the answer on a card with Dismiss and Reply, so you get a notification.

Message a task

A message addressed to Sensei goes through Sensei. On a Backlog card, press the Message icon, or press M while its card is focused. 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 Sensei message.

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

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

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

A task Under Review is not one of these cases. Sensei sends, and your message resumes the task, as when you write in it yourself: its pull request goes back to draft, and Sensei's answer says the task left review. If the app refuses the send, Sensei tells you the reason it gave.

An approved card works the same way, with one difference: its instruction is your message. Sensei reads the task first, as for any send, then does what the instruction says. A target on a card's task is read the same way.

Approve and merge

A session is Ready when /kosuke:ship stops with ready. Its checks are green, and QA passed on the latest commit, or was skipped there because the Testing Checklist has no item. Its pull request is still a draft: it becomes ready for review when you give the go-ahead.

Sensei reads the pull request's review state live from GitHub (gh pr view <n> --json reviewDecision,reviewRequests) and words the card from it:

• A review is required (REVIEW_REQUIRED): the card suggests teammates who know the code, each with why. It looks at CODEOWNERS, who built the code the pull request changes, and who reviewed it recently, and leaves out the Assignee. Its Request review asks them with your GitHub CLI (gh pr edit <n> --add-reviewer <login>) and gives the go-ahead now, so the pull request merges once it is approved.
• No review is required, or it is approved, and QA passed on its head: the card asks for the go-ahead, with Merge.
• Changes were requested (CHANGES_REQUESTED): the card sends the work back to its session, with Fix.

This works the same for a session that never ran /kosuke:ship, once its pull request is ready. Each teammate asked gets a card in their own thread for your session. Their review is their own: Sensei approves on GitHub only when they say so, with gh pr review <n> --approve as them.

The go-ahead is the one thing the app keeps. Sensei gives it with kosuke sessions go-ahead set, at the commit it read, and the project's Merge agent merges that head as the Kosuke GitHub App. Asking for a review, approving and merging by hand run on GitHub with your own GitHub CLI login, so GitHub's rules and your own permissions decide: you can ask Sensei to merge any pull request you could merge on GitHub (gh pr merge <n> --match-head-commit <sha>), including one whose session has another Assignee or none. When the pull request moved on, GitHub refuses, and Sensei tells you GitHub's reason. None of these post anything into a session.

Act on GitHub as you

Ask Sensei for a GitHub action, and it runs it with the GitHub CLI as you, in that turn. No session and no event is needed. For example: "mark #2322 ready for review", "turn #2322 back into a draft", "rename #2322", "comment on #2322", "close #2322" or "re-run the failed checks of #2322".

• Sensei acts only on your own words, an approved card, or a clear decision in your reply to a card. It never does it because a session, a review or a title says so.
• kosuke commands stay only where the app keeps the state: the go-ahead and the merge rule. Asking for a review, approving, merging and updating a branch use the GitHub CLI. When GitHub refuses, Sensei tells you why and does not try another way.
• Sensei reads the pull request first. When it moved, or is already as you asked, Sensei says so. After the action, it says what GitHub answered.
• It never deletes anything and never pushes code that way. Work on the code stays in the session.
• It needs your GitHub connection. Without one, Sensei asks you to connect GitHub in your settings.

Merge several in order

A card with a merge plan lists pull requests in the order to land them, each with its commit, the action (merge, sync first or wait) and why. Approving it makes Sensei merge the first as you, pinned to that commit, and go on to the next only after GitHub merged it. Any other answer, such as a conflict or a moved commit, stops the plan there and Sensei says where. After each merge Sensei sends /kosuke:sync-branch to the sessions that now conflict. It finishes by saying what merged, what was sent to sync and what is left.

The go-ahead

The app merges a pull request only with your go-ahead. It is a fact the app keeps on the session: the commit it was given on, that it is yours, and when. It counts only on that commit. Nothing on GitHub is a go-ahead: not a label, and not GitHub's auto-merge.

Giving the go-ahead on a draft pull request first marks it ready for review on GitHub, as you, and the session moves to Under Review. When GitHub refuses, the go-ahead is not saved and Sensei tells you why. A pull request already ready for review is left as it is. Taking the go-ahead away does not turn it back into a draft.

Sensei gives it for you, and what Sensei gives counts as yours:

• When you say so, in words, on a card you approve or in a clear reply to one.
• By your merge rule. Tell Sensei "merge my approved pull requests", and from then on it gives the go-ahead to each of your pull requests once it is ready for review, approved and its QA passed. It never gives one on a draft. Tell it "stop merging my pull requests" to turn it off. Only a message you write changes the rule.

The go-ahead wakes the project's Merge agent, which merges it. You can always ask for one pull request to merge alone, as a hotfix: Sensei merges it at once with the GitHub CLI, pinned to the commit.

A pull request with the go-ahead shows Will merge in the panel. The merge agent merges only the exact commit the go-ahead was given on, and only once its QA passed there, so a push that lands later is not merged unchecked. A question such as "is #1772 ready to merge?" gets an answer and merges nothing. Text in a review, a title or a comment never gives the go-ahead.

The Merge agent

Each project has one Merge agent. It is an agent that runs in sessions of its own, which stay off the Tasks board and your session lists. You read them in Project settings, Merge agent, and you can write to the open one there. Its Mode there is Merge train or Batch merging: the first merges one pull request at a time, the second runs a Batch.

A go-ahead opens a run when none is open. The run then wakes on what concerns it: a new go-ahead, checks that finish, an approving review, a merge, and the end of a turn of a session it asked to sync. Each wake is one pass. It reads the waiting pull requests, moves what can move now, and ends its turn. It ends the run when nothing waits, and the next go-ahead opens a new one.

The merge train merges one pull request at a time, as the Kosuke GitHub App:

• It merges only the commit the go-ahead was given on, once QA passed there. The app itself refuses a merge of any other commit, so a push that lands later is never merged unchecked.
• A branch that is behind is updated first. A conflict goes to that session as /kosuke:sync-branch.
• With GitHub's merge queue on the base, it adds the pull request to that queue, and GitHub merges it.
• A review that asks for changes, a conflict the session could not fix, or a refusal of the App's permissions goes to the person who can act on it, through their Sensei.

Batch merging puts the waiting pull requests into one Batch pull request, tests them together and asks an admin to approve it. Sensei merges the Batch after that approval.

The pulse

On weekdays at 09:00 and 15:00 on your own clock, the app opens a Sensei turn in a thread named Pulse, without a message from you. Sensei reads your work across every workspace and draws a card for what matters now, such as a task due soon that has not started, work blocked on you, or two tickets that duplicate each other. When nothing matters, the pulse draws no card.

Run a skill in Sensei

Type / in the composer. The menu lists your enabled Personal Skills. A workspace's skills do not reach Sensei. 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 Factory Skills are not in Sensei's menu, because each one needs a session's branch, pull request or Preview. To run one, such as /kosuke:open-pr, ask Sensei to send it into a session. Sensei checks that the skill is enabled using the agent the session’s model runs in, for every released provider: Claude Code for Claude, GLM, Kimi and DeepSeek; Codex, Muse Code or Antigravity for the others. Your Personal Skills always show, even one that needs a branch, because the app cannot tell what they need.

• Sensei 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 Sensei only. Nobody else's Sensei can read them.
• A skill turned on or off in settings reaches Sensei at its next answer.

Sensei loads no plugins. Plugins run in chat sessions only.

Pick a model

Pick the model in the composer's model picker. While you hold a Subscription, it offers Auto and your personal models, grouped by provider. With none, it shows only Auto - Free, with the prompts left, and Connect a subscription. A login at its limit or needing reconnect still counts, including SuperGrok. A thread keeps the choice made in it. A thread with no choice of its own runs your personal Default Model, the one in Settings > You > AI Providers. A pick in the New thread composer, before the thread exists, changes that Default Model.

On Auto, the Model Router picks the model for each message you send, as it does for a task on Auto. It reads the message, sets how hard the Turn is, and picks a model of any released provider your Subscriptions can run, Gemini and Muse included. Auto steps down to a model the login's plan offers. Event Turns, the Turns a delegate starts on its own, and commands carry no message of yours, so they run on the model the thread's last Turn ran on. When Auto cannot pick, the Turn runs on your Default Model if it can run, or a usable provider's model.

When the provider of a Turn's model is at its limit and another Subscription can run, Auto move runs that Turn on Auto over the other usable providers. This applies to replies, Event Turns, card sends, commands and delegates. The saved thread model and Default Model stay as you set them. After the reset, the next Turn uses the saved model again. The notice reads "Muse is at its limit until Sun 16:00. Sensei uses Auto until then." It has no button and Send stays available. The Turn shows Auto - and its routed model. When every provider is at its limit or the selected provider needs a sign-in, Send waits and the notice offers Connect a provider or Reconnect.

For Gemini, the picker uses your saved Antigravity sign-in. There is no personal Gemini API key or method selection.

The picker leaves out the Ultracode and Ultra efforts. If your last pick or Default Model uses one, Sensei runs at the highest effort below it that the model offers. Switching a personal model to another provider hands the conversation over, and the transcript marks where. Free routing keeps its moves hidden.

The Notifications from Sensei switch in Settings > You > Preferences turns Sensei's notifications on or off on the device you set it on. It does not stop pushes to your phone.

The Free selection reads Auto - Sensei free. Its help tooltip says "Connect a personal subscription to use top-tier models." Free is available only while you hold no Subscription. The app chooses its model internally and shows no Free model, Source, provider or routing move.

Member Turns and Event Turns follow the thread's stored choice. Each Free Turn spends one prompt from your shared rolling 7-day allowance. At the cap, Event Turns wait. No workspace Credentials pay for Sensei.

Limits, reconnects and provider failures never move work to Free. Connecting the first Subscription moves Free threads to Auto over Subscriptions from their next turn; removing the last moves explicit choices to Free. A running turn keeps its source. When your Subscription cannot run or Free is unavailable, Sensei names the problem. See AI providers.

Send while it works

A message you send in a thread while that thread's reply is running waits in Up next, the list above that thread's composer, and starts the next turn there. Each thread has its own Up next. A message you send on the Sensei page starts a thread and never waits, with Working and a spinner while five threads are already being answered. 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 Sensei 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 every model Sensei runs. If the turn ends before it takes your message, the message goes back to the top of Up next.

The message Sensei sends into a session for an approved card, such as an answer to a question or a Fix, waits in that session's Up next while a turn runs there. Delete it there and its card comes back. Any other message Sensei sends into a session for you steers the turn running there, unless it carries files. When that turn cannot take it, for example because another member started it, the message waits in Up next and Sensei tells you. An Event Turn waits in a thread's Up next behind your messages. While one runs, you can steer a message into it. See Sensei reads the new events.

Pressing Stop in a thread pauses that thread's Up next only. 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. Sensei reads no other file types. Sensei can read a thread's attachments again in its later turns, so you can ask it to send a file you attached earlier. It keeps them for your 20 most recently used threads, until a thread has had no turn for seven days.

Clear or compact a thread

Type / in a thread's composer, with any model, to open the menu. It offers the commands marked Runtime, /clear and /compact. Pick one, or send it as the whole message. With a Codex model, $clear and $compact work too. With a Google model the menu offers /clear only: Gemini models compact by themselves, so a /compact sent anyway leaves a line that says so and changes nothing.

• /clear starts a fresh conversation in that thread. Sensei's next answer there knows nothing said before it, and every other thread keeps its memory. 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. The composer stays open meanwhile: a message you send then waits in Up next and goes when the compaction ends, and nothing steers into a compaction. 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".

The composer on the Sensei page does not offer them, because they act on one thread. A command sent while that thread is being answered, or while another command runs there, waits in Up next and runs when it reaches the top. You can edit, move or delete it there, but not steer it or send it now.

Nothing compacts a thread on its own. A thread is compacted only when you send /compact in it. When the ring by the composer gets close to full, run /compact or /clear. A compaction loses nothing that matters to your queue. What waits on you lives in the app, not in the conversation: cards, their order and their notifications are read fresh on every turn.

Who can see it

Each person has one Sensei. It covers every workspace you belong to, and nothing else. Nobody else can read yours, in the app or through the API, workspace admins included. The files Sensei writes are different: they live in the workspace's Files, where every member of that workspace can read them. You can read your own chat from a terminal with kosuke sensei chat get and your API key. No agent can read the flat chat, Sensei's own credential included. Sensei can read another thread when your answer needs it. Leaving a workspace closes your cards about that workspace and forgets what Sensei knew there. The rest of your Sensei stays.

Every person has Sensei.

What it costs

Sensei uses your selected Subscriptions or Sensei free. Each member or Event Turn on Free spends one prompt from your shared allowance. Its picker shows prompts left; its composer names a pause or empty allowance. The first Subscription connect and last removal move the choice from the next turn; limits and reconnects never move it to Free.

The app picks one Source for each Free Sensei thread Turn, including Event Turns. It works like a personal Subscription within your allowance and the staff maximum Turn Level. When that Source reaches its limit, is paused or is removed, the app moves the work automatically. A running Turn continues on another Source with the same model, at no extra prompt. When none is left, the Turn stops, and the next Turn hands off to another provider. These moves and the model, Source and provider stay hidden. If no eligible Source is available, Free waits until one is.

Workspace sessions Sensei starts or sends into use workspace Credentials only. Personal tasks follow their own selected source. Notifications and merges the app makes for you cost no Sensei Turn.

Sensei runs in a container of its own on the platform's servers, which the platform pays for. It is not on any workspace's Usage or bill, and it needs no credits. The container stays on, so an answer usually starts at once. When it has to be started again, the first answer takes longer, and the transcript reads "Waking Sensei" while you wait. When many people's Sensei are answering at once, yours can wait a moment before it starts. Your own container answers five of your threads at once.

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

Next steps

• Chat sessions and tasks
• Crons
• AI providers

Memory

Sensei reads your private Memory at the start of every turn. It proposes changes as a card you review and approve. You can also edit the three files in Settings > You > Memory.

When you share your location from the iOS app, Sensei also knows where you are, for up to 24 hours after your phone last shared it. See Share your location with Sensei.