Support markdown semantic functions

It would be great if skills could be defined as a group of markdown files with frontmatter (YAML) for defining the configuration, i.e.

instead of

• WriterSkill/
  • Acronym/
    • skprompt.txt
    • config.json
  • EmailTo/
    • skprompt.txt
    • config.json

You could have

• WriterSkill
  • Acronym.md
  • EmailTo.md

Where Acronym.md has

---
schema: 1
type: completion
description: Generate an acronym for the given concept or phrase
completion: 
  max_tokens: 100
  temperature: 0.5
  top_p: 0.0
  presence_penalty: 0.0
  frequency_penalty: 0.0
---
Generate a suitable acronym pair for the concept. Creativity is encouraged, including obscure references. 
The uppercase letters in the acronym expansion must agree with the letters of the acronym

Q: A technology for detecting moving objects, their distance and velocity using radio waves.  
A: R.A.D.A.R: RAdio Detection And Ranging. 

Q: A weapon that uses high voltage electricity to incapacitate the target
A. T.A.S.E.R:  Thomas A. Swift’s Electric Rifle

Q: Equipment that lets a diver breathe underwater 
A: S.C.U.B.A: Self Contained Underwater Breathing Apparatus.

Q: Reminder not to complicated subject matter.
A. K.I.S.S: Keep It Simple Stupid 

Q: A national organization for investment in space travel, rockets, space ships, space exploration
A. N.A.S.A: National Aeronautics Space Administration

Q: Agreement that governs trade among North American countries.
A: N.A.F.T.A: North American Free Trade Agreement. 

Q: Organization to protect the freedom and security of its member countries in North America and Europe.
A: N.A.T.O: North Atlantic Treaty Organization.  

Q:{{$input}}

This would help reduce the number of files and folders a developer has to sift through, making the name of the file significant (rather than every function being named “skprompt.txt”)

[onionhammer]

For any future folks, I wrote a quick proof of concept. The argument about “performance” above is pretty silly, reading from 1 file is always going to be faster than reading from 2 files, the only difference is YAML deserialization vs JSON deserialization, which should be negligible. This could be easily tuned to be more performant, but 99% of the time will be spent reading the file into memory from secondary storage.

Also, some things had to be duplicated, since this library makes some things internal-only

https://gist.github.com/onionhammer/c019b04a7c4f058cd57183f0df738905

[onionhammer]

@dluc Why was this closed as completed? Did you mean to close it as not planned? If so then why say you’d consider hosting alternative formats?