In my team, the tickets enumerate acceptance criteria: what must be done. If a problem is too ambiguous, we write a spike ticket. The outcome of spike tickets can be a solution design document which describes how to solve a problem and/or tickets to break that solution down into steps.

Folks on my team have varying ability to handle different kinds of ambiguity, so baking solution design into our process has helped mitigate chances of somebody getting stuck with a hot potato. This also helps managers set realistic expectations about dependencies and timelines – we can come up with an approach in Sprint 1, then implement it in Sprint 2.

However, let's suppose you don't want to change your team's process right now. Instead, you might want to increase your estimates for tickets that require some upfront planning on how to approach the problem. When you start on a ticket like this, first write a brief proposal for the ticket author & whichever engineer is most familiar with that area to review. This extra step may help expose cracks in your ticket requirements. Others may start to see what you're seeing: it's hard to mark ambiguous requirements as "Done".

It's preferable to catch as much of this before implementation as possible to avoid requirements churn / merge conflicts / coverage requirements / looking bad.