If it makes you feel any better, the Markdown part is optional (and has no semantics). Somehow it feels about right that the Markdown file can actually just be a YAML file with the wrong extension.
(Actually, to be more specific, a YAML file with no directives, explicitly-signalled start-of-document-content, and followed by a second null document. I will note that frontmatter syntax is not specified; the non-normative Appendix B is the only place that suggests it means prefix and suffix --- lines. And no, frontmatter is not part of Markdown, or CommonMark, and is in fact incompatible with both. And it’s invalid YAML too, the end-of-frontmatter line should be ... to indicate end of document without starting a new document.)
> sure, but structured text like markdown is even more useful, since humans can parse and understand it as easily as skills can
And there are a number of nice viewers / editors either already installed or easily installable on most operating systems to view / edit Markdown in a "beautified" fully rendered form, on both CLI and GUI interfaces; and since most (all these days?) LLMs also "understand" Markdown formatting pretty-much natively, you can easily emphasize certain points to add "weight" to them in the LLMs' "mind" / "thinking" (calculation of statistical token probabilities) process. Plaintext without Markdown is just ... well ... plain. :)
it is until we define real consistent deterministic gates and protocols. It really is a symptom of the lack of concerted effort. Everyone has a personal preference on how to shove the context and most of them are just "here's some good text I've found to work in my context"
> define real consistent deterministic gates and protocols
I've been experimenting with doing kinda exactly that with the "routing layer" / "harness" level of things, before the "main" LLM itself ever receives the user's input, by getting "user intent" (as a little JSON packet) really quickly from an ultra-lightweight model first and deciding from there in deterministic code what "context" to inject into the user message template, which system prompt to use, and which model to route the assembled context "packet" to for the final response. These LLMs really are fun to play with once you get a feel for which ones do what well, and where each falls short so you can use them each around their individual strengths. :)