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. Routing labels (highest priority)
  2. Linear team configuration (fallback)
If a routing label is present, it always wins.

Split Work Within a Team Using Labels

This is the most common setup.
Team: ENGINEERING
Labels:
  frontend → frontend-app repository
  backend  → backend-api repository
  mobile   → mobile-app repository
This allows one Linear team to ship to multiple codebases without ambiguity.

When to Use Label-Based Routing

Use routing labels when:
  • A team owns multiple repositories
  • You use a monorepo with distinct domains
  • You want explicit, predictable routing
Use team-based routing when:
  • Each team owns a single repository
  • Simplicity matters more than precision

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:
Bug
Hotfix
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:
Feature
Improvement
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:
Orchestrator
Epic
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:
Graphite
Orchestrator
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

Sonnet → Balanced performance (default)
Opus   → Highest capability
Haiku  → Fast and cost-efficient

When to Override

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 Sonnet.

Practical Examples

Bug Fix

Title: Login button not responding on mobile
Labels: Bug
Team: FRONTEND
→ Debugger workflow
→ Targeted fix with tests

New Feature

Title: Add dark mode toggle
Labels: Feature
Team: FRONTEND
→ Builder workflow
→ Full implementation and verification

Large Feature

Title: Implement complete authentication system
Labels: Orchestrator, Epic
Team: BACKEND
→ Work decomposed into sub-issues
→ Coordinated execution

Incremental Refactor

Title: Refactor database layer
Labels: Graphite, Orchestrator
Team: BACKEND
→ 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?

Cyrus follows deterministic internal workflows to ensure consistency. If you want to understand those workflows in detail: → Procedure Reference fOjhOFI

Cyrus Community

Get support on Discord