zcode-glm-fleet

The knowledge layer for the learning loop. Explains how to read and act on the work-pattern snapshot that glm-learning-loop injects at SessionStart — what the verification ratio means, what tool over-reliance signals, how to adapt behavior based on past-session telemetry. ROUTE BY INTENT — load when the model receives a work-pattern snapshot and needs to interpret it, when the user asks "how do I work?" / "내 작업 패턴 뭐야" / "am I verifying enough?", or when adapting this session based on past behavior. Also load when the user wants to inspect or clear the telemetry that drives the loop. NOT a stats viewer (that's /session-stats) — this is the interpretive layer that turns numbers into behavioral change.

Detect the current repo's tech stack from its manifest files and recommend which ZCode skills, MCP servers, and plugins fit. Reads package.json (Node: React/Next.js/Vue/Svelte/Express/Nest), pyproject.toml + requirements.txt (Python: FastAPI/Django/Flask), go.mod (Go: echo/gin/fiber), Cargo.toml (Rust: axum/actix/tokio), pom.xml + build.gradle (Java: Spring/Maven/Gradle), composer.json (PHP: Laravel/Symfony), Gemfile (Ruby: Rails/Sinatra). ROUTE BY INTENT, NOT KEYWORDS — load when the user starts a new project ("이 레포 스택 뭐야", "what stack is this", "어떤 기술 쓰지", "set up for this repo"), asks for tooling recommendations, or when a fresh session needs to orient on an unfamiliar repo. Also load proactively at session start on an unfamiliar repo — orienting on the stack is step zero. Returns a stack fingerprint (language + framework + package manager + test runner + notable deps) + a recommendation table (skill/MCP/plugin → why it fits → install hint). Does NOT auto-enable anything — it recommends, the user decides.

JUDGE whether an already-rendered UI surface is good enough to ship — quality evaluation of something that EXISTS, not creation of something new. GLM-5.2 has no vision, so judgment runs on Playwright-MCP computed-style probes (getComputedStyle JSON: fontSize / color / padding / gap / contrast), not on eyeballing pixels. Scores 7 dimensions PASS/FAIL (visual hierarchy / spacing-rhythm / alignment / contrast+WCAG / density / design-token conformance / DESIGN.md-tone) + runs a 13-tell "AI-slop" gate (warm-cream hero, near-black+neon, Inter-only, white+purple, uniform sizing, vague headlines, scattered motion…). ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to evaluate quality of a built surface, including indirect signals: a shared screenshot the user reacts to with dissatisfaction, hesitation, or silence; "이거 이상하지 않아?", "괜찮아?", "어때"; a ship/no-ship decision moment ("출시해도 돼?", "이대로 갈까?"); any qualitative complaint about a rendered screen ("AI스러워", "올드해", "트렌디하지 않아", "이탈하고 싶어져"); explicit revie

CONVERGE an EXISTING rendered UI surface to good craft through a closed measured loop — judge → fix-list → edit code → HMR re-render → re-judge → repeat until PROCEED or a 3-round cap. Probe-driven (Playwright-MCP computed-style JSON), not eyeballing, because GLM-5.2 has no vision. Inlines the 7-dim rubric + 13-tell slop gate so a surface can be converged in-loop. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to REPEATEDLY IMPROVE a built surface until it is good, including indirect signals: "이거 계속 비슷해" (a prior one-shot fix did not land), "쓰레기 UI 고쳐", "UI 다듬어", "개선 루프 돌려", "craft 올려", "make this converge", any vibe that one-shot review is not enough and the user wants to iterate to satisfaction. NOT for designing a new screen from JTBD (that is ux-design-baseline). NOT for a single quality verdict (that is design-craft-rubric — judge once). NOT for runtime mechanics.

PRODUCE the design intent for a UI feature that does not yet exist — the design thinking BEFORE code. Frames the job-to-be-done (what user behavior change, measured how), grounds in the repo's DESIGN.md + FLOWMAP, audits the current-state surfaces with a severity-scored findings table + cognitive walkthrough, DECIDES craft forks with conviction (north-star default shown — never dumps an a/b menu on the user), and produces a durable design.md (9-section template, slim/full tier). Repo-agnostic: each repo's DESIGN.md owns tone, each repo's FLOWMAP owns the flow map. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to FIGURE OUT the design for something to be built, including indirect signals: a feature request that needs design thinking before code ("이 기능 만들어줘", "이 화면 추가하자"), a "how should this work?" question about user flow, a request for a wireframe or design doc, any moment where the user wants to decide what to build before building it. NOT for judging an already-rendered surface (that is d

Enforce the "no premature done" discipline. Before claiming a task is complete, the model MUST produce real evidence — a test run with passing output, a real DB query result, a rendered screenshot, a build that compiles, a command's actual stdout. "200 OK" alone, fake fixtures (fake JWT, synthetic audio), or code-inference without execution are NOT evidence. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the model is about to say "done", "complete", "fixed", "finished", "완료", "구현 완료", or any completion claim, OR when the user asks "did it work?", "are you sure?", "진짜야?", or expresses doubt about a claim. Also load when a conclusion lacks a quantitative basis (test count, response time, measured value). Returns either evidence (command + output / test result) or an explicit "확인 불가" (cannot verify) verdict with the missing evidence named. NOT a code editor — it produces or demands evidence, never edits code.

Architecture Decision Record template + when to write one. An ADR is a short markdown record of a significant architectural decision, its context, and its consequences — durable history that answers "why is it like this?" months later. ROUTE BY INTENT — load when making a non-obvious architectural decision ("이걸 왜 이렇게 했지?" later, "should we use X or Y for..."), when a decision is hard to reverse, or when you need to look up why a past choice was made. NOT for implementation details (that's code comments) or ephemeral task notes (that's a spec).

How to author a ZCode SKILL.md that triggers reliably and stays lean. The format, the description discipline (route-by-intent, not keywords), progressive disclosure (metadata → body → bundled files), and the anti-over-build stance (delete guidance that isn't pulling its weight). ROUTE BY INTENT — load when writing a new skill, revising an existing one, turning a repeated workflow into a skill, or debugging why a skill doesn't trigger. NOT for authoring plugins/hooks (those are separate).

When a task needs a spec (and when it doesn't), the slim/full tier scaffold, and the spec lifecycle. A spec is a durable record of WHAT was built and WHY — it survives compaction and session boundaries. ROUTE BY INTENT — load when starting a multi-step task ("이거spec 만들자", "spec for this feature", starting work that will span multiple commits/sessions), when deciding whether a task is big enough to spec, or when resuming work from a prior spec. NOT for tiny one-off fixes (a spec on a 1-line typo fix is net-negative ceremony).