The Contract

The Asana ticket template is the bridge between worlds. Product Owners fill it, Developers consume it.

Unspecified details create ambiguity. Ambiguity creates inconsistency. The ticket template forces explicit decisions — current behavior, desired behavior, testable requirements. The more specific the ticket, the better the blueprint, the better the code.

The Template

Goal

What are we building and why? One clear sentence. If you can't say it in one sentence, the scope is too big — split the ticket.

Bad Example

"Improve the dashboard"

Good Example

"Add a date range filter to the orders dashboard so managers can view sales by period"

Context

Background: Why does this matter? What triggered this work?

Current Behavior

How does the system work today? Be specific — reference pages, buttons, API endpoints, error messages.

Bad Example

"It's slow"

Good Example

"The orders page takes 8 seconds to load when filtering by date range with more than 10,000 orders"

Desired Behavior

Same specificity. Define exactly what should happen.

Bad Example

"Make it faster"

Good Example

"The orders page should load in under 2 seconds regardless of filter or order count"

Requirements

Testable acceptance criteria. Each one must be verifiable — someone should be able to definitively say "yes, this works" or "no, it doesn't."

improve performance
page loads in under 2 seconds on 3G

UI / UX

Filled by the Designer when the ticket goes through the design phase. Covers screens/flows, component choices (referencing existing components by name), and mockup attachments. Marked N/A if no design needed.

Bad Example

"Make it look nice, maybe a modal"

Good Example

"Use the existing DateRangePicker component. Filter appears inline above the table, same layout as the reports page. See attached mockup."

Constraints

Non-negotiable rules. Performance budgets, browser support, backwards compatibility, security requirements.

Must not break existing API contracts — all v1 endpoints remain unchanged
Page must load under 2s on 3G with 10k+ rows
No new dependencies — use existing date-fns library

Open Questions

Anything unresolved. This section MUST be empty before the ticket can move to Ready for Development. This is the hard gate.

Custom Fields

Type
feat | fix | improve | hotfix
Priority
Low | Medium | High | Critical
Status
Draft Refining Ready for Design Designing Ready for Dev In Progress PR Review Ready to Test Testing Done

Quality Gates

At Creation

Claude warns about missing or weak sections but still creates the ticket.

Soft Gate

At Transition

Claude blocks moving to Ready for Design/Developer if: Open Questions is not empty, Goal/Requirements are missing, or Behavior is vague.

Hard Gate

How Each Role Uses CLAUDE

Product Owners

Uses /draft to start drafting a ticket for a feature, bug fix, or improvement. Claude leads the discussion, explores the codebase, and fills every section with references to actual pages, endpoints, and components.

Designers

Fills the UI/UX section. References existing components by name from the codebase. Attaches mockups. Sends back to PO if requirements are unclear.

Developers /scaffold

Parses the template to generate a blueprint. Maps Goal → Blueprint Goal, Context → Blueprint Context, etc. Flags weak sections — developer can proceed or /send-back.

The Contract is a Promise

When the ticket is complete, every role has done their part. The Product Owner defined the problem. The Designer shaped the experience. The Developer knows exactly what to build. No guessing, no assumptions, no back-and-forth.

Clear input

produces clear output

One ticket

one blueprint, one PR

Zero ambiguity

at the point of build