Breaking down and Fleshing Out Tasks with Acceptance Criteria

The first thing I'd do in this scenario at Meta (or any company with high-caliber people) is just to observe others. Find other Senior/Staff engineers on the team and figure out how they decompose problems and delegate tasks.

There's usually some sort of team sync where people talk about the work they plan on doing in the next few days or weeks. This will likely be a critical meeting where you should come prepared with ideas of:

• What major work items have to get done, and what is a reasonable decomposition of the work?
• What skills are required to get those tasks done, and who on the team has those skills?

For the acceptance criteria, the question I'd ask is:

How can I make it unambiguously clear to anyone relying on this work that is has been completed adequately?

What are the likely questions they'll ask, or what resources/test cases will they ask for? Embed that in the work description, and ask the engineer doing the work to include links in the deliverable.

Here's the opposite of the question you're asking, where an engineer feels like they were given something far too vague. Use this to understand what NOT to do: What can I ask to break down vague requirements?