yao-open-prompts: Yao Open Prompts Turns Prompt Writing Into a Compiler Problem
A Chinese prompt library with versioning, linting, RTF meta-prompts, and pseudo-LISP syntax reveals what prompt engineering looks like when it starts acting like software.
- Yao Open Prompts treats prompts as maintained software artifacts, not disposable snippets.
- Its weirdest move is also its sharpest one: pseudo-LISP turns prompt structure into something the model has to parse, not merely read.
- The repository pairs creative prompt design with repository discipline, including taxonomy, frontmatter, automation, and an English mirror.
- Taken together, the project sits between a prompt library and a lightweight framework, which is why it feels more operational than collectible.
Most prompt libraries feel like bookmarks. This one feels like a build system. The repository's real story is not the number of prompts, but the way it forces them into a maintainable shape: versioned, categorized, mirrored, and checked like code.
yao-open-prompts is a collection of open prompts for the yao project.
Prompt Engineering, But Make It a Compiler
The useful way to read yaojingang/yao-open-prompts is not as a dump of reusable text. It behaves like prompt infrastructure. The repository has a strong notion of taxonomy, a bilingual mirror, maintenance scripts, and meta-prompts that generate other prompts. That is not a folder of tricks. That is a workflow.
The best evidence is structural. Prompts live in domains, frontmatter carries metadata, and the repository includes checks and catalog generation. The design says something important: once prompt writing becomes valuable enough, it stops being a loose craft and starts becoming an operations problem.
The Weirdest Part: Prompts Written Like Code
The pseudo-LISP prompt is the most revealing example in the repo. It asks the model to think in nested structures, not freeform prose. That matters because the syntax itself becomes part of the instruction. The model is not just told what to do. It is boxed into a hierarchy of roles, tasks, and constraints.
(define-meta-prompt-system
:role "Prompt Expert"
:goal "Transform vague intent into structured prompts"
:constraints ("follow RTF" "preserve hierarchy" "output in a fixed format"))
That is the compiler logic in miniature. Raw intent goes in. Structured output comes out. The value is not in the parentheses themselves. The value is in the discipline they impose.
A Repository That Acts Like a Maintained System
| Prompt collection behavior | Yao Open Prompts behavior |
|---|---|
| Loose snippets in one folder | Domain-based organization across prompts, prompts-en, maintenance, scripts, and docs |
| No metadata | YAML frontmatter with versioning, status, and source fields |
| Manual browsing | Catalog generation and repository checks |
| Single-language distribution | English mirror alongside the Chinese library |
| One-off prompt writing | Reusable meta-prompts that generate more prompts |
This is where the repo crosses the line from content library to system. The structure says the maintainer expects change, review, and reuse. That is why maintenance files matter as much as the prompts themselves. They imply governance.
The English mirror matters too. It is not just localization. It is distribution strategy. A prompt library that can only be read in one language is a local archive. A mirrored one becomes a portable system.
Why GEO and Humanized Writing Matter Here
| SEO-era prompt thinking | GEO-era prompt thinking |
|---|---|
| Optimize for human clicks | Optimize for machine-citable trust signals |
| Write for readability only | Write for machine readability plus human readability |
| Lean on keywords | Lean on evidence blocks and structured claims |
| Treat distribution as search traffic | Treat distribution as answer surfaces across AI systems |
| One audience | Two audiences: people and retrieval models |
The repo's GEO branch shows where the discipline is headed. Search is no longer only about ranking pages. It is about making content legible to systems that summarize, cite, and synthesize. That changes how prompts are written, because prompts now need to produce outputs that survive machine digestion.
The humanized-writing branch points the other way, toward style and voice. Together, the two branches tell a useful story. One optimizes for machine trust. The other fights generic output. The repo is not confused about that tension. It is organizing around it.
How This Repo Compares
| Axis | Yao Open Prompts | Prompt marketplaces | LLM frameworks |
|---|---|---|---|
| Primary unit | Versioned prompt files | Shared prompt examples | Code and chains |
| Structure | High | Low to medium | High |
| Distribution | GitHub repo plus mirrors | Web app or gallery | SDK and runtime |
| Prompt quality control | Frontmatter, taxonomy, scripts | Community ratings | Programmatic composition |
| Best at | Prompt design discipline | Discovery | Application orchestration |
| Weakest at | Runtime execution | Governance | Editorial curation |
This is why the repository is interesting even without a runtime. It occupies a narrow but valuable middle ground. It is more disciplined than a gallery, less heavy than a framework, and more opinionated than a pastebin. That makes it a good specimen of prompt engineering's maturation.
The Bigger Idea
The deepest implication here is simple. Prompt engineering is drifting away from ad hoc writing and toward systems design. Repositories like this are evidence of that shift. They show a world where prompts are versioned, reviewed, translated, and cataloged like product assets, because that is what they have become.
That does not make prompts boring. It makes them legible. And once prompts are legible, they can be maintained, audited, and improved. That is the compiler mindset hiding inside this repository.