I've been able to avoid this kind of markdown library architecture with very chatty tool feedback. Interaction with a responsive environment is much better than static chunks of "skill" text. For example, imagine a domain constraint:

"You must use tool ABC before calling tool XYZ"

This can either be in some static prompt scheme somewhere, or it can be the live result of a tool call.

If you make everything tool calling and environmental, you effectively have a lazily evaluated & dynamic prompt scheme.

I like to think of this as context for the context. The better you map the environment and descriptions of it to the agent, the less top-down prompting is required.

If you set up the harness correctly, you can run circles around a lot of what passes as AI innovation with powershell in a while loop. Adding static markdown document soup on top of this would only reduce performance in the general case.

Yup! I feel pretty strongly that every little nit pick and instruction you pass into your model is murdering your output. Having a hook that executes on tool calls is significantly better than telling your agent to follow your repos specific format/lint/style/test constraints

A good agent and harness should notice that an instruction like "You must use tool ABC before calling tool XYZ" is best implemented as a pretooluse hook

Can you go into more detail about your setup and use cases?