How to break down a game idea into a game design bible (not doc)

I used to think that Pong would be the perfect game for a beginner game developer. Not because it turned out to be difficult, but simply because there are simpler games to create. For example, Snake is one such game. It doesn’t require a second player or “complicated” math for rebounds. Everything can be simplified, of course, but there’s no need to bother with unnecessary thinking. Hence, the idea of making Snake the first game. When you have little time for hobbies and can only spare an hour at most for skill development, there’s no point in rushing it! A plan is needed, and not just any plan. It has to be detailed, broken down into even the most atomic tasks, sometimes to the extreme. The hour during the day that some of us find (or not) requires a seamless transition to deep work, with as little wondering, ‘Where was I? What should I do now?’ But I don’t start with tasks. The first result of such preparation is what I call my game design document. However, I seem to perceive it slightly differently than most tutorials on the Internet, where it appears that the document is an excuse to mix a pitch deck, lore, storylines, dialogues, marketing plan, and some references to the game project  <a href="https://medium.com/@MauriceKlimek/how-to-break-down-a-game-idea-into-a-game-design-bible-not-doc-21d7d03654de">Website</a>