Skip to main content

Documentation Index

Fetch the complete documentation index at: https://atcyrus.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Skills are the primary way you customize how Cyrus works. A skill is a small, focused capability the agent loads on demand: a review checklist, a deploy runbook, a triage flow, a design QA pass. Cyrus discovers skills at the start of a session, decides which ones are relevant, and pulls them into context only when needed. Skills replaced the rigid procedure workflow in v0.2.41. The agent still ships PRs, posts summaries, and runs verification. What changed is that how it approaches a task is now legible, editable, and yours.

​
What Skills Are

A skill is a Markdown file (SKILL.md) with a clear trigger (“when to use this”) and a focused body (instructions, examples, things to avoid). The agent treats them like a reference shelf:
  • Discoverable. Every skill is listed at the start of the session by name and one-line description.
  • Loaded on demand. Only the skill bodies relevant to the current task enter the context window.
  • Composable. A single session can pull in several skills (for example, a review checklist plus a deploy runbook).
  • Scoped. A skill can be restricted to specific repositories, Linear teams, or Linear labels.
If you have ever wished you could write down “the way our team does X” once and have the agent actually follow it, skills are that layer.

​
Where Skills Come From

Cyrus loads skills from two sources:
  1. Curated skills. Installed from the Skills page in the Cyrus dashboard. Maintained by the Cyrus team and updated automatically.
  2. Custom skills. Added through the Skills page in the dashboard. Synced to the agent’s runtime on every change.
Both sources are merged at runtime. A custom skill with the same name as a curated one wins.

​
Installing Curated Skills

The fastest way to extend Cyrus is from the dashboard.
The Skills page in the Cyrus dashboard, showing curated skills grouped by category with one-click install.
  1. Open the Skills page in the dashboard.
  2. Browse the curated catalog. Skills are grouped by category:
    • Development. Code review, refactoring patterns, test authoring.
    • DevOps. Deploy runbooks, infrastructure changes, rollback procedures.
    • Security. Threat-model checklists, dependency-patching practices.
    • Design. Design QA passes, accessibility reviews.
    • And more, added as the catalog grows.
  3. Click Install on any skill. You’ll be asked to choose where the skill should be active.

​
Choose Where the Skill Applies

When you install a curated skill, you pick its routing up front across three tabs:
  • Repos. Restrict the skill to specific repositories.
  • Teams. Restrict the skill to specific Linear teams.
  • Labels. Restrict the skill to specific Linear labels.
You can tick selections across all three tabs. The skill will only load when every populated dimension matches the current session (see Scoping Skills for the full logic). Then choose how to install:
  • Install globally. Skip scoping. The skill loads on every session.
  • Add to selected. Install only against the rows you ticked.

​
Managing and Removing an Installed Skill

Once a skill is installed, its tile shows a Manage button instead of Install. Click it to open a menu with three options:
  • Manage scope. Re-open the routing picker to add or remove repos, teams, or labels.
  • View details. Inspect the skill’s SKILL.md body and metadata.
  • Remove. Uninstall the skill. The agent stops loading it on the next session.
Curated skills are read-only. If you want to tweak one, fork it as a custom skill.

​
Adding a Custom Skill

On the Skills page, find the Custom skill tile (the one with the wand icon) and click Add custom skill.

​
Fill In Three Fields

The form has three required fields:
  • Name. Lowercase letters, numbers, hyphens, and underscores only. Shows up on the skill’s tile and in logs.
  • Description. One line. This is what the agent reads when deciding whether to load the skill, so make the trigger condition explicit (“use when…”, “before doing X…”).
  • Instructions. Markdown body of the skill. Only loaded into context when the agent decides the skill is relevant. This is where the actual checklist, runbook, or guidance lives.
Click Add skill to save.

​
Pick a Scope

After saving, you’re asked where the new skill should apply. The picker has the same three tabs as the curated install flow:
  • Repos. Restrict to specific repositories.
  • Teams. Restrict to specific Linear teams.
  • Labels. Restrict to specific Linear labels.
Then choose how to install:
  • Apply globally. The skill loads on every session.
  • Add to selected. Restrict to the rows you ticked.
You can change the scope later through the skill’s Manage menu.

​
Worked Example: A Team Playbook Skill

A backend team wants Cyrus to follow the same review checklist a senior engineer would apply before approving a PR. They’d fill the form like this:
  • Name: backend-review-checklist
  • Description: Use during full-development sessions on the api repo before opening the PR.
  • Instructions: 
    # Backend Review Checklist

Before opening the PR, verify each of these. If any fail, fix or call them
out in the PR description.

## API surface

- Any new endpoint has a corresponding entry in `docs/openapi.yaml`.
- Breaking changes are flagged with the `breaking-change` label on the PR.

## Data access

- New queries use the repository layer in `src/db/`, never raw SQL in
  handlers.
- N+1 risks: any loop that calls `findOne` should be a `findMany` instead.

## Tests

- Integration tests hit a real Postgres (the `testcontainers` setup), not
  mocks. We had a migration regression last quarter when mocks diverged.
- Failure paths have at least one assertion.
After clicking Add skill, scope it to the api repo. The next time Cyrus runs a full-development session there, it will load and follow the checklist automatically.

​
Scoping Skills

By default, every skill is available to every session. Scoping lets you restrict a skill to specific contexts so the agent only sees it where it makes sense.

​
What You Can Scope By

A skill can be restricted along three dimensions:
  • Repositories. Only load when the agent is working in matching repos.
  • Linear teams. Only load when the issue belongs to matching teams.
  • Linear labels. Only load when the issue carries matching labels.

​
How the Logic Works

  • Across dimensions: AND. Every populated dimension must match. If a skill is scoped to repo api and label release, it loads only when both are true.
  • Within a dimension: OR. Multiple entries in the same list are alternatives. Teams [BACKEND, INFRA] means “either team is fine.”

​
Scoping From the Dashboard

You always pick a scope when you install a skill, either Apply globally or Add to selected with specific repos, teams, or labels ticked. To change the scope of an already-installed skill, go to its tile on the Skills page, click Manage, then Manage scope in the menu that appears. The same Repos / Teams / Labels picker opens; adjust your selections and save.

​
Worked Example: Scoping by Repo + Label

You maintain both a frontend-app and a backend-api. You want a frontend-specific accessibility checklist to load only for frontend work tagged as a Feature. On the skill’s Manage scope picker, tick frontend-app under Repos and Feature under Labels, then click Add to selected. From then on:
  • A Feature issue routed to frontend-app → checklist loads.
  • A Feature issue routed to backend-api → checklist does not load.
  • A Bug issue routed to frontend-app → checklist does not load.

​
Authoring Guidelines

The agent has limited attention. A good skill earns its place. Make the trigger explicit. The description is what the agent reads to decide whether to load the body. “Use during full-development on the api/ repo before opening the PR” is loadable. “Helpful tips” is not. Keep the scope focused. One skill per playbook. If your SKILL.md is a kitchen sink of unrelated rules, the agent will struggle to apply them. Split it. Show, don’t lecture. Concrete examples (“queries go through src/db/, not raw SQL in handlers”) beat abstract principles. Where possible, include a snippet of good and bad. Encode the why. “Integration tests must use real Postgres; mocks masked a migration bug last quarter” is far more useful than “use real Postgres.” Reasons let the agent generalize. Trim aggressively. Every line in the body costs context. If a sentence doesn’t change behavior, cut it. Test on a real issue. Apply the relevant scope, run a session against a sample issue, and read the agent’s plan. If it didn’t pick up the skill, tighten the description.
cyrus-f1

Cyrus Community

Share skills and get help authoring them on Discord