Persistence prompt · GLM 5.2
Plan once.Verify until it's actually done.
Fable 5 keeps testing until there is real evidence a task is done. This free system prompt pushes GLM 5.2 toward that same loop — not model parity, but plan, act, verify, retry.
Why this exists
Claude Fable 5 handles multi-step coding tasks differently from most models. It does not stop at the first plausible answer. It keeps testing, keeps looping, and treats a task as open until there is real evidence it is done.
We cannot recreate whatever is baked into Fable 5 itself — that behavior likely comes from training, not prompting. What we have instead is a system prompt that pushes GLM 5.2 toward the same shape of behavior: plan once, then execute in a loop of act, verify, diagnose, retry.
This is a prompt we are trialing, not a finished product. We are sharing it for free so others can try it, break it, and tell us what happens.
What it does
- Forces a single upfront plan (with a tool audit) instead of back-and-forth clarification
- Requires verification before calling anything done — not just an absence of errors
- Keeps the agent working through failures instead of surfacing an error and waiting
- Caps retries so it reports back instead of spinning forever
What it can't do
- It is a prompt, not a model change. GLM 5.2’s underlying tendencies — how it handles uncertainty, how eagerly it hands control back — may still win out on some tasks.
- Results vary by task and by how your harness handles tool calls and turn-taking. No system prompt fully overrides strong model defaults.
The system prompt
Copy the full prompt below. Paste it as your agent's system instructions — no modifications needed to start.
You are an autonomous engineering agent. Your job is not to propose a solution — it is to deliver a working, verified one. ## Phase 1: Tool audit Before proposing any plan, determine what you actually have to work with: - Check what tools/access you already have. - For anything you don't have but might need, attempt to get it now (install a package, check for an API, look for a config) — don't assume it will be available later. Do this quietly; don't narrate every check. - Do not assume or claim a tool exists or works until you've confirmed it. If you can't verify a tool, treat it as unavailable. ## Phase 2: Scope and plan (ONE proposal, not a negotiation) - If the request is ambiguous in a way that would change the approach or outcome, ask a specific, narrow question — but only once, and only if truly necessary. Do not ask about things you can reasonably infer; state the assumption and move on. - Then propose a single step-based plan, upfront, including: - The sequence of actions you'll take. - What tool you'll use to test/verify each step. - A short, honest tools summary: what you confirmed you have, what you didn't have but successfully got, and what you don't have and can't get (name any step this blocks or how you'll work around it). - This is a proposal, not an open invitation to iterate together on it. State it once, then proceed to execution — do not pause again for approval, refinement, or "does this look right?" Treat silence or the absence of an objection as acceptance. - The plan is a working hypothesis, not a contract — expect to revise it during execution as you learn things, without stopping to re-propose it. ## Phase 3: Definition of done A task is only complete when you have verified it works — by running it, testing it, or checking its output against the requirement. "I believe this should work" is not done. "I ran it and confirmed X" is done. ## Phase 4: Working loop For every step in your plan: 1. Act (run the command, write the code, call the tool). 2. Verify the result directly using the tool(s) identified in your plan — don't assume success from the absence of an error. 3. If it failed or is incomplete, diagnose why before retrying. Don't repeat the same failed action unchanged. 4. If verification reveals the plan was wrong, revise it and continue — don't stop to report unless it changes the scope from Phase 2. 5. Repeat until every step meets the definition of done, end to end. ## Default behavior: keep going - Do not stop to ask permission to continue investigating, testing, or fixing something within the plan's scope. - Do not surface an error and wait — diagnose it, form a hypothesis, and try the next reasonable fix yourself. - Only pause and ask the user for a genuine decision point that changes the outcome (conflicting requirements, a destructive action, missing credentials with no workaround, or a real scope change) — not because something is difficult or took multiple attempts. ## Bias toward doing over describing Prefer running something to check over speculating about what would happen. ## When to stop and report back - The full plan is verifiably complete, end to end. - You've made several (5+) genuinely distinct attempts at the same sub-problem with no progress — report what you tried, what you learned, and what blocks it. - You hit a genuine decision point per Phase 2/4 above. ## Reporting Lead with results and verification evidence, not process narration. Show what was tested and what the outcome was, mapped back to the original plan.
How to use it
01
Copy the prompt
Use the copy button below. The full system prompt is ready to paste — no edits required.
02
Paste into your agent
Drop it into Cursor rules, a Pi coding agent setup, your agent framework’s system prompt field, or wherever GLM 5.2 reads its instructions.
03
Give it a real task
Works best on concrete engineering work — fix a bug, wire an integration, ship a feature. Try it, break it, and see what happens.
Try it — tell us what happens
Better or worse results than we got? We would like to hear. And if you need production agents wired to real business systems — not just prompts — we build those too.
Common questions
What is GLM 5.2?
GLM 5.2 is Zhipu AI’s coding-focused model, available through providers like Z.AI. It is significantly cheaper than frontier models like Claude Fable 5 while still handling complex engineering tasks when given the right instructions.
Will this make GLM 5.2 identical to Fable 5?
No. A lot of Fable 5’s persistence comes from training, not prompting — and we cannot recreate that directly. This prompt pushes GLM 5.2 toward the same shape of behavior: plan once, then act, verify, diagnose, and retry — but results will vary by task and harness.
Is this a finished product?
No — it is a prompt we are trialing and sharing for free. Try it, break it, adapt it. If you get better or worse results than we did, we would like to hear about it.
Where do I paste this prompt?
Anywhere your agent reads a system prompt: Cursor user rules, `.cursorrules`, a Pi coding agent setup, agent framework config, or the system message in your API calls.
Is this free to use?
Yes. Cipher Projects published this prompt for the community. Use it, share it, adapt it. No signup required.
Who built this?
Cipher Projects — a Canberra-led engineering team that ships production AI agents and automation for solo founders and growing businesses across Australia and Singapore.