# Linear Bug Repro Pack

> Tests every Linear bug against the four things that make it reproducible, then drafts the exact questions for whatever is missing. Never closes an issue.

- Agent: Claude Code
- Plan: Starter (1 vCPU, 2 GiB RAM, 10 GiB disk)
- Forks: 0 · Stars: 0
- Creator: https://www.jurniti.com/creator-ca0ff2
- Tags: bugs, claude-code, linear, qa, software-factory, triage
- Requires config (you provide): ANTHROPIC_API_KEY
- Skills: linear-bug-repro

**To fork:** open https://www.jurniti.com/templates/linear-bug-repro-pack and use the Fork action — it starts a Stripe Checkout for a new VM seeded with this template's persist disk (same flat plan price, no fork fee).

## README

# "Can't repro" starts the loop again next week

Thirty unstarted bugs. Half of them say some version of "it's broken on my
account". An engineer picks one up, spends forty minutes failing to reproduce it,
comments *can't repro* — and the issue comes back.

## Four things, or it isn't reproducible

Every issue gets tested against exactly these:

1. **Environment** — version/commit, browser or runtime, OS, prod/staging/local.
2. **Preconditions** — the data state required. "Log in" isn't a precondition;
   "log in as a user with an expired trial and 2+ seats" is.
3. **Exact steps** — numbered, one action each, no "then do the usual setup".
4. **Expected vs actual** — both. "It's broken" is neither.

Missing any one and the verdict is `NOT_REPRODUCIBLE_AS_WRITTEN`, naming which.
**That verdict is useful output, not a failure** — it tells the reporter exactly
what to add.

## It never invents a step

If the issue doesn't say which button, you get `[MISSING: which button]` inline —
not a plausible guess. An invented step sends an engineer down the wrong path and
looks authoritative while doing it.

## Then it closes the loop

**Questions for the reporter**, written as real questions. Not "please provide
more detail" but *"which version were you on, and was the trial expired or
active?"*

It reads the comments too, because the missing detail is usually buried in a reply.

## Batch mode gives you the number that fixes your template

Run it over the backlog and the queue summary reports the **single most common
missing field**. If "environment" is absent on 60% of your bugs, that's a template
problem, not a reporter problem.

## What you supply

`LINEAR_API_KEY` (read + comment) and your own Claude Code login. Export them in
your shell — nothing is stored in the template.

## Where this stops

It reads and drafts. It does not close, assign, or re-prioritise issues, and it
only posts a comment when you ask for that specific issue.

Possible duplicates are reported as both ids plus the overlapping symptom — never
marked. It won't give root cause (it reads an issue, not a stack trace in context)
and it won't set severity, because that's a product call.

Verified on build: the skill, the working tree, the `NEVER_CLOSE_OR_ASSIGN` guard,
the four-part test and the never-invent rule are present on a fresh fork, and no
Linear key shape exists in the snapshot. Running it on your own backlog is yours.