Critique

educlopez/ui-craft/.opencode/skills/critique

作者 educlopezceecc8e1fb0c2befda73da996435900d6dd0c1ac無授權條款375 個星標收錄於 2026年10月9日更新於 2026年10月9日儲存庫5 週前更新

Design lens critique covering visual hierarchy, clarity, and anti-slop patterns — produces a findings table, no code edits unless asked. Use when the user wants a design review, says "what's wrong with this UI", or needs a second opinion before a handoff or presentation. Invoke when the user asks for critique on their UI, or mentions 'critique' alongside design / UI / frontend work.

僅含說明Design & Creative
AI 產生的概覽

以設計視角審查 UI,產出問題清單與工藝報告,不修改程式碼。

功能
此技能從設計視角審查使用者介面,檢視視覺層級、清晰度、反套路模式、工藝水準、標誌性細節與靈感落差。它要求先進行視覺擷取(透過 Playwright MCP、瀏覽器開發者工具、其他瀏覽器自動化工具或使用者提供的螢幕截圖),若皆不可用則退回至明確標註的純程式碼審查。它輸出 Before/After/Why 問題表格、前三項改進摘要,以及結尾的 Craft Report。它不會修改程式碼。
適用情境
當使用者想要進行介面設計審查、詢問介面有什麼問題,或在交付、簡報前需要第二意見時使用。適用於與設計、UI 或前端工作相關的審查請求。
執行需求
僅為指示,無指令碼。視覺審查需要螢幕截圖,最好透過 Playwright MCP 伺服器、瀏覽器開發者工具或 Chrome MCP,或其他瀏覽器自動化工具取得;否則需由使用者提供桌面、平板與行動裝置的螢幕截圖。它引用 ui-craft 技能及其 references 檔案(inspiration.md、review.md)以及 CRAFT_LEVEL 設定。
<!-- HARNESS MIRROR — do not edit here. Canonical source: skills/ or commands/. After editing source, copy into cli/assets/<harness>/ and repo-root harness mirrors. -->

Context: this sub-skill is one lens of the broader ui-craft skill. If the ui-craft skill is also installed, read its SKILL.md first for Discovery + Anti-Slop + Craft Test, then apply the specific lens below.

Critique the UI at $ARGUMENTS through a design lens. Load the ui-craft skill.

Step 0: Visual capture (mandatory)

Code-only review is insufficient. Every audit/critique starts with the surface as the user sees it. Try the following in order; use the first one available:

  1. Playwright MCP — if playwright MCP server is available, use it. Capture full-page screenshots at three viewports: desktop (1280×800), tablet (768×1024), mobile (375×812). Capture dark mode if the app supports it.
  2. Browser DevTools / Chrome MCP — second choice; same viewport set.
  3. Other browser automation (agent-browser, cursor-ide-browser) — third choice.
  4. Ask the user — last resort. If no automation is available, request screenshots from the user before proceeding. Be specific:
    • "Visual review needs screenshots. Please provide:
      • Full-page at 1280px (desktop)
      • Full-page at 768px (tablet)
      • Full-page at 375px (mobile)
      • Dark mode of each, if supported."

Do not begin the review until visuals are captured or provided. State this explicitly to the user when no automation succeeds — don't silently fall back to code-only review.

If the user declines to provide screenshots, run a code-only pass and clearly mark the report [CODE-ONLY REVIEW — visual issues not assessed] at the top so the limitation is explicit.

Knob awareness (CRAFT_LEVEL sets the bar for what counts as "needs work"):

  • CRAFT_LEVEL 3 → flag only anti-slop Critical items. Skip Minor polish.
  • CRAFT_LEVEL 5-7 → flag Critical + Major. Mention Minor polish as optional.
  • CRAFT_LEVEL 9+ → flag everything, including Minor polish and missing signature detail.

Run these lenses in order:

  1. Anti-Slop Test (from SKILL.md): flag every item present. Critical first (ALL CAPS, purple gradients, identical card grids, bounce easing, emoji icons, glassmorphism + neon). Then major (colored pills on trends, thick colored borders, uniform radii, gradient text, walls of text). Then minor (straight quotes, missing tabular-nums, generic CTAs).
  2. Craft Test (from SKILL.md): where does the design fall short of "one accent, 3-5 placements; plain secondary text for comparisons; functional color only; every section earns its space"?
  3. Hierarchy: can the user tell what's primary, secondary, tertiary at a glance? Or does everything shout equally?
  4. Clarity: is the value prop legible in 5 seconds? Are CTAs specific (not "Learn more")?
  5. Signature detail: is there one memorable element that makes this feel designed, not assembled? If not, suggest one (motif, layout break, custom marker, distinctive hover).
  6. Inspiration gap — read references/inspiration.md: which observed pattern from the archetypes / signature details applies here, and how does the current state diverge from it?

Output format — the Review Format table:

BeforeAfterWhy

Prioritize by impact, not by file order. End with a one-paragraph summary of the top 3 changes that would raise this from "AI-generated" to "designed".

Do NOT edit code. This is a critique.

Close with a Craft Report (references/review.md → Craft Report) as the final wrapper around the findings table and top-3 summary — Checked names the lenses actually run (Anti-Slop, Craft Test, Hierarchy, Clarity, Signature, Inspiration gap) and at what CRAFT_LEVEL bar, Passed carries whatever held up under those lenses, Changed stays empty (critique doesn't edit), Left alone covers anything flagged but out of scope, Verdict is the one-sentence state. Produce it even when the surface passes clean — that's the validation the user is asking for.

Next step: /polish — apply the fixes this critique named (rung 1).

來源與署名

來源:educlopez/ui-craft位於.opencode/skills/critique提交ceecc8e

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架