Automation Starts With Selection
Switchboard can turn Linear issues into pull requests, but not every issue should enter that lane. The biggest mistake is treating automation as a backlog vacuum. A good automation queue is selective. It contains issues with enough context, tight enough scope, and a review path that a human can evaluate quickly.
This post is about deciding which issues belong on Switchboard before you spend time tuning routes, models, and daemons.
The Best Candidates
Good Switchboard issues usually have five traits:
- The desired behavior is clear.
- The code area is known.
- The change is small or medium sized.
- The acceptance criteria are testable.
- The review risk is manageable.
Examples:
- Fix a broken empty state in a specific page.
- Add logging around a known failure path.
- Update a validation message.
- Add a small endpoint field with existing patterns.
- Write tests for a known regression.
- Update documentation based on a merged feature.
These issues do not require the agent to discover the product strategy. They require it to execute a bounded engineering task.
The Bad Candidates
Some issues should stay manual at first:
- Ambiguous feature requests.
- Cross-team architectural changes.
- Product decisions disguised as engineering tasks.
- Security-sensitive changes without a clear reviewer.
- Database migrations with unclear rollback expectations.
- UI redesigns without screenshots or acceptance criteria.
- Anything that requires a conversation before the first line of code.
An AI agent can help investigate those topics, but that is different from letting Switchboard drive them directly into a pull request.
Use manual Claude Code or Codex sessions for discovery. Once the task is understood, turn the result into a better Linear issue.
A Selection Rubric
Before adding a label or status that Switchboard watches, score the issue:
| Question | Ready signal |
|---|---|
| What repo should change? | One repository is named |
| What files or area are likely involved? | A module, route, page, or package is identified |
| What counts as done? | Acceptance criteria are written |
| How should it be tested? | Test command or manual QA note exists |
| What should not change? | Constraints are explicit |
| Who reviews it? | Reviewer or owner is obvious |
If you cannot answer those questions, the issue is not ready for automation.
Example: Ready
Title: Fix empty state copy in billing history
Repo: app
Area: billing settings page
Goal:
When no invoices exist, show the new empty state copy from the design note.
Acceptance criteria:
- Empty state title matches the issue text.
- Body copy links to pricing.
- Existing invoice table behavior does not change.
- Site typecheck passes.
Review notes:
This is copy and layout only. Do not change billing logic.This issue is bounded. It names the repo, area, outcome, test expectation, and constraint.
Example: Not Ready
Title: Improve billing
Make billing better and easier to understand.That may be a valid product concern, but it is not automation-ready. It needs discovery, product decisions, design context, and probably several smaller issues.
How This Fits Switchboard
Switchboard works best when the issue is clear enough to route. The route can choose the team, repo, daemon, provider, model, branch behavior, and concurrency settings. But routing cannot rescue an unclear issue. A vague issue routed perfectly still produces vague work.
Think of Switchboard as a disciplined execution lane. The work should enter the lane already shaped for implementation and review.
Tradeoffs
Being selective feels slower at first. You may reject issues that look automation-friendly because the context is missing. That is healthy. Automation rewards clarity and punishes ambiguity.
The payoff is a queue where more runs produce useful pull requests, fewer runs stall for missing context, and reviewers spend less time reverse-engineering what the agent was asked to do.
There is also a morale benefit. Teams trust automation more when it succeeds on well-chosen work. A smaller queue with predictable outcomes beats a broad queue that produces confusing branches and review fatigue.
Start Small
Pick one label, one repository, and one issue type. For example: switchboard-ready on low-risk bug fixes in one frontend repo. Run several issues through that lane before expanding.
If you are still deciding between manual and automated workflows, read Manual AI Agent Runs vs Switchboard Automation. If you are ready to use automation, compare the Switchboard plan on the pricing page.