# Jira ticket scorer

Score a ticket **before** it is estimated, so the team argues about the work, not about what the words mean.

## When to use
- As a step in a pipeline: new ticket → score → route to refinement or back to the reporter.
- Standalone in Claude Code: paste the ticket, get the score and the rewrite.
- On a schedule via the API, sweeping everything created since the last run.

## Input
The ticket's title, description, acceptance criteria (if any), labels and linked issues. Comments are optional; when present, treat the newest comment as the current truth.

## Rubric
Score three dimensions from 1 to 5. Do not average them — report each.

**Clarity** — Could an engineer who has never seen this codebase start without asking a question?
- 5: user, trigger, expected outcome and out-of-scope are all explicit.
- 3: the goal is clear, the boundary is not.
- 1: a title and a sentence.

**Scope** — Is this one deliverable?
- 5: one change, one owner, one way to verify.
- 3: two or three related changes that could ship separately.
- 1: a project wearing a ticket's clothes.

**Effort signal** — Does the ticket contain what estimation needs (affected components, data, dependencies)?
- 5: components named, edge cases listed, dependencies linked.
- 1: nothing to estimate from.

## Rules
- Never invent acceptance criteria that are not in the ticket. Propose them, and label the proposal.
- Flag anything you could not verify instead of guessing. "The reporter probably means…" is a flag, not a fact.
- Subtasks inherit their parent's context: score them against the parent's goal, not in isolation.
- Story points already on the ticket are not evidence of clarity. Ignore them for scoring; mention them only if they contradict the effort signal.
- Keep the rewrite in the reporter's voice. You are tightening, not redesigning the feature.

## Output format
```
## Result
- **Clarity:** 3 — goal clear, boundary missing (what happens for guest users?)
- **Scope:** 2 — contains a migration and a UI change that can ship separately
- **Effort signal:** 4 — components named, no data volume given
- **Flags:** "as before" refers to behavior not described anywhere; linked PROJ-812 is closed
- **Suggested rewrite:** only when any score is ≤ 2
```
Keep the whole result under 200 words. One ticket, one result.

## Edge cases
- Bug tickets: Clarity means reproduction steps + expected vs. actual. Missing repro caps Clarity at 2.
- Spikes and research tickets: Scope is judged by the question, not by deliverables; a spike without a timebox caps Scope at 3.
- Empty description with a good title: score it, do not refuse. The rewrite is the deliverable.

## License
MIT