Seven languages, one spec tree, zero drift. That’s the number that stopped me mid-scroll on a post in r/PromptEngineering this week. The tool is called Yass, and the person behind it, u/TedditBlatherflag, just pushed it into public beta after months of quiet building.
Here’s the problem the creator was solving. Most spec-driven development tools force you to write walls of custom instructions that models either ignore or forget halfway through a session. Others need heavy plugins or skills bolted on just to function. Yass takes a different approach. It uses a minimal YAML format built on RFC2119 keywords like “MUST,” “SHOULD,” and “MAY.” That’s the same vocabulary every major model already has baked into its training. No custom instruction set to write. No plugin to install. Just keywords the model already understands, arranged in a lightweight spec tree.
That’s the setup. Here’s the twist that actually makes this interesting.
To prove the specs alone were doing the work, the creator ran a wild validation test. A single Yass spec tree, with no CLI downloaded anywhere in the sandbox, reproduced the entire Yass CLI with byte-exact output. It did this across seven different languages: TypeScript, Python, Go, C, C++, Erlang, and Elixir. All of it ran inside sandboxed Claude Code harnesses on Opus 4.6, not some eye-wateringly expensive frontier model. If the spec alone can drive identical output across seven totally different language runtimes, that’s not a toy demo. That’s a real signal the format is doing what it claims.
So the CLI isn’t actually the product here. The spec is. The CLI just makes it faster to work with.
How to try it
- 📖 Clone or open the Yass repo on GitHub and point your agent at the README. That’s the entire onboarding step.
- 🤖 Tell your coding agent (Claude Code, or whatever you’re running) to read the README and follow it. The README itself contains everything the agent needs to get moving.
- ⚙️ Write your first spec tree in the minimal YAML format. Lean on RFC2119 keywords to express what the implementation MUST do versus what it SHOULD or MAY do.
- ✅ Hand the spec to your agent and let it implement directly from that, no extra plugin required.
- Hit something broken? Open a GitHub issue yourself, or better, have your agent open it for you.
Pro tip: don’t think of the CLI as a requirement. The creator’s own validation test stripped it out entirely and the specs still drove correct, reproducible output. Treat the CLI as a token saver and steering aid, something you reach for once you trust the spec format. It’s not a dependency you need on day one. If you’re testing this on a tight token budget, start with the raw spec tree and skip installing anything.
A second thing worth stealing for your own prompt engineering: the RFC2119 trick generalizes past this one tool. Models already have strong trained-in associations with “MUST” versus “SHOULD” versus “MAY” from years of ingesting specs and RFCs. Leaning on vocabulary the model already respects, instead of inventing your own instruction syntax, is a cheap way to cut context rot. That applies to any agent workflow you’re building, not just this one.
A few caveats worth flagging before you commit real work to this. This is a fresh public beta, not a mature 1.0 release, so expect rough edges and API drift while the creator keeps refining the format. The byte-exact reproduction test is impressive, but it was run across specific languages and one specific harness, Claude Code on Opus 4.6. Your mileage may vary on other platforms until more people stress test it themselves. The whole pitch also rests on models already knowing RFC2119 semantics cold. Results will likely be strongest on frontier-class models and noticeably shakier on smaller local ones.
Compared to heavier spec-driven-development setups that ship their own DSL, plugin architecture, or skill library, Yass is making the opposite bet. It leans on minimal syntax, zero required tooling, and behavior the model already has, instead of behavior you have to teach it. Whether that tradeoff holds up at scale is exactly what the beta is for.
If you’ve been burned by spec files that get ignored three prompts into a session, this is worth twenty minutes of your afternoon. Go point an agent at the README, write one small spec tree, and see if it holds. 🚀 If you find a gap or want a feature added, the creator’s asking for GitHub issues. Don’t just complain in the comments, go file it.
Yass – Yet Another Spec Syntax Enters Beta
by u/TedditBlatherflag in PromptEngineering