How do you decide when a requirement is detailed enough to hand to a delivery team?

1. My test is whether a competent builder could implement it, and a tester could verify it, without needing to ask me a clarifying question.
2. It needs the business context — the “so that” clause — because a builder who understands the intent frequently proposes something better than what was specified.
3. It needs acceptance criteria covering the main path, the significant edge cases, and the relevant personas or profiles.
4. It needs its dependencies and assumptions stated, so nobody discovers mid-build that it relies on something not yet delivered.
5. What it should not contain is the implementation design. Specifying “use a record-triggered flow” removes the team's ability to choose a better mechanism. I describe the required behaviour and leave the how to the people who build it.