Skip to main content
Most users will never need this page. Use it when:
  • You want to understand Cyrus’s internal workflow
  • You are debugging unexpected behavior
  • You are contributing to or extending Cyrus
Procedures are not configuration knobs. They are deterministic workflows selected automatically based on issue intent.

​
What Is a Procedure?

A procedure is a structured sequence of steps Cyrus follows to complete a task. Each procedure is optimized for a specific type of work to ensure:
  • Predictable behavior
  • Consistent quality
  • Safe execution
Procedures are selected automatically based on labels and issue content.

​
Procedure Structure

Most procedures follow the same high-level structure:
  1. Primary Phase
    Core work such as investigation, implementation, or planning
  2. Verification Phase (when applicable)
    Testing, validation, or checks
  3. Git Phase (when applicable)
    Committing changes and creating pull requests
  4. Summary Phase
    Posting results back to Linear
Not all procedures include every phase.

​
Available Procedures

​
simple-question

Purpose:
Answer questions without modifying code Typical Use Cases:
  • Codebase questions
  • Clarification requests
  • Information lookup
Behavior:
  • Reads relevant files
  • Gathers context
  • Posts an answer in Linear
Output:
Linear comment only (no PR)

​
documentation-edit

Purpose:
Update documentation or markdown files Typical Use Cases:
  • README updates
  • Documentation fixes
  • Markdown changes
Behavior:
  • Applies documentation edits
  • Commits changes
  • Opens a pull request
Output:
Pull request with documentation changes

​
full-development

Purpose:
Implement code changes with full verification Typical Use Cases:
  • New features
  • Enhancements
  • Refactoring
Behavior:
  • Implements changes following existing patterns
  • Runs tests and checks
  • Opens a pull request
Output:
Pull request with verified code changes

​
debugger-full

Purpose:
Systematic bug investigation and fixing Typical Use Cases:
  • Bug reports
  • Production issues
  • Test failures
Behavior:
  • Reproduces the issue
  • Identifies root cause
  • Applies minimal fix
  • Adds test coverage
  • Verifies behavior
Output:
Pull request with fix and tests

​
orchestrator-full

Purpose:
Coordinate large or multi-part work Typical Use Cases:
  • Large features
  • Complex refactors
  • Multi-component changes
Behavior:
  • Breaks work into sub-issues
  • Coordinates execution
  • Verifies completion
Output:
Multiple related issues and pull requests

​
plan-mode

Purpose:
Clarify requirements or produce an implementation plan Typical Use Cases:
  • Vague requests
  • Ambiguous scope
  • Multiple possible approaches
Behavior:
  • Analyzes the request
  • Produces clarifying questions or a plan
Output:
Linear comment with questions or plan (no PR)

​
How Procedures Are Selected

Procedure selection follows this priority:
  1. Explicit intent labels (e.g., Bug, Feature, Orchestrator)
  2. Issue content classification
  3. Safe defaults
Users cannot manually select procedures.

​
Important Notes

  • Procedures may evolve over time
  • Names and steps are internal implementation details
  • Rely on labels and intent, not procedure names
If behavior feels incorrect, review:
  • Issue labels
  • Issue clarity
  • Routing configuration