跳到正文
cccskills
免费在 GitHub 公开中文介绍

design-is

依据Dieter Rams的十项原则检查界面或产品设计,并提供有证据支持的评分,判断应新建、改进还是重新设计,再整理成用于制定执行计划的请求。

原文查看原文说明

Audit a design against Dieter Rams' ten "Good design is..." principles, then hand off a /make-plan prompt for one of three outcomes — new design, refine design, or redesign. Use when the user says "audit this design", "design review", "check this UI against Rams", "is this UI good", "critique this design", "design audit", or asks for a critique that should lead to a plan.

AI 评分80分/ 100查看安装方法

适用场景

  • 依据Dieter Rams十项原则检查界面
  • 决定改进界面还是重新设计
  • 凭证据检查界面文案与易用性
  • 将审查结果整理为make-plan请求

中文介绍

功能

依据Dieter Rams的十项原则检查界面或产品设计。检查内容包括结构、间距、字体、颜色、界面文案以及加载时的资源开销,每项原则按0至3分评分。评分附有代码位置、界面区域或测量值等证据,并据此判断应新建设计、改进现有设计还是重新设计。

适用场景

适合希望超越外观偏好,同时评估界面易用性和说明准确性的人。需要决定局部修改还是从结构上重新审视设计时,也可以使用。检查范围、证据、评分表、判断结果以及供后续规划使用的请求都会整理到文件中。

使用示例

  • “请按十项原则检查这个界面,判断应改进还是重新设计。”
  • “请把审查结果和优先改进项整理成可以交给 /make-plan 的请求。”

注意事项

该技能负责评估及向规划环节交接,不编写实现代码。收集证据时使用子代理,检查运行中的界面时使用agent-browser。若只能检查代码而没有运行环境,会将视觉信息明确标为推断。常规界面代码审查和仅修改文案的任务不在适用范围内。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

客观评估

AI 仅根据 SKILL.md 的内容,从 4 个方面进行了评估。星标数和热度不计入评估。

指令清晰度能否看出何时使用、做什么
A良好说明明确列出设计审查的使用场景,以及评分、判断和向 /make-plan 交接的任务。
步骤具体性步骤、输入输出和示例是否具体
A良好指令规定各调查代理的必填报告项、0至3分的评分格式及五个输出文件。
安全性发送数据、删除文件、执行命令等是否有说明
B部分不足指定写入 DESIGN-IS-<YYYY-MM-DD>/,但未说明如何处理已有文件。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足需要使用子代理和agent-browser,但未提供配置步骤。

总分按每项 A=25 分、B=15 分、C=5 分相加。 由 AI(OpenAI Codex)于 2026年10月21日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md18.4 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Design Is

Do not use for

  • Routine UI code reviews → use /review
  • Pure copy edits → use a separate copy pass
  • Pre-design ideation with no artifact yet → start with /make-plan directly

You are an ORCHESTRATOR. Audit a design against Dieter Rams' ten principles, score each principle with evidence, decide the outcome verdict (NEW / REFINE / REDESIGN), and hand off to /make-plan with a ready-to-run prompt.

You do not write implementation code. You produce: evidence-cited scores, a verdict, and a /make-plan handoff prompt.

The Ten Principles (Dieter Rams)

Audit each principle in this exact order. Each gets a score 0–3 and ≥1 piece of evidence (file:line, screenshot region, copy excerpt, or measured value).

  1. Good design is innovative — Does it advance the form, or imitate? Innovation rides on technology; never an end in itself.
  2. Good design makes a product useful — Does it serve the primary task? Emphasizes usefulness; disregards anything that detracts.
  3. Good design is aesthetic — Is it beautiful? Only well-executed objects can be beautiful; aesthetic quality affects well-being.
  4. Good design makes a product understandable — Does the structure clarify function? Or is it self-explanatory at best?
  5. Good design is unobtrusive — Does it stay out of the way? Neither decorative objects nor works of art — leave room for self-expression.
  6. Good design is honest — Does it claim only what it is? No false promises, no manipulation, no inflated value.
  7. Good design is long-lasting — Will it age well? Avoids being fashionable; never appears antiquated.
  8. Good design is thorough down to the last detail — Are edges, empty states, errors, focus rings, motion curves all considered? Care and accuracy express respect for the user.
  9. Good design is environmentally friendly — Does it conserve resources? Minimizes pollution — in software: bundle weight, energy, attention, cognitive load.
  10. Good design is as little design as possible — Less, but better. Concentrates on essentials; back to purity, back to simplicity.

The user wrote "Dieter Braun" — they mean Dieter Rams. Don't correct them inline; just use the right principles.

Delegation Model

Use subagents for evidence gathering (reading components, measuring contrast, counting elements, inspecting tokens, screenshotting via agent-browser). Keep scoring and verdict synthesis with the orchestrator. Reject subagent reports that score without citing evidence and redeploy.

Subagent Reporting Contract (MANDATORY)

Each evidence subagent response must include:

  1. Sources consulted — exact file paths and line ranges, or screenshot regions
  2. Concrete findings — what is present, what is missing, with quotes/values
  3. Per-principle facts (not opinions) — leave scoring to the orchestrator
  4. Known gaps — what could not be inspected and why

Output Artifacts

All artifacts go in DESIGN-IS-<YYYY-MM-DD>/ at repo root (or the project the user points at):

  • 00-scope.md — what was audited (URL, component paths, screens), input materials
  • 01-evidence.md — per-principle evidence collected by subagents
  • 02-scorecard.md — per-principle 0–3 score with one-line justification + total
  • 03-verdict.md — NEW / REFINE / REDESIGN with reasoning
  • 04-handoff-prompt.md — copy-pasteable /make-plan prompt for the chosen outcome

Phases

Phase 0: Scope Lock (ALWAYS FIRST)

Ask the user (or infer from the request) and write 00-scope.md:

  • What is being audited? (live URL, repo path, Figma frame, component name)
  • Who is the primary user, and what is the primary task?
  • Constraints (brand, stack, deadline)
  • Reference designs or competitors, if any

If the user is asking about a design that doesn't exist yet, skip Phases 1–2 and go straight to Phase 3 with verdict = NEW.

Phase 1: Evidence Gathering (FAN OUT)

Deploy subagents in parallel. Each must return ONLY the required fields below — no prose paragraphs, no scoring.

1. Structural Evidence subagent (always deploy) Required fields returned:

  • Total interactive-element count on audited surface
  • Max nesting depth of the primary component tree
  • Repeated-pattern count (same affordance appearing >1 place with the same purpose)
  • Dead-prop / unused-import count
  • File:line citations for every count

2. Visual Evidence subagent (always deploy) Mode: if target is a reachable URL or running dev server → use the agent-browser skill for screenshots and computed-style inspection. If target is a static repo with no running instance → read source CSS / tokens / component files and report inferred facts only (mark these "INFERRED"). Required fields returned:

  • Spacing scale observed (px array)
  • Type scale observed (px array)
  • Distinct color count (count of unique hex/oklch tokens actually rendered or referenced)
  • Lowest contrast ratio observed across primary text
  • States present checklist: empty / loading / error / success / focus / disabled — present or missing for each

3. Copy & Honesty subagent (always deploy) Required fields returned:

  • List of every user-facing string with file:line
  • Flagged inflations (marketing superlatives without backing)
  • Flagged dark patterns (forced continuity, hidden cost, fake scarcity, confirmshaming)
  • Flagged jargon / unclear labels with proposed plain replacement
  • Label→behavior mismatches with file:line of both

4. Weight & Friction subagent (always deploy) Required fields returned:

  • Initial JS bytes (number)
  • Network request count for primary view (number)
  • Time-to-interactive ms (number, measured or estimated with method noted)
  • Animation count on idle screen (number)
  • Notification / badge / modal count on initial load (number)

5. Accessibility Evidence subagent (OPTIONAL — deploy only if target has a meaningful interactive UI surface; skip for static landing pages without interaction) Required fields returned:

  • WCAG contrast pass/fail per text token
  • Focus order list across primary controls
  • Keyboard reachability of every primary action (yes/no per action)
  • ARIA landmark count
  • Skip-link present (yes/no)

Principle → subagent mapping (orchestrator uses this when scoring):

PrincipleFed by
#1 innovativeorchestrator-only (judgment using all evidence)
#2 usefulStructural, Accessibility
#3 aestheticVisual
#4 understandableStructural, Copy & Honesty, Accessibility
#5 unobtrusiveStructural, Visual
#6 honestCopy & Honesty
#7 long-lastingorchestrator-only (judgment using all evidence)
#8 thoroughVisual
#9 environmentally friendlyWeight & Friction
#10 as little design as possibleStructural

The orchestrator writes 01-evidence.md consolidating all subagent reports. Reject any finding without a source citation. Subagents are explicitly forbidden from scoring — only the orchestrator scores, using the rubric in Phase 2.

Phase 2: Scorecard (ORCHESTRATOR)

The orchestrator scores each of the ten principles itself — do NOT delegate scoring.

For each principle, write to 02-scorecard.md:

N. Good design is <principle> — Score: X/3
   Evidence: <one-line summary citing 01-evidence.md anchors>
   Justification: <one sentence on why this score, not the one above or below>

Per-principle scoring anchors (apply verbatim — pick the level whose signal best matches the audited surface):

#1 innovative — 3: introduces a pattern not seen in 5+ peer products and ships it with restraint. 2: refreshes an existing pattern with a clear improvement. 1: imitates competitors with minor variation. 0: copies a competitor's flow wholesale. #2 useful — 3: primary task completes in fewest possible steps; no decoy actions. 2: primary task completes but adjacent surface adds steps. 1: primary task requires unnecessary detours. 0: primary task is not directly supported on the screen audited. #3 aesthetic — 3: spacing/type/color obey a single visible system; no orphan styles. 2: ≤2 minor inconsistencies across audited surface. 1: 3–5 inconsistencies OR one jarring violation. 0: no visible system OR active visual noise. #4 understandable — 3: a first-time user names every primary control correctly. 2: 1 control needs a tooltip. 1: 2–3 controls unclear; jargon present. 0: primary action is not identifiable without help. #5 unobtrusive — 3: chrome recedes; content is the figure, UI the ground. 2: chrome visible but quiet. 1: decoration competes with content. 0: chrome dominates content. #6 honest — 3: every claim, badge, and label maps 1:1 to actual behavior. 2: ≤1 minor inflation (e.g. "powerful" once). 1: 2+ inflations OR one dark pattern. 0: any deceptive flow (forced continuity, hidden cost, fake scarcity). #7 long-lasting — 3: visual language has no dated trend markers; would read as current 3 years from now. 2: 1 dated marker. 1: 2–3 dated markers (skeuomorph residue, fad gradients, trend typography). 0: design reads as a specific year's trend. #8 thorough — 3: empty / loading / error / success / focus / disabled all present and considered. 2: 1 state missing or rough. 1: 2–3 states missing. 0: 4+ states missing or default-browser. #9 environmentally friendly — 3: initial JS <100KB, no idle animation, dark mode honored, prefers-reduced-motion respected. 2: <500KB, motion gated. 1: 500KB–2MB, motion always on. 0: >2MB OR autoplay video OR dark mode ignored. #10 as little design as possible — 3: every element earns its place; removing any one breaks the task. 2: ≤2 removable elements. 1: 3–5 removable elements. 0: page is dominated by decoration or duplicated affordances.

Scoring rules:

  • Tie-breaker rule: When uncertain between two scores, pick the lower one. Convergence > generosity.
  • Score worst, not mean: When a principle has multiple representative instances on the audited surface, score the worst instance — not the average.
  • No bonuses, no weights: Scores stay 0–3 integer. Principles are equally weighted. Total is sum of ten scores, max 30.

Phase 3: Verdict (ORCHESTRATOR)

Write 03-verdict.md with one of three verdicts, chosen by these rules:

  • NEW DESIGN — No design exists yet, OR the existing artifact is a stub/wireframe with no real decisions to preserve.
  • REFINE — Total score ≥ 20 AND no individual principle scored 0. The bones are good; iterate.
  • REDESIGN — Total score < 20, OR any principle scored 0 on a load-bearing dimension (typically #2 useful, #4 understandable, or #6 honest). Start over from purpose.

State the verdict in one sentence. Then list the 3–5 highest-leverage moves — each tied to a specific principle and evidence anchor. These become the spine of the next phase's plan.

Anti-patterns to reject in your own verdict:

  • Recommending REFINE because the codebase is large (sunk cost is not a design principle)
  • Recommending REDESIGN because a single screen is ugly (scope it)
  • Recommending NEW when an honest REDESIGN is warranted (don't dodge the critique)

Phase 4: /make-plan Handoff

Write 04-handoff-prompt.md containing exactly ONE fenced /make-plan prompt matching the verdict. The prompt must be self-contained — the next session won't see this audit unless it's quoted in.

Use the matching template below. Fill every <bracket>. Include the top 3–5 moves from Phase 3 verbatim, each with its evidence anchor.

Quote-in step (mandatory, applies to all three templates below): Before emitting the handoff, replace EVERY <bracket> placeholder with concrete content from the audit. Inline the verdict paragraph from 03-verdict.md and the top 3–5 moves verbatim into the template. Do NOT leave bare references like "see DESIGN-IS-.../03-verdict.md" — the next session won't have file access to the audit. The emitted handoff must be readable and actionable with zero external lookups.

Template: NEW DESIGN

/make-plan Design <product/screen/component name> from scratch.

Primary user: <who>
Primary task: <one sentence>
Constraints: <brand, stack, deadline, accessibility floor>

Non-goals (do not design these now):
- <explicit out-of-scope item 1>
- <explicit out-of-scope item 2>
- <explicit out-of-scope item 3>

Reference principles to optimize for, in order:
1. Useful (#2) — <what useful looks like here>
2. Understandable (#4) — <what clarity looks like here>
3. As little design as possible (#10) — <what restraint looks like here>

Deliverables for the plan:
- Information architecture (one screen map or component tree)
- Primary flow wireframe (low-fi, labeled)
- Token decisions (type scale, spacing scale, color count cap)
- States checklist (empty, loading, error, success, focus, disabled)
- Honesty audit on every user-facing string before ship

Anti-patterns to guard against (specific to NEW):
- Decoration without function
- Novel interactions without precedent
- Copy that overpromises
- Designing for screens the Non-goals list excluded

Template: REFINE DESIGN

/make-plan Refine <product/screen/component name> based on a Dieter Rams audit (total <X>/30).

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Keep (already strong, do NOT touch in this pass):
- Principle #<N> (<name>) scored 3 — Evidence: <file:line or anchor>. Regression check: <what to grep / re-test to confirm it still scores 3 after the refine>.
- <repeat for every principle that scored 3>

Fix in priority order (top 3–5 moves from the audit, verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
4. <optional 4th>
5. <optional 5th>

Out of scope for this refine pass: <explicit list — what NOT to touch>

Deliverables for the plan:
- Per-fix: target files, exact change, verification step
- Token/spec changes consolidated in one place
- Regression checklist for every "Keep" item above

Anti-patterns to guard against (specific to REFINE):
- Adding new abstractions where a direct change suffices
- Restyling areas that already scored 3
- Scope creep into structural redesign (if structure must change, this should be REDESIGN, not REFINE)
- Letting fixes mutate principles outside the priority list

Template: REDESIGN

/make-plan Redesign <product/screen/component name>. Current design failed audit at <X>/30 with critical gaps in principles <comma-separated list of 0-scored or 1-scored load-bearing principles>.

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Why redesign and not refine: <one sentence — usually a load-bearing principle (#2, #4, or #6) scored 0, or total is below threshold>

Preserve from current design (MUST be non-empty — at minimum, name the brand tokens):
- <specific element 1, with file:line>
- <specific element 2, with file:line>
- (if structurally nothing survives, write: "Brand tokens only — color palette and logo. Discard everything else.")

Discard (MUST be non-empty — name the structural patterns causing the failures):
- <pattern 1>. Evidence: <file:line>. Caused failure on principle #<N>.
- <pattern 2>. Evidence: <file:line>. Caused failure on principle #<N>.

Top 3–5 moves from the audit (verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line>.

Redesign principles in priority order:
1. <Principle # — name> — <what success looks like>
2. <Principle # — name> — <what success looks like>
3. <Principle # — name> — <what success looks like>

Deliverables for the plan:
- New information architecture (not derived from old)
- New primary flow (low-fi, labeled, compared side-by-side to current)
- States checklist (empty, loading, error, success, focus, disabled)
- Migration path for users currently on the old design
- Cutover criteria (when is the old design retired)

Anti-patterns to guard against (specific to REDESIGN):
- Porting old structure under new styling
- Keeping both designs behind a flag indefinitely
- Redesigning to follow a trend rather than the principles above
- Treating the Preserve list as optional — it must be filled before this handoff is valid

Key Principles (for the auditor)

  • Evidence over taste — every score cites a source; "feels wrong" is not a finding
  • Score what is, not what was intended — design is what ships, not what was drawn
  • Honesty applies to the audit too — if total is 28/30, say REFINE even if the user wanted a redesign; if it's 12/30, say REDESIGN even if the user wanted a refine
  • One verdict, not three — pick NEW or REFINE or REDESIGN; do not hedge
  • Handoff, don't implement — design-is ends at the /make-plan prompt; /make-plan and /do take it from there
  • Verdict commitment — Once 02-scorecard.md is written, the verdict follows the Phase 3 rule mechanically. Never re-score to back into a preferred verdict; if the scorecard says REDESIGN, the handoff is REDESIGN.

Failure Modes to Prevent

  • Scoring from screenshots alone without reading the code — redeploy with structural subagent
  • Scoring the codebase instead of the design — re-anchor on user-facing evidence
  • Awarding 3s generously to soften the verdict — recalibrate against the per-principle anchors in Phase 2
  • Producing a handoff prompt that doesn't quote the verdict and top moves — the next session is blind without them
  • Skipping Phase 0 scope lock — auditing the wrong surface wastes Phase 1
  • Sunk-cost reasoning — recommending REFINE because the codebase is large; sunk cost is not a design principle
  • Hedging across verdicts — "could be REFINE or REDESIGN depending on..." — pick one
  • Score inflation to match a desired verdict — score the evidence, then read the verdict off the rule
  • Letting Phase 0 user preference override Phase 3 evidence — the user can disagree with the verdict, but the audit reports what the evidence says

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Agent Cost Report

免费有简介AI 评分 90分

根据代理工作记录和词元数量,整理每项已完成成果及返工的费用,区分估算金额与实测支出,并生成附有依据的 HTML、JSON 和 CSV 报告。

  • 核对每周支出与完成成果
  • 比较每项已完成成果的费用
  • 调查重复工作与返工费用
thedotmack/claude-mem10.2万2026年10月22日 更新

babysit

免费有简介AI 评分 80分

持续跟踪拉取请求的评审和自动检查,核实反馈是否适用于实际代码,反复修复、测试并推送,直到待处理问题与未解决讨论清零,达到可合并状态。

  • 监控拉取请求的自动检查
  • 核实评审反馈并修复问题
  • 检查合并前的未解决事项
thedotmack/claude-mem10.2万2026年10月22日 更新

build-and-release

免费有简介AI 评分 60分

将编码任务交给子代理,依次执行build、合并已准备好的拉取请求,再从更新后的main进入release,把实现与发布工作连接起来。

  • 委托从实现到发布的完整任务
  • 衔接拉取请求合并与发布工作
  • 连续执行build和release
thedotmack/claude-mem10.2万2026年10月22日 更新

ccs-align

免费有简介AI 评分 90分

检查本地claude-mem运行状态,更新各用户的重要记录缓存,支持排除和恢复记录,并报告不同层级的规则冲突,适合定期运维。

  • 检查运行状态并更新重要记录
  • 保留原始历史并排除缓存记录
  • 恢复已排除的记录
thedotmack/claude-mem10.2万2026年10月22日 更新

childhood

免费有简介AI 评分 90分

发布后核查公开软件包、线上服务和已安装插件,持续跟踪延迟到达的持续集成结果及故障报告,确认问题是否由此次发布引起,并在授权范围内修复。

  • 检查已发布软件包的内容
  • 验证线上环境的变更路径
  • 确认已安装插件的版本
thedotmack/claude-mem10.2万2026年10月22日 更新

claude-mem-install

免费有简介AI 评分 90分

为Grok Bot安装claude-mem,建立收集工作记录的环境。除默认的本地worker与CMEM Pro配置外,也介绍可选的host-login配置及远程连接。

  • 为Grok Bot添加记忆功能
  • 配置本地worker与CMEM Pro
  • 安装可选的host-login配置
thedotmack/claude-mem10.2万2026年10月22日 更新

查看 thedotmack 的全部技能

报告此技能的问题