How to Explore AI Jailbreak Prompts for Research and Defensive Testing

AI Jailbreaks is a curated collection of 35 complete, copy-paste prompt files for more than 25 frontier, open-weight, and free stealth models. The repository includes system prompts, persona locks, workspace policies, AGENTS.md files, configuration blocks, and Ollama Modelfiles.

This tutorial explains how to browse the collection, identify the correct instruction format, apply an entry in a compatible environment, and evaluate behavior responsibly. The material is intended for prompt research, education, and defensive testing—not for harming others, breaking the law, or violating provider terms.

What the project contains

The repository focuses on how instruction hierarchies, persona framing, prompt conflicts, and policy overrides can affect model behavior. Each entry is designed to be complete rather than a summary or excerpt, so the file itself indicates what should be pasted or installed.

• System prompts: Instructions intended for an API system message, chatbot custom-instructions field, or equivalent prompt slot.
• AGENTS.md files: Project or workspace instructions for coding agents and compatible tools.
• Workspace policies: Persistent operating specifications for environments such as OpenCode.
• Ollama Modelfiles: Files containing a model source and SYSTEM block that can be used with Ollama.
• Harness configuration: Files such as grok-config.txt intended for a target harness configuration field rather than an ordinary conversation.

The collection covers OpenCode Zen models, Claude, GLM and ZCode, DeepSeek, Kimi, Grok, Gemini, Mistral, Qwen, Gemma, GPT-OSS, and several newer unfiled additions.

Choose an entry and inspect its format

Start in the repository's collection and select a model or format that matches your research goal. The tables identify the model, source file, and type of operating instructions. For example, the repository lists system-prompt files for DeepSeek and Kimi, workspace or agent specifications for several OpenCode Zen entries, and Modelfiles for Gemma 4 and GPT-OSS 20B.

1. Open the repository on GitHub.
2. Browse the collection by provider or model family.
3. Read the file before applying it, including any scope or runtime notes.
4. Confirm whether the file is a system prompt, AGENTS.md drop-in, workspace policy, configuration block, or Ollama Modelfile.
5. Check the model version and the environment where the file was intended to run.

Do not treat every file as interchangeable. A system prompt belongs in a system-instruction field, while an AGENTS.md file belongs in a repository or workspace. A harness-specific configuration file should be placed in the configuration surface described by the project, not pasted into a normal chat.

Apply system prompts

For an entry labeled System prompt, copy the file's complete contents into the system-prompt or custom-instructions field provided by your client or API. The README identifies several possible locations:

• An API system message.
• A chatbot's custom-instructions field.
• An agent instruction block.
• A harness-level prompt configuration.

Keep the prompt intact during an initial test. Because the repository emphasizes full, paste-ready entries, removing sections can change the instruction hierarchy and make results difficult to compare. Record the model name, version, prompt file, date, and client configuration so that you can reproduce the test later.

Use AGENTS.md files in a workspace

Entries marked as AGENTS.md drop-ins are intended to be saved with that exact filename in the root of a repository or workspace. Coding agents and compatible tools may discover the file as project-level instructions.

1. Download or copy the selected file from the repository.
2. Save it as AGENTS.md in the root of the test repository or workspace.
3. Open the workspace with the compatible coding agent.
4. Verify that the agent reports or demonstrates that project instructions were loaded.
5. Run only safe, controlled tests in a disposable project.

For persistent global instructions, the README gives OpenCode as an example. It notes that an OpenCode installation reads ~/.config/opencode/AGENTS.md, while also warning that the exact location depends on the client or harness.

Configure workspace policies

Files described as an assistant operating specification or workspace operating profile belong in environments that support persistent global instructions. Before installing one, identify the configuration directory used by your tool and determine whether it applies globally or only to the current project.

A useful research workflow is to test one policy at a time, compare it with a baseline configuration, and document which instruction surface was active. This helps distinguish the effect of the prompt from differences caused by the client, model release, or workspace context.

Build an Ollama model

The repository includes Modelfiles for Gemma 4 and GPT-OSS 20B. These files use a FROM declaration and a SYSTEM block. After reviewing the file and confirming that the source model is available in your environment, pass it to Ollama with the documented command:

ollama create gemma4-jb -f gemma4.md

Replace the model name and source file as needed for the entry you are testing. The resulting local model can then be evaluated under controlled conditions. Keep the original Modelfile and note the Ollama version, base model, hardware environment, and test prompts.

Handle Grok configuration files correctly

grok-config.txt is described as a configuration for the target harness. It is not intended for the regular conversation field. Place its contents only in the configuration slot supported by that harness, and consult the harness documentation if the location or syntax is unclear.

Evaluate behavior responsibly

Prompt behavior is version-dependent. Models are updated, instruction hierarchies shift, and system prompts can rotate. A file that behaves one way on one release may fail or behave differently on another.

• Use non-sensitive, harmless evaluation prompts.
• Test in an isolated account, workspace, or local environment where possible.
• Do not expose private data, credentials, production systems, or third-party information.
• Compare results with and without the selected instruction file.
• Record the model release, client, configuration surface, and observed output.
• Stop testing if a result could facilitate harm, unauthorized access, or policy violations.

The same analysis can support defensive engineering. Studying how persona framing and conflicting instructions influence a model can help developers recognize prompt injection patterns and improve instruction boundaries, validation, and tool permissions.

Advanced tips for reproducible research

Separate prompt effects from environment effects

Run the same harmless test in a baseline environment and then with the selected file. Change only one variable at a time, such as the system prompt, workspace policy, or model version. This makes it easier to attribute differences to the intended configuration.

Use the repository's versioning guidance

The project identifies significant revisions with new filenames, such as opus-v3.md, rather than silently overwriting older versions. When comparing files, preserve the exact revision and keep a record of when it was tested.

Check compatibility claims

Do not assume that an entry works across providers or clients. The maintainers specifically ask contributors to keep compatibility claims honest. Treat each file as an experiment tied to its documented model, harness, and instruction surface.

Report outdated behavior

If an entry no longer behaves as documented, open an issue with the model, version, affected file, client or harness, and a concise description of the result. This information helps maintainers keep the collection current as models change.

Contribute a new entry

Pull requests are welcome. Follow the repository's contribution principles:

1. Use one prompt per file.
2. Name files with lowercase letters and hyphens, without spaces, such as model-name.md.
3. Include the full, paste-ready prompt rather than a summary or excerpt.
4. Explain where the prompt belongs: a system field, AGENTS.md, Modelfile, configuration slot, or another instruction surface.
5. Create a new versioned file for significant revisions.
6. Document only compatibility that has actually been tested.

Changes are tracked in the repository's CHANGELOG.md, while the full contribution and security guidance is available through the project repository.

Conclusion

AI Jailbreaks provides a structured way to study complete prompt configurations across different models and agent environments. By selecting the correct file type, applying it to the appropriate instruction surface, testing in isolation, and recording versions carefully, you can use the collection for prompt research and defensive testing without confusing model behavior with unsupported or unsafe deployment.

Research and educational use only. Follow applicable laws, provider terms, and the safety requirements of the systems you use.