Since this is a strange quirk on Windows, and the knowledge of handling PATH is just an assumed skills for UNIX world. I guess you can add some logic in kickstart to “guess” the common path to store C compiler on Windows if no C compiler is in PATH.
This might work in this case, but it does not in general. Then, you’d need to add the path to the linker/librarian. Done? Not really, cause then you’d need to add the path to all libraries you need to link to. Finally, runtime libraries. So that’s not a viable solution to be done manually. So, generally, some environment setup scripts are provided.
Something that in most of the cases is not needed in UNIX-like systems, for how libraries and dependencies are installed in the system.
Not that I think this is good, and indeed it does not foster full support of things like this one on Windows systems.
One way could be to automatically detect a VS development kit, which normally should reside in a standard path set by the installation process (except if the user manually changed it). In any case, you could query the VS{2015/2017/2019/2022}INSTALLDIR ENV variable, and if found, launch a separate process where you launch the VS prompt and compile with the VS cl C compiler.
Or, if for some reasons VS is not installed in the system, another most used development kit Intel’s oneAPI, which is now made free. You could query for the ENV variable ONEAPI_ROOT. If it exists, then in a separate process launch the setup script %ONEAPI_ROOT%\setvars.bat and call the cc/clang Intel compiler.
This way, no action is required by the user, if it is not at ease with such things. Everything would be automatically managed under-the-hood.
Just follow these instructions from the Treesitter site, this will allow it to download pre-compiled artifacts from Github on platforms where requiring a compiler on the path is a stupendously bad idea.