ticket-triage

What this skill does

# Ticket Triage

Evaluate a single ticket against six readiness criteria and produce a clear verdict with actionable remediation guidance.

## How to Get the Ticket

The user might provide the ticket in several ways. Adapt accordingly:

- **Pasted in the prompt**: The ticket text is right there. Use it directly.
- **File path**: Read the file.
- **Jira / Linear / GitHub Issue / other tracker**: If MCP tools are available for the tracker, use them to fetch the ticket. If not, ask the user to paste the content.
- **Multiple tickets**: If given multiple tickets, evaluate each one separately and produce a per-ticket assessment. Do not batch them into a single verdict.

If the ticket content is ambiguous or incomplete (e.g., just a title with no description), note that in your assessment but still evaluate what's there.

## Evaluation Posture

Before diving into the criteria, understand the right mindset for this evaluation. The question you are answering is: **"Could a developer pick up this ticket and build the right thing without needing to ask clarifying questions?"**

You are not looking for perfection. You are looking for sufficiency. A ticket with slightly informal language that nonetheless communicates the expected behavior clearly is FINE. Only fail a criterion when the gap would genuinely cause a developer to build the wrong thing, miss an important behavior, or be unable to verify their work.

When in doubt, pass the criterion and note an optional improvement. Reserve failures for genuine problems that would block development or lead to incorrect implementations.

## The Six Readiness Criteria

A ticket is **Ready for Development** only if it passes ALL six criteria. Failing even one makes it not ready.

### 1. Specific Acceptance Criteria

The ACs must communicate what the feature does concretely enough that a developer knows what to build. They should describe behaviors, not just restate the feature name.

**Passes**: "Dragging changes order in the UI" -- a developer knows what to implement: drag interaction that visually reorders items

**Passes**: "When a user submits a task with a title shorter than 3 characters, a validation error appears below the title field" -- very precise and detailed

**Fails**: "User can create a task" -- this is a feature summary, not an AC. It says nothing about what creating a task involves, what fields are shown, or what happens after creation

**Fails**: "Validation errors are displayed on the form" -- which errors? for which fields? where on the form?

The bar is "would a developer know what to build?" not "is every edge case documented?" ACs that clearly communicate the expected behavior pass even if they could be more detailed.

### 2. Appropriately Sliced

The ticket is a single, deliverable unit of work. Not an epic disguised as a story, nor an artificial slice that separates tightly coupled concerns (like creating a model in one ticket and adding its validations in another).

**Passes**: "Add drag-and-drop reordering to the task list" -- single feature, clear scope

**Fails**: "Build import and export functionality" -- two distinct features with different complexity

Red flags: 3+ distinct capabilities listed, "and" in the title joining unrelated concerns, question marks in the description suggesting the scope isn't decided.

### 3. Verifiable and Specific ACs

Each AC must be testable -- a QA engineer could determine pass or fail from the AC text. The key question is whether the AC contains subjective language that makes the pass/fail determination a matter of opinion.

**Passes**: "Order persists after page refresh" -- clear test: reorder, refresh, check

**Passes**: "A user only sees their own tasks" -- clear test: log in as user A, verify user B's tasks are not visible

**Fails**: "Query is reasonably performant with large data sets" -- "reasonably" is subjective, "large" is undefined

**Fails**: "Users perceive the app as more powerful" -- entirely subjective, no way to test

Subjective red-flag words that typically cause failures: "appropriately", "reasonably", "correctly", "clearly", "feels", "perceived", "intuitive", "meaningful". However, context matters -- "User can toggle theme" is fine even though "toggle" is slightly informal, because the behavior is obvious.

### 4. User-Verifiable Through the UI

The ticket as a whole must be verifiable by a user interacting with the application. Evaluate this at the **ticket level**, not per-AC.

**Passes**: A ticket where the core behavior is user-facing, even if one AC mentions an implementation detail. For example, if a ticket has 3 ACs and two describe UI behavior while one says "foreign key relationship exists", the ticket passes -- it IS user-verifiable. The implementation AC is a style issue to note as an optional improvement, not a criterion failure. If even ONE AC describes a user-observable behavior, the ticket passes this criterion.

**Fails**: A ticket where ALL ACs describe implementation details ("foreign key exists", "data is stored in the database", "migrations run successfully") with no user-observable behavior at all.

The question is: "Can a user verify this ticket is done by using the app?" If yes, it passes. Period.

### 5. Not Infrastructure-Only

The ticket delivers value that a user of the application can experience. Pure infrastructure, tooling, or devops tickets should be typed as "Chores" or "Tasks", not "Stories."

**Passes**: "User can see a task list page after the app starts" -- infrastructure + user value combined

**Fails**: "Docker Compose starts the app and database is reachable from Rails" -- developer/infra value only

Infrastructure work is necessary and valid. The criterion is about typing and framing, not dismissing the work. If a ticket is purely infrastructure, recommend reclassifying it as a Chore or merging it with a user-facing ticket so they ship together.

### 6. Validation Criteria for Data Models

This criterion applies when a ticket **introduces a new data model** (a new database table / entity) or **adds user-facing fields** to an existing model. When it applies, every user-facing field must have explicit validation rules: type, required/optional, min/max length or value, format, allowed values, default value.

**Passes**: A ticket that includes something like:

| Field | Type | Required | Constraints | Default |
|-------|------|----------|-------------|---------|
| title | string | Yes | Min 3 chars, max 255 chars | -- |
| status | enum | Yes | pending, in_progress, completed, archived | pending |

**Fails**: "Each task has: Title (string), Description (text), Status, Due date" -- field names and rough types but no validation rules

**N/A -- mark as Pass**: When the ticket does NOT introduce a new data model. Specifically:
- Adding a foreign key for a relationship (e.g., adding `user_id` to tasks) is a relationship change, not a new data model. Pass.
- Using fields that already exist on an established model (e.g., reordering tasks using a `position` field introduced in an earlier ticket) is not introducing new fields. Pass.
- Pure UI changes, behavioral changes, or features that don't touch data models. Pass.

The criterion only triggers when the ticket says something like "create a Comment model" or "each task should have: [list of new fields]" -- i.e., the ticket is defining what data gets stored and the developer needs to know the validation rules to build the forms and model correctly.

Watch for: tickets that mention data fields in the description but have no validation section, enum fields that list values without specifying the default, and fields whose validation rules are defined in a different ticket (this means the ticket isn't self-contained).

## Evaluation Process

For each ticket:

1. **Identify the ticket metadata**: title, type, priority (if available)
2. **Evaluate each criterion**: Determine pass/fail with specific reasoning that references the actual ticket text
3. **Determine the