An issue is ready when the implementer can begin without choosing product behavior on the author's behalf. A long description is not enough: “handle errors gracefully” still leaves someone to decide which errors and what the user sees.
Before assigning work, check five things:
- The problem names an affected user or workflow.
- The expected result describes observable behavior.
- Acceptance criteria include a normal case and a relevant failure or boundary case.
- Scope says what will stay outside this change.
- Dependencies and unanswered decisions have an owner.
For a bug, add steps another person can repeat and separate the observed result from the expected result. For an API, define the contract and permissions. For a UI, distinguish loading, empty, error and success states. Use the bug, backend or UI template as a starting point.
SpecBot reviews issue context and returns a readiness result with suggested fixes. Read the findings, confirm what is actually missing, and amend the issue with facts. A READY result does not prove the code is correct or authorize unresolved product decisions.
Install SpecBot in Linear and review one real issue before handoff.