Vibecodeprompts treats prompts like infrastructure

Most “prompt libraries” assume the problem is wording. As if better adjectives or clever roleplay magically produce reliable systems. That has never matched my experience. The real failure mode is drift, inconsistency, and lack of shared structure once things scale beyond a single chat window.

Vibecodeprompts seems to implicitly accept that prompting is closer to infra than copywriting.

The prompts are opinionated. They encode assumptions about roles, constraints, iteration loops, and failure handling. You can disagree with those assumptions, but at least they are explicit. That alone is refreshing in a space where most tools pretend neutrality while smuggling in defaults.

What I found useful was not copying prompts verbatim, but studying how they are composed. You can see patterns emerge. Clear system boundaries. Explicit reasoning budgets. Separation between intent, process, and output. Guardrails that are boring but effective.

In other words, this is less “here is a magic prompt” and more “here is a way to think about working with models as unreliable collaborators”.

That also explains why this probably will not appeal to everyone. If you want instant magic, this is not it. You still have to think. You still have to adapt things to your domain. But if you are building anything persistent, reusable, or shared with other people, that effort feels unavoidable anyway.

Curious how others here think about this. Do you treat prompts as disposable glue, or as something closer to code that deserves structure, review, and iteration over time?

https://t3x.org/zsp/index.html

With LLM's you will often lack predictability. If there's any, of course. Because more than I once I had to correct these over trivial errors on TCL, and they often lack cohesion between different answers.

That was solved even under virtual machines for text adventures such as the ZMachine, where a clear relation between objects was pretty much defined from the start and thus a playable world emerged from few rules with the objects themselves, not something built from the start. When you define attributes for objects in a text adventure, it will map the language 1:1 to the virtual machine, and it will behave in a predictable way.

You don't need a 600 page with ANSI C standards+POSIX, GLibc and > 3000 pages long books with the AMD64/i386 ISA's in order to predict a basic behaviour. It's there.

Can LLM's get this? No, by design. They are like huge word predictors with eidetic memory. They might somehow be slightly good on interpolating, but they are useless extrapolating.

They don't understand semantics. OTOH, the Inform6 language tageting the ZMachine interpreter has objects with implicit behaviour in their syntax and a basic syntax parser for the actions from the users. That adds a bit of context generated between the relations of the objects.

The rest it's just decorated descriptions from the programmers, where the ingame answer can be changed once you drop some kind of objects and the like.

Cosmetic changes in the end, because internally there's mapped a action which is indistinguisable from the vanilla output from the Inform6 English library. And Gen-Z ers don't understand that when older people tell them that no LLM will be close to a designed game from a programmer, be in Inform6 or Inform7. Because an LLM's will often mix named input, named output and the implicit named object.