What needed solving.
Background coding jobs need an inspectable lifecycle. A running process, an accepted message, and completed work are different states.
- 01Scoped task
- 02Durable worker + bounded observations
- 03Evidence + integrated change
Simplified from the implementation and project notes.
How it fits together.
The GLM subagent server exposes tools through MCP and validates inputs with Zod. Jobs have persistent records and append-only events; JSON state is written to a temporary file and renamed atomically.
Worker identity includes process metadata, and log tails are bounded to prevent a long-running job from flooding the caller. Write-enabled jobs validate their working directory against Git context.
The surrounding workflow guidance assigns each concurrent writer an isolated checkout, preserves unrelated work, and coordinates heavy checks through a machine-wide gate. This is operational tooling around agents, not a replacement for source control or test infrastructure.
Inside the software.
A local agent operations toolkit: GLM-powered delegated Claude Code jobs and shared personal instructions that standardize safe edits, checks, delivery, and proposal workflows. Skills and operational docs are instructions, not a hosted product UI.
GLM subagent MCP service
An MCP server exposes a local job interface for delegating read-only or write tasks to a GLM-backed Claude Code worker.
Node ESM server uses MCP SDK/Zod, persists jobs under the user's local data directory, and starts a separate worker process.
Present in the reviewed source.
Implementation references
glm-subagents/server.mjsglm-subagents/package.json
Read-only jobs and isolated write worktrees
Delegated tasks can inspect in place or request a write task in a Git worktree, keeping changes separate from the original checkout.
Server verifies directory/repository boundaries, creates ignored `.claude/worktrees` location for write tasks, and records job metadata; worker prompt distinguishes read-only from write mode.
Present in the reviewed source.
Implementation references
glm-subagents/server.mjsglm-subagents/worker.mjs
Job lifecycle, cancellation, and recovery
Jobs expose progress and terminal state, support cancellation, and reconcile stale workers after process exit instead of leaving runs indefinitely active.
Worker identity includes PID and process start time, cancellation markers are persisted, and atomic JSON writes record job/event transitions.
Present in the reviewed source.
Implementation references
glm-subagents/server.mjsglm-subagents/worker.mjsglm-subagents/test/effort.mjs
Keyring credential isolation and bounded worker environment
The service reads its GLM key from the desktop keyring and passes it to a worker with a deliberately reduced environment.
`secret-tool` lookup scopes the key to GLM subagents; worker gets fixed Z.AI base URL/model variables and allowlisted environment fields, with bounded diagnostics and event records.
Present in the reviewed source.
Implementation references
glm-subagents/server.mjsglm-subagents/worker.mjs
Machine-wide heavy-check gate
A shared wrapper admits one expensive check at a time and returns a busy result instead of silently starting duplicate project-wide work.
`bin/heavy` coordinates active processes and exposes status; repo guidance assigns queue ownership and explicitly treats busy exit 75 as not-run.
Present in the reviewed source.
Implementation references
personal-agent-skills/bin/heavypersonal-agent-skills/global/checks.mdpersonal-agent-skills/README.md
Persistent instruction proposals
Agent instruction changes can be proposed in durable local state and reviewed explicitly; the proposal tool does not apply changes automatically.
`agent-proposals` stores proposals under local state and keeps acceptance/rejection separate from proposal creation.
Present in the reviewed source.
Implementation references
personal-agent-skills/README.mdpersonal-agent-skills/bin/agent-proposalspersonal-agent-skills/global/AGENTS.md
Reusable specialist workflows
The skill library packages repeatable workflows for diagnosis, orchestration, agent-facing writing, visual parity, and other focused tasks.
Each skill is a directory with scoped trigger guidance and optional agent metadata/scripts; skills are linked into host user directories.
Present in the reviewed source.
Implementation references
personal-agent-skills/skills/diagnosing-bugs/SKILL.mdpersonal-agent-skills/skills/orchestration-status/SKILL.mdpersonal-agent-skills/skills/writing-for-agents/SKILL.mdpersonal-agent-skills/skills/visual-parity/SKILL.mdpersonal-agent-skills/README.md
Building and checking it.
A job is launched with an explicit scope, monitored through durable state, and handed back with evidence. The primary agent remains responsible for integrating changes and validating affected callers.
The recurring design choice is to make state and authority visible: stable job IDs, bounded observations, separate checkouts, and explicit completion criteria.
These are local tools and conventions. They do not establish a secure multi-tenant execution service or guarantee the correctness of generated changes.
Source notes
Based on repository code and project records reviewed on October 30, 2026. Historical checks are described as recorded, not rerun for this article. Screenshots, renders, and mockups are labeled individually.
glm-subagents/server.mjsglm-subagents/worker.mjspersonal-agent-skills/global/delivery.mdpersonal-agent-skills/global/checks.md