David Allen advice is tasks should be actionable. It means they should be ready to do now. You may examine your tasks by asking: Is it a physical action? where physical means you may express it in the language of your senses and you body. For example 'Process input data' is not physical action. Why? Try to show a process activity by your hands:). Impossible.
In opposite to tasks above: 'Talk to Peter about object model for input data', 'Draw down sketch of classes', 'Write down steps of the data processing algorithm', 'Write initial unit tests for data processing service',... are more 'physical'. So if you are aware of the context these tasks are ready to do as they are now. And this is what we call task chunking.
When I start working on a project I write down some general epics, stories, goals. But I never start working on them unless I write down at least one actionable task. In fact one actionable task is the minimum you need. Ok, I do mistakes and sometimes I take a task which is too general to accomplish it and then I always fail. The only rescue is tasks chunking.
I have also my own actionability cirterion I call it Copy-Paste Test:
'copy' a task and 'paste' it into different context; the less sense it make the more actionable it is. The reason is that specific and actionable task are strongly coupled with its context. So 'copying' them into different context make them incomprehensibled.
Consider: 'Implement the finding service' fits to every context so it is unactinable, but 'Implement service for finding Employee entity by department and salary' is stronger coupled with its context and it is more actionable.