SpecBot is a Linear integration that checks issue readiness before implementation. It scores the context available, flags missing information, and helps teams improve issues before humans or coding agents start work.

SpecBot is for product teams, engineering managers, and AI-assisted delivery teams that want clearer tickets, better acceptance criteria, and less rework during implementation.

What does SpecBot check?

SpecBot checks problem clarity, expected behavior, acceptance criteria, edge cases, technical context, dependencies, reproduction steps, and scope clarity.

Reproducible bug: a Linear issue template

Copy a practical issue template with a weak example, corrected example and handoff checklist.

Copy the template below into a Linear issue description or your team's saved issue template. Replace bracketed prompts and remove irrelevant sections. Examples are synthetic teaching fixtures, not observed product incidents. The corrected example illustrates a more complete draft; unresolved owner decisions still need answers.

Copyable template

# [Specific change and affected flow]

## Problem
[Who is affected, what happens now, and why change it?]

## Expected behavior
[Observable result; record decisions and unresolved questions explicitly.]

## Acceptance criteria
- [ ] [Given a state, when an action happens, then an observable result follows.]
- [ ] [Boundary or failure behavior.]

## Scope and context
[Relevant service/component; in scope; out of scope; dependencies and owner.]

## Verification
[How to check success; safe fixtures; expected results.]

## Reproduction
[Environment/build; safe test data; numbered steps; actual vs expected; frequency.]

Weak example

Fix login bug

Users say login is broken. Need a fix soon.

Corrected example

# Password reset link expires before its advertised lifetime

## Problem and environment
Synthetic example: on staging build demo-42, Chrome desktop, a test account cannot reset its password using a link opened two minutes after delivery. The email promises a 30-minute lifetime. Reproduction frequency: 3/3 in this example.

## Reproduction steps
1. Request a reset for a seeded test account at 10:00 UTC.
2. Open only the newest email at 10:02 UTC.
3. Enter a new password that meets the displayed policy and submit.
Actual: the page says “Link expired”; the password remains unchanged.
Expected: an unused link younger than 30 minutes permits one password change.

## Acceptance criteria
- [ ] An unused link aged 29 minutes succeeds and the new password permits login.
- [ ] At 30 minutes or later, the link is rejected and the password stays unchanged.
- [ ] A successfully used link cannot be reused.
- [ ] Invalid or expired links show a request-new-link action without revealing account existence.
- [ ] Regression coverage uses a controlled clock for both sides of the expiry boundary.

## Scope and technical context
Investigate the reset-token expiry comparison in the authentication service and email lifetime text. Preserve the existing password policy; signup and session expiry are out of scope. No new dependency is expected; confirm the actual service path before implementation. Attach sanitized timestamps, never reset tokens.

## Verification
Run reset-flow regression checks in staging; record results on this issue. The owner must confirm the intended 30-minute rule before implementation.

Before handoff

[ ] Can another person reproduce it with a safe test account?
[ ] Are actual and expected behavior distinct?
[ ] Are environment, frequency and boundary conditions included?
[ ] Do checks prove the defect is fixed without exposing secrets?

What SpecBot contributes

SpecBot can flag missing reproduction context, expected behavior and testable outcomes. It cannot reproduce the bug or confirm the root cause. A score is advisory, not proof that implementation will succeed. Correct the issue using facts the owner confirms, then review it again if your workspace allows rechecks. Rechecks use the shared monthly allowance.

Install SpecBot in Linear to review your next issue. No meeting or demo required. Review the workspace settings after installation; automatic comments may be enabled.