Creating Tickets

Otto works best when tickets are clear, specific, and well-structured. The more context you provide up front, the fewer clarification rounds Otto needs and the better the output.

Describe what should happen, not just what's wrong. Instead of "fix the login page," write "the login form should validate email format client-side and show an inline error message below the email field."

Include Acceptance Criteria

List the conditions that define "done." Otto uses these to guide its implementation and verify its own work:

The endpoint returns a 200 with the user's profile data
Invalid tokens return a 401 with a JSON error body
Rate limiting applies after 100 requests per minute

Provide Context and References

Otto performs better when it understands the broader picture:

Link related tickets so Otto can understand dependencies and prior decisions
Reference existing code by mentioning file paths, function names, or modules (e.g., "follow the pattern in src/services/auth.service.ts")
Attach supporting documents such as API specs, flowcharts, or mockups as links or inline descriptions
Mention constraints like "must be backwards-compatible with v2 API clients" or "no new dependencies"

Structure for Clarity

A well-structured ticket typically includes:

Summary - One sentence describing the change
Background - Why this change is needed
Requirements - What specifically needs to happen
Acceptance criteria - How to verify it's done
Technical notes - Any constraints, patterns to follow, or files to reference

Avoid Ambiguity

Otto will ask clarifying questions when requirements are unclear, but you can save time by being precise:

Vague: "Improve the dashboard performance"
Clear: "The dashboard /api/metrics endpoint takes 3s to respond. Add Redis caching with a 5-minute TTL for the aggregated metrics query"

Setting Up Intake Workflows

Otto can automatically pick up tickets filed by other teams, making it ideal for handling cross-functional requests without pulling engineers away from focused work.

Linear Asks

Linear Asks lets non-engineering teams submit requests that land in your triage queue. Combined with Otto, this creates a fully automated intake pipeline:

Set up a Linear Ask form for your team (e.g., "Engineering Request")
Configure the form fields to capture the information Otto needs (description, priority, affected area)
Route submissions to a triage project or label (e.g., intake or support-request)
Create an Otto integration rule that matches on the triage label or project
Set the trigger to fire when the ticket status changes to "Todo"

Now when a marketing manager submits a website copy change or a support agent files a bug report, Otto automatically picks it up, clarifies requirements, and delivers a pull request for an engineer to review.

Jira Intake with Service Desk

Jira Service Management provides a similar intake workflow:

Create a Jira Service Desk project or request type for external team submissions
Define required fields that map to the information Otto needs
Set up an automation rule in Jira to move approved requests to your engineering project
Configure an Otto integration rule that matches on the project or label
Set the trigger to fire when the issue transitions to your team's backlog

Best Practices for Intake Workflows

Template your request forms so non-technical team members provide the right level of detail
Include a "technical notes" field where the submitter can add any relevant context
Use labels to categorize incoming requests (e.g., bug, copy-change, feature-request) so you can route different types to different Otto agents
Set up a QA agent to automatically review Otto's pull requests before they reach an engineer
Keep a human in the loop for review and merge, especially for requests from non-engineering teams