No need to type prompts โ the agent reads the intent itself and runs the whole course on its own:
a strong plan โ a verified implementation loop โ a security & QA review. A ZCode harness.
the journey
No plan is born warm. Somewhere up on the ridge, in the only light for miles, a forge burns โ and every line of code glm-hammer ships is struck there, under the snow, with the receipt to prove it.
An LLM agent's "done" is just a claim until it is verified. glm-hammer hands judgment to independent sub-agents, cross-checks that judgment against the evidence files (receipts) left on disk, and if a gate isn't met, hooks block the turn from ending at all. Instead of trusting the agent's diligence, the structure enforces it.
The main agent is only an orchestrator. The maker (worker), the one who judges the contract (validator), the one who hunts for cheating (critic), and the one who attacks the result (reviewer) are all separate sub-agents โ none of them can see each other's output.
Every judge writes its verification report directly to .glm-hammer/evidence/ and closes with EVIDENCE_RECORDED. If the state file's claim and the receipt disagree, the hook blocks the turn from ending.
Instead of an open-ended summary, the judge answers a fixed yes/no checklist. "If you didn't verify it, you may not say YES." The VERDICT is derived mechanically as the AND of the answers โ not a feeling.
There are only two places a human steps in โ when answering a question and when approving the plan. The loop handles the rest.
Since the route-intent hook reads your prompt and routes on its own, you never need to memorize skill names. The rule: ambiguous or touching 4+ files โ forge; small and clear โ blueprint; plan already in hand โ hammer.
A lightweight plan for small, clear jobs (โค3 files). Same format as forge (binary acceptance criteria, verification strategy, symbol anchors) but a strict Self-Review replaces the critic panel. If it discovers hidden complexity, it promotes itself to forge.
Before asking a single question, it dispatches 2โ4 Explore sub-agents to recon the codebase. Anything recon can answer is never asked. After the draft, three critics verify against the real codebase โ a revision loop until all approve.
Per task, a three-way check: worker โ validator (information isolation) โ implementation-critic (cheat detection). Once everything is done: the E2E gate โ a parallel security/QA review. A FAIL becomes a fix task and loops back.
It splits the work into four concerns โ structure / existing patterns / interface boundaries / verification infrastructure โ and dispatches parallel Explore sub-agents. Before asking the user anything, it exhausts everything the code itself can answer.
Only the ambiguity recon couldn't resolve, cited against recon results, bundled into at most four independent questions in a single round. If no answers are needed, it asks nothing and moves on.
Saved to docs/glm-hammer/plans/. Every task is a Goal + dependencies + a list of symbol-anchor files + binary acceptance criteria with no room for interpretation + steps that hold real code. A placeholder counts as a plan failure.
Three critics attack the plan in parallel: feasibility (can it be built as written?), integration (will it assemble and run?), coverage (does it cover every requirement?). Each leaves a receipt; a single REJECT means a revision โ full panel re-review. The instant the plan file is edited, the plan-gate hook resets approvals to zero, so re-review is enforced, not optional. Past 3 rounds, it escalates to the user.
It presents the plan with a summary and asks exactly one thing: "Shall we proceed with hammer?" โ on approval, hammer picks it up immediately.
The worker implements per the plan (a step that clashes with reality is minimally adapted, then reported). The validator, having never seen the worker's output, judges each acceptance criterion from the plan text alone as an isolated yes/no. On pass, the implementation-critic hunts what the validator couldn't see โ stubs, test-shaped hardcoding, swallowed errors, tests that verify nothing.
A failure is triaged first: a worker defect means a rework carrying all accumulated feedback; a plan defect means editing the plan file itself (an Amendment Log is recorded; loosening a criterion is forbidden as reward hacking). After three failures on one task, it escalates to the user.
Once all tasks are done, it runs the plan's verification-strategy command plus the full test suite. The raw output is saved to evidence/e2e.md โ without this receipt, the stop-gate will not let it pass.
Two reviewers attack the changed code in parallel โ security goes after injection / auth / secret keys / exposure, QA goes after real behavior / edge cases / regressions / test adequacy, each on its own binary checklist. A blocking finding becomes a fix task that must re-run the entire task cycle, and after the fix both the E2E gate and the review panel are re-run in full.
Once a skill writes state to .glm-hammer/state.json, a hook cross-checks that state against the evidence on disk and enforces the gate. Verified configuration against the ZCode-installed engine.
| Hook | Event | Role |
|---|---|---|
session-start | SessionStart | On finding an unfinished run, injects a resume briefing โ automatic return after a restart or compaction, with no "continue" needed. |
route-intent | UserPromptSubmit | If it's a work request, injects a forge/blueprint/hammer routing directive; if work is in progress, reminds of the current state. |
plan-gate | PostToolUse | During forge, detects a plan-file edit โ resets critic approvals to zero, forcing a full panel re-review. |
comment-checker | PostToolUse | Detects AI-slop comments: elision markers ("... existing code ..."), change narration, placeholders โ orders an immediate fix in the same turn. |
edit-diagnostics | PostToolUse | LSP-lite: an instant syntax check on edited files (JS/JSON/Python) โ catches a broken file right at the edit, not at the E2E gate. |
stop-gate | Stop | Cross-checks the state's claims against the evidence receipts โ if a gate isn't met, it blocks the turn from ending, and hardens its directive tone with each repeat. |
A completion claim in state.json is not trusted. A receipt left on disk by the judge itself is what opens the gate.
.glm-hammer/evidence/
โโโ critics/round-<N>/<critic>.md # VERDICT: APPROVE ร3 required
โโโ tasks/task-<i>/validator.md # VERDICT: PASS
โโโ tasks/task-<i>/critic.md # VERDICT: APPROVE
โโโ e2e.md # E2E gate raw output
โโโ reviews/{security,qa}.md # VERDICT: PASSEscape hatches are designed in too: a legitimate user escalation (awaiting-user), a concession after 6 blocks, and an unblock when context pressure is detected. The evidence-gate and session-recovery patterns are borrowed from lazycodex (OmO).
Reflecting the observation that an LLM judge is more reliable on binary questions than on open summaries, all six judges rule on fixed checklists.
CHECKS:
- C1: YES โ real implementation exists in every function
- C2: NO โ parse() has a branch tuned to the test
input only (utils.js:42)
- C3: YES โ every new test can fail
- C4: YES / C5: YES / C6: YES
VERDICT: REJECT โ automatic if any NO
FINDINGS:
- [REJECT-level] criteria-shaped
hardcoding at utils.js:parse ...Answer each question only YES / NO / N-A, and attach a one-line basis (what you verified).
YES Only when verified directly with a tool. If you didn't verify it, you may not answer YES โ verify it, or answer NO.
NO Must come with a matching finding (file ยท symbol ยท evidence).
VERDICT = the AND of all answers. No partial credit, no "almost there," no conditional pass. The verdict is computed, not felt.
Requirement: Node.js 18+ (to run the hook scripts; must be on your PATH).
Settings โ Plugin Management โ add a custom marketplace โ register the GitHub repo
tmdgusya/glm-hammer (or your local clone path if you're developing) as a source โ install glm-hammer.
After install, check the plugin detail to confirm all 6 hooks show as runnable.
claude plugin marketplace add tmdgusya/glm-hammer
claude plugin install glm-hammer@glm-hammerAfter install, just talk to it the way you normally would โ a single line like "build the checkout module properly" is enough for the router to fire forge, and after one plan approval you won't need to touch anything until the completion report.