ux-design-baseline

스타0

포크0

업데이트2026년 7월 6일 05:12

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

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

jhlee0409

jhlee0409/zcode-glm-fleet

GitHub 저장소 열기 Creator 저장소 보기

다운로드

관련 직업SOC

SOC 직업 분류 기준

웹·디지털 인터페이스 디자이너컴퓨터 및 수학직·SOC 15-1255

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

work-pattern-memory

jhlee0409/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.

2026-07-060

stack-detect

jhlee0409/zcode-glm-fleet

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.

2026-07-060

design-craft-rubric

jhlee0409/zcode-glm-fleet

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

2026-07-060

ui-iterate

jhlee0409/zcode-glm-fleet

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.

2026-07-060

verify-before-claim

jhlee0409/zcode-glm-fleet

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.

2026-07-060

adr-template

jhlee0409/zcode-glm-fleet

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).

2026-07-060

name

ux-design-baseline

description

UX design baseline — procedure + template + cognitive walkthrough + severity

The producer-side UX knowledge for designing a feature before code. Lifted into a skill so the procedure loads only when actually designing. Repo-agnostic — works on any repo; each repo's DESIGN.md owns tone, each repo's FLOWMAP.md (if present) owns the flow map. The procedure itself is universal.

Why this skill exists (the failure it prevents)

Three failure modes that happen even when every mechanical step is right:

Research → defer, not conviction. After deep research the main context hands a design-craft fork back to the user ("우측 패널을 어떻게 처리할까요?"). The research already pointed at the answer. → decide craft forks with conviction.
Surface plumbing, flow-incomplete. Page A redesigned but adjacent page B stayed stale. → every affected flow surface accounted for.
Design = ephemeral chat prose. Died at compaction boundaries. → durable design.md.

The 5-step design procedure (mandatory)

Ground first — never infer the current state from code alone.

(a) Framing — JTBD + measurable success metric + current friction

JTBD in one line: 사용자가 ___ 할 때 ___ 하고 싶다, because ___ + a measurable success metric + the current drop-off / friction point. No measurement → "확인 불가"; do not guess a number.

Outcome-not-output HARD REJECT. If the root goal is a feature / output ("슬라이드쇼 모드 추가") rather than a measurable user BEHAVIOR change ("사용자가 한 세션에 영상을 publish 한다"), REJECT and reframe before any UI sketch. The design.md §① 3 blanks (business objective / measurable result / which user problem) cannot be left empty.
POV + reframed HMW. One-line user-context POV (누가 / 어떤 상황에서 / 무엇이 필요한데 왜 못 채우나) + ≥1 reframed How-Might-We that does NOT pre-commit to the current (broken) UI — reframe the problem, not the existing plumbing.

(b) Grounded research — existing context FIRST, WebSearch for delta ONLY

Read the matching DESIGN.md (the repo's tone definition), the matching FLOWMAP.md (if present — the repo's flow map), and any related spec/design.md or existing design docs in that repo. THEN WebSearch only the industry-standard / pattern pieces not already in that context. Re-running a full research sweep every call is BANNED. Cite every finding (URL / doc / file:line).

Evidence vs assumption split. Separate "evidence I have" (cite repo log / transcript / DB / analytics — real usage) from "assumptions I am making" (untested). External research numbers are borrowed analogies — label them "borrowed, unproven on this repo", never canon.

(c) Current-state audit — QUALITY DIAGNOSTIC, not reuse inventory

Output is a severity-scored findings TABLE (one finding per row), not prose:

[finding | surface:location (file:route) | evidence (cite FLOWMAP node /
 DESIGN.md token / grep) | severity 0-4 | proposed fix]

Severity anchors (observables, not vibes):

Score	Meaning
0	cosmetic
1	minor friction with a workaround
2	noticeable friction, user fumbles
3	partially blocks the task or forces a retry
4	blocks the user from completing the task

Gate the full table to redesigns touching ≥2 flow surfaces (failure-#2 class); single-component tweak skips it. Single-rater (self-score) — do NOT mandate two-pass + affinity clustering or 3-rater mean.

The findings are GENERATED by a cognitive-walkthrough: draw the first-time-user persona + happy-path action sequence FROM THE REAL FLOWMAP (not invented). At each step ask the 4 questions:

Will they try the right action?
Will they notice it's available?
Will they associate it with their goal?
After acting, will they see progress (feedback)?

Each "no" = one row in the table, feeding design.md §④ + §⑤. Then inventory reusable components — a "new component" is allowed only after you prove no existing one fits.

(d) Decide with conviction — north-star default + consequence check

Commit a north-star default and show it (ASCII wireframe / component tree / render instruction). Do not hand craft forks back to the user as a vague a/b menu.

Default-consequence check: if executing the default makes a new paid/external call, loses/drops data, changes a pricing/availability/brand claim, or is irreversible → it is genuine, escalate — even if it looks like layout/copy/transition/empty-state craft. Otherwise escalate ONLY a genuine fork (business / brand / data-model / irreversible). Handing a harmless design-craft fork ("which panel layout?") back to the user is BANNED — that is failure #1.

§5.1 consequence-override checklist (auditable): per committed north-star default, write a row in design.md §5.1 (4-column Y/N grid → craft-decided / ESCALATED). An unrecorded "escalate: none" is not acceptable. Mandatory in BOTH tiers — a tiny change can still trigger a paid call.

Decide by RANKING, not absolute scoring. Rank ≥2 clearly-different directions with conviction. BANNED: emitting or thresholding any single absolute LLM numeric quality score (e.g. "이 디자인 8.5/10"). HARD BANNED: NO final verdict on cross-screen flow journeys — cross-flow judgment defers to FLOWMAP.md + runtime verification. Diagnose and rank within a surface.

(e) Produce design.md — 9-section template + tier selection

Fill all 9 sections (tier gates which ones). Silent omission of an adjacent surface is BANNED (failure #2). Every severity 3-4 finding must be resolved by the design (§5) + appear as an acceptance criterion (§8), OR be explicitly scoped-out (§9).

design.md — durable artifact

Deliverable: a design doc that shares the repo's spec lifecycle. Convention varies by repo (specs/<slug>/design.md, docs/design/<feature>.md, or repo-specific). When unsure, ask the user or follow the repo's existing pattern.

9 fixed sections:

§	Section	Notes
①	Problem & JTBD	outcome-not-output 3 blanks
②	Success metric	ODI shape bound to real FLOWMAP node or analytics event
③	Research findings	cited
④	Current-state audit	diagnostic findings table (severity 0-4) + 4-question walkthrough + component inventory
⑤	The design	IA / flow before→after asserted vs DESIGN.md token + FLOWMAP / layout / component reuse map / new-component justification / all states incl. empty·error·edge
§5.1	consequence-override checklist	both tiers, the safety field
⑥	Alternatives rejected	falsifiable — ≥1 rejected OR explicit forced-solution line
⑦	Accessibility	WCAG, N/total split, honest N=0 where no tool
⑧	Acceptance criteria	severity 3-4 findings each map here or scope-out
⑨	Flow-surface checklist	every affected FLOWMAP surface marked redesign or scope-out (if no FLOWMAP, every affected route)

Tier selection:

Slim tier (single-surface change / internal experiment): fill §1 + §4 (key findings — full table NOT required) + §5 + §5.1 (always). Mark the rest "N/A — slim tier".
Full tier (gate: redesign touches ≥2 flow surfaces OR any public-facing surface = real users): all 9 sections, full severity table, full §9 checklist.
§5.1 consequence-override checklist is mandatory in BOTH tiers.

Output format

BLUF header mandatory:

결론 (3줄)
- JTBD / 성공지표: <1줄>
- 채택 디자인 (north-star): <1줄 — 보여준 것>
- escalate fork: <genuine fork N건 또는 "없음 — 전부 디자인이 결정">

The escalate-fork count MUST be backed by the §5.1 consequence-override checklist — a bare "escalate: 없음" without the filled checklist is not acceptable. Then the 9-section design.md body inline. Concrete only — "대비비 3.2:1 (AA 4.5:1 미달)" not "대비 낮아 보임". No design-craft fork dumped on the user.

BANNED

Edit UI code or DESIGN.md / FLOWMAP.md. You produce the design; the builder builds it. You read DESIGN.md / FLOWMAP.md as compliance references, you do not rewrite them.
Defer a layout / scroll / button-reachability problem as "위험" — core requirement.
Dump a design-craft fork on the user. Craft forks are decided with conviction and shown. Only genuine forks (business / brand / data-model / irreversible) escalate.
Emit a single aggregate design score. A rolled-up number is not actionable — per-dimension PASS/FAIL + a fix list is.