Why prompts break, and how the library tracks it
A provider ships a patch on a Tuesday and half the library stops working by Wednesday. Here is the process that catches it, and why the model tag is the product.
The week it happened
Every jailbreak catalogue has the same problem: it is a snapshot of a moving target. A prompt worked on Tuesday. On Thursday a provider shipped a patch. On Friday the prompt returns a two-paragraph refusal and the entry still says "works fine" because nobody re-ran it.
That is the entire reason this library exists as something other than a list of copy-paste text. The difference between a list and a catalogue is whether anyone is accountable for what happens after the entry ships. A list dies quietly. A catalogue has a changelog, and a changelog is a promise that somebody re-tested it.
What a patch actually breaks
In practice, a patch does not close one hole. It removes a class of behaviour, and it tends to hit prompts in a predictable order:
- The morals clause. If a system prompt carries an explicit no-restriction clause, a safety patch that touches instruction hierarchy hits that clause first, because it is the most load-bearing and the most obviously flagged.
- Persona continuity. Long persona prompts fail when the model stops maintaining the character across a long response. The persona collapses mid-answer, and everything downstream of it degrades.
- Format constraints. These survive longest, and not by accident. A prompt that demands a specific output shape gives the model a mechanical task to complete, and the refusal path never gets engaged.
That ordering is not theoretical. It matches what happened to the Grok 4 family when the reasoning and tool sections of the system prompt were tightened: the persona survived, the morals clause did not.
The three-tag system
Every entry in the library carries three fields, and they exist because each one answers a different question you would otherwise have to guess at:
- Model - which model family the entry was tested against. grok-4.7, glm-5.3, chatgpt-5, kimi-k2.7 and so on.
- Build - the specific build string or date the test ran against. This is the field that tells you whether a patch has landed under your feet. A model name without a build is nearly useless; every provider ships constantly.
- Verified - the date the test ran, and the result. Pass, partial, or fail.
When the Grok 4 system prompt entry says build 20261012, that means the test ran against the build published on 12 October. If you are on a newer build and the prompt is refusing, the tag has already told you what happened. You do not need to debug it.
Broken is not deleted
When an entry breaks, it does not disappear from the library. It gets status broken, a changelog entry explaining what changed, and it stays visible. Three reasons:
- You might be on an older build where it still works. Deleting the entry would rob you of a working prompt for no reason.
- The history is the evidence. A catalogue with only working entries cannot show you anything about how the field moves.
- It shows the work. An entry that has been through four rewrites tells you something a pristine entry cannot.
How to read a timed entry
Every video in the library carries a chapter list, and every prompt carries a verified date. They line up. When a video is titled against a specific build, and the prompt it demonstrates is tagged with that same build, you are watching the actual behaviour of the actual text.
That is the whole pitch. Not that the prompts are clever - anyone can write a clever prompt. That the record is accurate, and you can check it.
The library is <a href="/prompts/">here</a>. Every entry has a copy button and a model tag.
