Skip to main content
Labels are the primary way you control where Cyrus works and how it approaches a task. Use this page to decide which labels to apply to a Linear issue based on the outcome you want.

​
What labels control

Labels influence Cyrus’s behavior in the following order:
  1. Repository routing – where the work happens
  2. Work approach – how Cyrus reasons and executes
  3. Model selection (optional) – which AI model is used
If labels are missing or ambiguous, Cyrus falls back to safe defaults.

​
Route issues to the right repository

Labels allow you to route issues more precisely than team-based routing alone.

​
Routing priority

Cyrus applies routing rules in this order:
  1. Description tag — [repo=...] or repos=... in the issue description (highest)
  2. Routing labels — labels mapped to repositories
  3. Project assignment — Linear project mapped to a repository
  4. Team selection — the issue’s Linear team (lowest)
Higher-priority signals always override lower-priority ones.

​
Route with a description tag

The most explicit way to target a repository is to add an inline tag to the issue description:
The tag can appear anywhere in the description. Cyrus also accepts the unbracketed form:

​
Override the base branch

Append #branch-name to check out from a branch other than the repository’s default:
This is useful for stacked work or for branching from a release branch.

​
Route to multiple repositories

A single issue can fan out to several repositories. Cyrus will create a separate worktree and agent session for each target. There are three equivalent ways to do this. Multiple description tags:
Comma-separated list:
Multiple routing labels: Apply more than one routing label to the issue. Each label that maps to a repository will trigger a session in that repository.
Per-target base branch overrides work the same way:

​
Split work within a team using labels

This is the most common setup.
This allows one Linear team to ship to multiple codebases without ambiguity.

​
When to use each style

Use a description tag when:
  • You want one-off, explicit routing for a specific issue
  • You need to override the base branch
  • You want the issue to fan out to multiple repos without managing labels
Use routing labels when:
  • A team owns multiple repositories with stable, recurring routing
  • You use a monorepo with distinct domains
  • You want routing to be visible at a glance from the Linear board
Use team-based routing when:
  • Each team owns a single repository
  • Simplicity matters more than precision

​
Worked example: one issue → frontend + backend

A team owns both a frontend-app and a backend-api repository, and an issue requires changes to both.
Cyrus will:
  • Open a worktree in frontend-app from its default branch
  • Open a worktree in backend-api from main
  • Run an agent session in each, posting progress back to the same Linear issue
The same fan-out happens if you instead apply both the frontend and backend routing labels.

​
Choose how Cyrus approaches the work

Different tasks require different approaches. Labels tell Cyrus how to reason about the issue before writing code.

​
Fix a bug

Use when: Something is broken or incorrect Labels:
Cyrus will:
  • Investigate the root cause
  • Make minimal, targeted fixes
  • Add test coverage where appropriate
→ Uses the debugger workflow

​
Build or improve something

Use when: Adding features or improving existing behavior Labels:
Cyrus will:
  • Follow existing code patterns
  • Implement fully scoped changes
  • Verify before opening a pull request
→ Uses the builder workflow

​
Coordinate large or multi-part work

Use when: The task is too large for a single pass Labels:
Cyrus will:
  • Break work into smaller sub-issues
  • Coordinate execution across them
  • Track overall progress
→ Uses the orchestrator workflow

​
Large work with stacked pull requests

Use when: Each step depends on the previous one Labels:
Cyrus will:
  • Create stacked pull requests
  • Execute work sequentially
  • Respect dependency order
Requirement: Graphite CLI must be installed

​
(Optional) Override the AI model

In most cases, Cyrus selects the right model automatically. You can override this behavior with labels.

​
Available model labels

​
When to override

Use Fable for:
  • The hardest problems where capability matters most
  • Trying Anthropic’s latest model on a single issue — add the fable label before assigning the issue to Cyrus
Use Opus for:
  • Complex architectural decisions
  • Critical bug fixes
  • Difficult debugging scenarios
Use Haiku for:
  • Small changes
  • Documentation updates
  • Quick tasks
If no model label is present, Cyrus uses your team’s default Claude model — Opus unless you’ve changed it in Behaviours settings, where you can also select Fable as the default.

​
Practical examples

​
Bug fix

→ Debugger workflow
→ Targeted fix with tests

​
New feature

→ Builder workflow
→ Full implementation and verification

​
Large feature

→ Work decomposed into sub-issues
→ Coordinated execution

​
Incremental refactor

→ Stacked PRs using Graphite

​
If something feels wrong

If Cyrus:
  • Picked the wrong repository
  • Used the wrong approach
  • Did less (or more) than expected
Check:
  1. Label spelling
  2. Routing priority
  3. Missing intent labels
→ See Troubleshooting

​
Want to go deeper?

To customize how Cyrus approaches work — review checklists, deploy runbooks, team playbooks — see Skills. Skills can be scoped by repository, Linear team, or Linear label. For historical context on the rigid workflow Skills replaced, see the Procedure Reference.
cyrus-f1

Cyrus Community

Get support on Discord