Tenbi Docs

Appearance

Projects ​

A project is the unit of work in Tenbi. It owns everything the work is about:

  • a ticketing destination — where its tickets live: an external tracker (GitHub Issues, Jira, Shortcut) or Tenbi's own built-in tracker, Tenbi Tickets. The Composer files into it, and it's the default every lane polls (a lane can override its own connection);
  • a repo registry — the repositories runs work in, each with its clone URL, workspace role, base branch, and Version Control connection;
  • its settings — models, protected paths, messaging, overlap awareness, and the Composer's templates and skills.

Inside a project, lanes are its pickup rules — each one decides when a ticket is handed to the agents and how that run behaves. And the project's Compose board is where rough ideas become well-formed tickets before any agent touches them.

Open Projects in the sidebar to see them all: each row shows the owning team, its ticketing destination, its lane count, and its connections. Click a project to land on its board.

The tabs ​

TabWhat it holds
ComposeThe drafting board: your ideas on the left, AI-written tickets on the right — Draft → Refine → Filed
TicketsThe built-in tracker's ticket list (projects on Tenbi Tickets only — external projects' tickets live in their tracker)
LanesThe project's pickup rules — see Lanes
RunsEvery run this project's lanes have produced, filterable and searchable
SettingsEverything below

Creating a project ​

Projects → New Project. Two decisions up front:

  • Name — for internal-tracker projects this also derives the ticket key prefix (a project named "Core app" numbers its tickets CORE-1, CORE-2, …). The prefix freezes once the first ticket exists.
  • Ticketing — Tenbi Tickets (the built-in tracker: zero external setup, tickets live in the project's Tickets tab), an external connection (pick or create a Jira / GitHub / Shortcut connection and its destination — a Jira project key, a Shortcut workflow). A project always has a destination — it's what the Composer files into and what the project's lanes poll.

Everything else lives in Settings after creation.

Settings ​

Repositories ​

The project's repo registry — the single source of repos for every lane in the project. One Version Control connection serves the whole registry. Each repo row: a name (the tracker-style owner/repo form — the clone URL derives itself) and an optional base branch, with Verify (checks the repo really exists through the connection and fills in the default branch if you left it empty) and Run indexer (builds the repo's curated .agent/ guide through one of the project's lanes). Under Advanced: the clone URL (blank = derived), the role — the folder the repo lands in inside the agent's workspace; give multi-repo projects distinct roles like frontend/backend — and a per-repo connection override for the rare repo that lives on a different host. A repo referenced by a lane can't be removed until that lane lets go of it.

Protected paths live here too: path prefixes runs may not change without the ticket carrying the allow-protected-paths label. Empty inherits the platform default (.github/workflows/). Applies to every lane in the project.

Models ​

  • Run model & reasoning effort — defaults for every run in this project. A lane's own override still wins; blank inherits the workspace base (Workspace → Settings → Models). Resolution order: ticket-type routing → lane → project → workspace → platform, and every run records which level decided.
  • Ticket-writing model — which Claude model the Composer drafts tickets with; blank inherits the workspace ticket-writing default, then the platform default. Separate from the run model on purpose: the model that writes the best tickets isn't always the one you want burning run tokens.

Operations ​

Applies to every lane in the project:

  • Overlap awareness — the PR merge-probe and planning-time exposure toggles; see When Work Overlaps.
  • Hosted repo optimization — pre-digested codebase maps and guides; the on/off switch is here, while index status and the Rebuild / Run indexer buttons live on each lane's form, scoped to that lane's repo selection. See Optimize.
  • Messaging connections — Discord / Slack / Microsoft Teams pings, with per-channel hooks: choose which of PR-opened, run-failed, and overlap-detected each channel receives.

Deleting a project ​

Deleting a project deletes everything inside it — its lanes, its Tenbi tickets, the Compose board's drafts, and its Tenbi Tickets connection — and the confirmation names exactly what will go. Run history is kept: past runs stay on the Dashboard, marked as belonging to a deleted project.

Composer ​

  • Default template — the ticket shape (feature / bug / chore / refactor) new drafts start from; each draft can override it.
  • Compose skills — library skills the ticket-writer consults: style guides, domain vocabulary, house conventions. Additive guidance — it sharpens tickets but never overrides the template contract, and the writer still refuses to invent facts about your code it can't know.

The Compose board ​

Three columns, one journey:

  • Draft — your words, exactly as captured. The AI has not read them; nothing here spends tokens. Refine with AI is the hand-off — an explicit consent moment, never automatic.
  • Refine — the AI writes a full, template-shaped ticket from your words and asks targeted questions where the input can't answer them. It's a conversation: reply to steer, hand-edit the ticket directly (your version becomes the new baseline), or accept a split when one idea is really several tickets — split parts render as a single stacked card until you review the batch.
  • Filed — the ticket now exists at the project's destination. The card is a reference, not a copy: the tracker owns the ticket from here. On Tenbi Tickets, Mark ready on a filed ticket is what releases it to the lanes.

Filing a ticket does not run it. The ticket still needs its ready label or status — the same human gate every ticket passes — before a lane picks it up. Compose upstream, orchestrate downstream, a person in between.

Tenbi Tickets — the built-in tracker ​

For teams without an external tracker, a project on Tenbi Tickets is self-contained: tickets live in the Tickets tab with states, labels, and comments; the Composer files into it; lanes poll it exactly like an external tracker — the ready label is still the gate. Each ticket carries an activity trail, and the orchestrator's own label changes appear there as "Tenbi", so a run's whole journey reads off the ticket.

It is deliberately small — tickets, labels, comments. It's the loop's ticket store, not a replacement for Jira.

Connections ​

A connection is a tenant-level registry entry for an external service — a Jira site, a GitHub app, a Teams webhook — with credentials attached separately. Projects bind connections (the ticketing destination, each repo's Version Control, messaging); they never hold secrets themselves. You'll rarely visit the registry: a New connection shortcut sits beside every connection picker in project Settings (it opens the connection form in a new tab — press the refresh button beside the picker when you're done), and the connection lands in the shared registry so your next project finds it already there. The full registry — every kind, tabbed — lives under Workspace → Connections, visible to everyone; what each person sees follows their team. Details: Connections.