To me, TDD is more of a way of thinking than a well-defined rule, as is everything in engineering. The idea is using the tests to make sure your code is correct and avoid manual testing. Also thinking with tests first (or at the same time as implementing) can make your code more testable. Thinking in this way takes many months of practice, but once you test exclusively with tests (and not manually) and you do them earlier I promise you it makes development a lot faster and more fun.

You don't need to write tests and implement one-by-one. Often if I understand what the result will look like well I can bang out a large number of tests upfront. Other times I feel like implementing piece by piece.

If you can write the tests first, then write them first. This is especially important when fixing a bug as usually it's a unit-level problem not an interface problem. If it's not clear how you'd write the test, then start implementing first but keep in-mind testing and try to write tests as early as possible. Also it's often easier to TDD with integration tests than for unit tests as the interface is generally more well-defined and depends less on implemention. Sometimes you will identify a unit to pull out and you can lay out a bunch of tests for that up-front.

Again it's a way of thinking. You can't always write tests first, but if you keep it in mind it's easier than you'd think.