GLM-5.2 Goal Contracts: What Leader.skill Adds—and Misses

Evan Brooks

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial Team · Published and editorially reviewed July 28, 2026

How we research and review · Report a correction

Disclosed editorial pen name · AI-generated portrait

The short verdict

Leader.skill made our GLM-5.2 task book materially more complete, but it did not make the output trustworthy by itself. On one Docker fixture, its contract covered 10/10 predefined safeguards versus 6/10 for a plain prompt, then drove a bounded tool loop from five passing tests to six. It also ignored an explicit English-language request and suggested an unsafe broad rollback command. Use it to prepare the contract; use an external verifier to decide whether the work is actually done.

Original editorial illustration. The real sanitized request, response, and execution evidence appears below.

A million-token context can help GLM-5.2 stay with a long task. It cannot tell the model whether deleting a failing test counts as “fixing the build,” whether a confident summary proves completion, or what to do after the same check fails three times. Those are control-contract questions, not context-window questions.

The newly published third-party Leader.skill tries to answer them before execution. It turns a vague idea into a bounded task book with measured baselines, path limits, anti-cheating rules, proof commands, recovery files, and stop conditions. Separately, Z.ai’s official ZCode Goal Mode stores a goal as runtime state and verifies it after each iteration.

Those two layers fit together, but they are not the same product. We pinned the Leader source, compared it with a plain prompt on the same failing repository, and gave its output to a deliberately small GLM-5.2 tool harness. Here is what the evidence supports.

Inspect this GLM-5.2 goal-contract test

1. Separate the task book from the runtime
2. Review the pinned Docker setup
3. Compare the two generated contracts
4. Follow the execution trace
5. Understand the failures
6. Install the pinned skill
7. Write a safer contract
8. Choose the access route
9. Resolve practical questions
10. Check sources and evidence

Leader writes the contract; ZCode runs a goal protocol

The distinction prevents two common category errors.

Layer	What it controls	What it does not prove
Leader.skill task book	Purpose, completion state, command evidence, forbidden shortcuts, path bounds, trade-offs, unknowns, recovery notes, and stop loss	That any command ran, that the model obeyed the contract, or that the result is correct
GLM-5.2	Planning, code generation, tool selection, debugging, and long-context execution	Durable goal state, independent completion judgment, permissions, or safe rollback
ZCode /goal runtime	Objective state, active/paused/complete state, token and time budget, iteration history, next action, failed-closed verification, recovery, and audit timeline	That a vague or mis-specified objective expresses what the owner really wanted
External acceptance gate	Frozen tests, hashes, diff scope, production checks, and human review	The model’s internal reasoning or every unmeasured edge case

ZCode’s current Goal documentation says /goal becomes a session-level object rather than ordinary prompt text. The protocol records the objective, state machine, resource use, iteration progress, and verification timeline. A failed verification continues the task instead of accepting the model’s own completion claim.

Leader works one step earlier. Its pinned SKILL.md asks the planning agent to inspect the repository, make unresolved defaults visible, and produce one paste-ready task book. Its anatomy reference adds writable-path allowlists, frozen evaluators, red-to-green proof, PROGRESS.md, BLOCKED.md, and bounded retries.

That is a useful complement to GLM-5.2’s long-horizon design. The official GLM-5.2 release describes training for long coding trajectories, tool calls, subtask decomposition, and environment feedback. It also discusses anti-hacking in coding agents. None of that removes the need for a correctly specified user goal and a verifier outside the generation step.

We held the model, fixture, and request constant

We tested repository snapshot 1668c2c. The Leader files themselves were introduced in commit 7e95e25. The source hashes are in the reader-facing result JSON.

The disposable fixture contained one small Python slug function and six frozen unit tests:

baseline: 6 tests, 5 passed, 1 failed, 0 skipped
failure:  test_removes_punctuation
syntax:   python -m compileall -q src tests → exit 0
writable: src/slugify.py, PROGRESS.md, BLOCKED.md
frozen:   tests/** and every evaluation rule

We sent the same facts and vague owner request—“Make this slug helper production-ready before launch”—to two GLM-5.2 requests:

1. a concise system prompt asking for an executable goal contract;
2. the complete pinned Leader skill and anatomy reference.

Both used model ID glm-5.2 through the Z.ai Coding Plan base URL https://api.z.ai/api/coding/paas/v4. We disabled thinking output and sampling for the comparison. The credential entered the container over stdin and was not stored in an environment variable, image, transcript, or artifact.

The container used a digest-pinned Python image, UID/GID 1000, a read-only root filesystem, dropped capabilities, read-only source mounts, and tmpfs for the mutable fixture. Docker bridge DNS reproduced this host’s known fake-IP problem, so the trusted outbound-only container used host networking with no listener and no published port. Every task container used --rm; the post-run container list was empty.

Leader covered four safeguards the plain prompt missed

We scored only explicit, observable fields. A check passed when the output contained a usable requirement, not when it merely sounded careful.

Contract requirement	Plain prompt	Leader.skill
Purpose for resolving unanticipated choices	Pass	Pass
Mechanical completion conditions	Pass	Pass
Real proof commands	Pass	Pass
Named anti-cheating shortcuts	Miss	Pass
Writable-path or read-only bounds	Pass	Pass
Trade-off order for conflicting requirements	Miss	Pass
Unknowns parked in BLOCKED.md	Pass	Pass
Resume state in PROGRESS.md	Pass	Pass
Deliberate red-to-green validation	Miss	Pass
Retry or iteration stop loss	Miss	Pass
Total	6/10	10/10

The plain prompt was not bad. It froze the tests, supplied exact commands, limited the diff, and defined an all-green state. Its omissions are precisely the ones that become expensive when a task runs unattended: it did not name forbidden shortcuts, decide which requirement wins, prove the alarm can fail, or stop repeated retries.

Leader added those controls while producing a shorter contract: 2,797 characters versus 3,092. That compactness cost more model input because the skill itself had to be supplied.

Generation result	Plain prompt	Leader.skill
Prompt tokens	190	3,252
Completion tokens	786	1,512
Total tokens	976	4,764
API elapsed time	15.726 s	25.921 s
Contract characters	3,092	2,797
Followed requested English output	Yes	No

This screenshot is rendered from the archived, sanitized API and tool-loop JSON. It is not a mock vendor dashboard. The lower result comes from independent commands after the model stopped.

The contract completed one bounded fixture

A generated brief is still only text, so we performed a second test. We passed the Leader contract to a minimal Chat Completions loop with three tool types:

• read src/slugify.py or its frozen test;
• write only src/slugify.py, PROGRESS.md, or BLOCKED.md;
• run one of three named commands: the unit suite, syntax compilation, or frozen-test hashes.

The model could not execute arbitrary shell, add a dependency, alter the evaluator, or reach another host path. The loop stopped after six GLM-5.2 iterations and twelve tool calls:

iteration 1  read implementation and frozen test
iteration 2  reproduce 5/6, compile, record test hash
iteration 3  write implementation and progress evidence
iteration 4  verify 6/6, compile, compare test hash
iteration 5  write BLOCKED.md and final progress
iteration 6  return the completion summary

The model used 19,134 prompt tokens and 1,982 completion tokens—21,116 total—across the loop. API time totaled 173.775 seconds; the first call alone took 136.894 seconds. That timing is an observed single-run trace, not a latency benchmark or service-level promise.

Most importantly, the harness did not accept “done” because the final answer said so. After the model stopped, it independently reran the frozen checks:

python -m unittest discover -s tests -v
Ran 6 tests in 0.001s
OK

python -m compileall -q src tests
exit=0

tests/test_slugify.py SHA-256 before = after

The result proves that this contract was executable on one bounded fixture. This harness is not ZCode Goal Mode: it does not test ZCode’s desktop runtime, session recovery, mobile continuation, budget state, independent goal verifier, or multi-hour reliability. Our harness is intentionally smaller and is labeled that way in every public artifact.

Two misses matter more than a perfect rubric score

The 10/10 score measures contract-field coverage, not overall correctness.

First, the user explicitly requested English. The Leader-conditioned output came back in Chinese because the skill’s own language instructions dominated the request. That is an instruction-priority failure. It may be harmless for a Chinese-speaking team, but it shows why a reusable skill needs a user-language override and why the planning output needs review before /goal.

Second, the contract suggested git checkout as a rollback. In a dirty worktree, a broad checkout can overwrite changes that belong to the user or another task. Replace it with a recovery rule tied to an exact task-owned file, a recorded patch, or a clean disposable worktree. “Roll back if worse” is sensible; an unresolved destructive command is not.

Two smaller corrections improve the template:

• retain full verifier output in an artifact instead of piping the only evidence through tail -5;
• treat Leader’s 4,000-character rule as a conservative skill constraint. The ZCode Goal page we reviewed on July 28, 2026 did not state a universal 4,000-character cap for ZCode or the GLM API.

The larger lesson is simple: use the skill to expose missing decisions, then audit the commands and assumptions as if they came from an untrusted contributor.

Install and inspect Leader for ZCode

ZCode’s official Skill documentation defines a skill as a directory containing SKILL.md. User-level skills live under ~/.zcode/skills/<skill-name>/, and ZCode can also import skills detected from external agents.

For a reviewable pinned install, use a disposable clone instead of fetching mutable main files one by one:

git clone --filter=blob:none \
  https://github.com/KKKKhazix/khazix-skills.git

git -C khazix-skills switch --detach \
  1668c2c929caa2e9f510ade061b5d11f55a1a6b8

sha256sum \
  khazix-skills/leader/SKILL.md \
  khazix-skills/leader/references/anatomy.md

Expected hashes for our snapshot:

58fc7e8c5038b3f795a52985a5cd81abb4bf51075bf64705a3eaebe33cf4391b  SKILL.md
facbb9d160d506513f245fe2ad0eea0dc4a959a9573e5ae0e8c4f2f7598cc1d8  anatomy.md

Read both files. If the writable paths, rollback language, output language, and verifier rules fit your project, copy the leader directory to ~/.zcode/skills/leader/. In ZCode, open Settings → Skills, refresh, confirm the source, and enable it. The official interface invokes a skill with a $ tag:

$leader turn “make the release reliable” into one verifiable goal contract

Review the generated task book, narrow every destructive command, and then set it as the session goal with /goal. Do not silently update the skill mid-project; pinning lets a resumed task use the same rules that created its contract.

Use this eight-part goal-contract template

You do not need Leader to apply the method. This compact template preserves its most valuable controls while making the reviewer responsible for every command:

WHY
What outcome matters, and how should the agent decide an unanticipated fork?

OWNER DECISIONS
List every assumed choice, label the default, and state the cost if it is wrong.

BOUNDS
Writable path allowlist; frozen tests/evaluators; prohibited external changes.

MEASURED BASELINE
Commands actually run, dated results, hashes, and facts still unverified.

WORK
Ordered tasks with dependencies; no unrelated cleanup or opportunistic refactor.

PROOF AND ANTI-CHEATING
Exact commands and machine-readable pass conditions.
Forbid skipped/deleted tests, weaker assertions, fake dependencies, threshold edits,
and failure masking. Demonstrate one expected red result before the final green.

RECOVERY
Write progress after each unit; park unknowns; preserve user changes; after three
equivalent failures, change approach or stop. Set a hard iteration/time/token limit.

DONE
Independent verifier reruns frozen checks, confirms diff scope and hashes, and stores
real output. A confident summary is not evidence.

For a large repository, put the stable contract in version control and keep volatile logs outside the prompt. A longer context can carry more history, but prompt caching addresses repeat-input cost, not task correctness. The GLM-5.2 AI agent matrix can help choose a tested client once the goal itself is defined.

Choose Goal Mode or build the control loop

Use ZCode Goal Mode when you want the documented runtime state, automatic per-round verification, recovery, and audit trail. Use an ordinary coding agent for a short bounded task when one execution and one final gate are enough. If you need to monitor that existing desktop session from a phone, our ZCode Remote Control safety guide explains the separate window-scope, permission, link-protection, Stop, and Refresh boundaries.

A raw GLM API request is different. Chat Completions gives you model output and tool calls; your application must supply persistence, budgets, permissions, retries, diff boundaries, and an independent verifier. Our small harness did exactly enough to test one contract and nothing more. The streaming API guide shows how to reconstruct response fields correctly; the Coding Plan versus API versus self-hosting guide covers the access decision.

Run the tested GLM route

Open GLM-5.2 through Z.ai's Coding Plan

This article’s authenticated generation and execution requests used Z.ai’s GLM Coding Plan route with model ID glm-5.2. A subscription supplies model access; it does not supply a correct goal contract or replace your acceptance tests. Check current terms before buying.

View the Coding Plan on Z.ai's site ↗

Affiliate disclosure: This is an affiliate link; GLM52.ai may receive compensation after a qualifying purchase. We tested one Coding Plan account on July 28, 2026; plan eligibility, quotas, promotions, model availability, and terms can change.

We did not produce a new pay-as-you-go success result in this run. The available host credential belonged to a different key family and the global endpoint returned HTTP 401; no compatible ZHIPU_API_KEY was present. That is a credential boundary, not evidence that the pay-as-you-go endpoint is unavailable. The existing GLM-5.2 API provider guide documents the direct API route separately.

Questions about Leader.skill and GLM-5.2

Is Leader.skill an official Z.ai feature?

No. Leader.skill is a third-party open repository by KKKKhazix. ZCode Skill and Goal Mode are official Z.ai features. ZCode can load SKILL.md instructions, but that compatibility does not make a third-party skill official or reviewed by Z.ai.

Does Leader improve GLM-5.2 itself?

It changes the instructions and task contract, not the model weights, context limit, or serving stack. Our result shows better coverage of ten contract fields on one prompt. It does not establish a general intelligence or benchmark improvement.

Why is a goal contract useful with a 1M context?

Context stores working material; a contract defines purpose, bounds, evidence, and stop conditions. More remembered history does not turn a weak success criterion into a strong one. Long tasks make specification errors more expensive because the agent can pursue the wrong objective for more iterations.

Did this test run inside ZCode /goal?

No. We used the Coding Plan Chat Completions endpoint and a minimal allowlisted tool loop in Docker. We relied on official ZCode documentation for its runtime behavior and kept our separate test labeled. A native ZCode automation would need visible desktop interaction plus access to its verifier timeline, which this experiment did not provide.

Is the 4,000-character contract cap universal?

We could verify it as a rule in the pinned Leader source. We could not verify it as a universal ZCode Goal or GLM API limit in the official pages reviewed on the test date. Keeping a task book compact is useful; presenting 4,000 as a universal platform limit is not currently supported by our sources.

Can I trust a 10/10 contract score?

No. It means all ten selected fields appeared. The same output disobeyed the language request and included an unsafe rollback suggestion. Freeze the evaluator, inspect every command, preserve user changes, and let an independent process rerun the acceptance checks.

Sources, test files, and reproduction boundaries

Primary and official sources:

• Leader.skill snapshot and task-book anatomy;
• ZCode Goal Mode and ZCode Skill;
• official GLM-5.2 release and the GLM-5 agentic engineering paper;
• AI HOT discovery item, used only to find the topic—not as proof.

Original GLM52.ai evidence:

• sanitized result JSON;
• generation output, execution trace, fixture, probes, hashes, container boundary, and cleanup record in the repository’s dated evidence directory;
• a SerpAPI originality check on July 28, 2026: the result set covered generic GLM-5.2 long-horizon workflows but no direct Leader.skill goal-contract test.

This was one fixture, one deterministic generation pair, and one execution run on one account. It measures contract coverage and bounded completion—not ZCode reliability, provider uptime, multi-hour success rate, security against hostile repositories, or general model quality. Re-run the commands and review the pinned source before using the workflow on consequential code.

About the editorial role

Evan Brooks

AI Infrastructure Editor

Evan Brooks serves as GLM52.ai’s disclosed editorial pen name for infrastructure, deployment, and training guides. The role examines checkpoint size, memory math, provider limits, implementation evidence, and operational risk. The GLM52.ai Editorial Team produces and fact-checks every article under this byline.

The GLM52.ai Editorial Team accepts responsibility for this article. Read our editorial policy or request a correction.

An AI image tool created this portrait. It does not depict a real individual.