[Documentation] Split readme into smaller files

[StanFromIreland]

Splitting the long readme into more manageable files will make it more organized and easier to find the stuff you are looking for. I can do this if help is wanted. I would put all sections into a Docs folder.

[nicbarker]

I agree, we need a better solution for managing docs for sure. I'm investigating the github wiki atm but would also like the docs to be version controlled so that older versions of clay that are in projects still include the full documentation 🙂

[Shadow1363]

An interesting option could be Material for MK Docs.

[RoboXGamer]

I agree, we need a better solution for managing docs for sure. I'm investigating the github wiki atm but would also like the docs to be version controlled so that older versions of clay that are in projects still include the full documentation 🙂

I have an idea to make docs for this in Starlight + Astro as those docs look the best and most ease of use for the user and we can have version control with them also

[Jipok]

If the project documentation does not grow, then the way everything is done now is really great:

1. It immediately gives a feeling of the minimalism of the project and the understanding that it is easy to master.
2. All the information is in one file, you can immediately see the amount of what you need to know from the scrollbar.
3. You can simply feed the readme to any LLM and ask questions, they cope perfectly with one small file.

I would recommend not to split the documentation too much. And it would be nice to have a documentation site made with clay.

UPD: I mean, documentation might be worth putting on a separate site (made with Clay, of course), but it would be better if it was one page, easy to copy-paste for llm, where the scrollbar allows you to estimate the volume. And some menu/contents on the left to quickly jump between sections.

[Mathys-Gasnier]

What @Jipok said is true, the doc isn't that big, splitting it will just make it so we need to switch pages constantly... Two things that would help with the global understanding of the doc are:

• A table of contents to jump to each Readme label
• A cheatsheet kinda like raylib does, just something that lists every function signature with a little comment explaining it