interface-review

بازبینی تغییرات رابط کاربری برای کشف رگرسیون‌های دسترس‌پذیری و تجربه کاربری

این Skill، branch، pull request یا تغییرات uncommitted را بررسی می‌کند و مشکلاتی را که همان تغییر ایجاد کرده یا بدتر کرده است، در زمینه‌های دسترس‌پذیری، layout، متن، typography، رنگ و UI شناسایی می‌کند. ابتدا محدوده تغییر را مشخص می‌کند، فایل‌های تحت‌تأثیر را گسترش می‌دهد و هر دو سمت diff را می‌خواند.

گزارش نهایی change-scoped است؛ بنابراین به‌جای فهرست‌کردن همه ایرادهای قدیمی پروژه، روی رگرسیون‌های واقعی همین تغییر تمرکز دارد. این رویکرد برای code review رابط کاربری، پیش از merge و کاهش مشکلات قابل‌مشاهده برای کاربران مفید است.

چه چیزی می‌گیرید

  • تعیین دقیق محدوده بررسی برای branch، pull request یا تغییرات uncommitted
  • شناسایی رگرسیون‌های accessibility، layout، typography، رنگ، متن و UI
  • گسترش فایل‌های تغییرکرده به سطح‌ها و رابط‌هایی که از آن‌ها تأثیر می‌پذیرند
  • دسته‌بندی یافته‌ها و حذف موارد نامرتبط با تغییر فعلی
  • گزارش متمرکز بر علت تغییر، نه ایرادهای قدیمی کل codebase

برای چه کاری خوب است

  • بازبینی pull requestهایی که کامپوننت‌ها یا صفحات frontend را تغییر داده‌اند
  • بررسی تغییرات طراحی، CSS، layout یا متن پیش از merge
  • تیم‌هایی که می‌خواهند رگرسیون‌های accessibility و UI را در code review پیدا کنند

برای چه کاری نیست

  • بررسی correctness، تست‌ها، security یا performance؛ این موارد باید در code review عمومی بررسی شوند
  • ارزیابی یک screen بدون تغییر مشخص یا ممیزی کامل و قدیمی codebase
  • وقتی branch، pull request یا تغییرات محلی قابل‌بررسی وجود ندارد

دربارهٔ این اسکیل

(no title)

URL: https://raw.githubusercontent.com/jakubkrehel/skills/main/skills/interface-review/SKILL.md

name: interface-review
disable-model-invocation: true
description: Reviews a branch, pull request or uncommitted change for the interface problems it introduced or regressed, across accessibility, layout, writing, typography, color and UI.
---

Interface review

This skill reviews a change rather than a screen. It resolves the scope, expands the changed files to the surfaces they affect, reads both sides of the diff and classifies every finding.

It owns the scope, the classification and the change-scoped report. Domain rules belong to the better-* skills. Severity, consolidation, coverage, the cap and the verdict belong to better-interface, which this skill hands the review to.

Correctness, tests, security and performance belong to the project's general code review. Name such a concern once, point at that review and drop it.

The change, not the codebase

The author is asking "did I make this worse?". Report what the change caused and stay mostly quiet about what it merely touched. Three pre-existing findings is a courtesy; thirty is a different review and one nobody asked for.

Read the whole diff before forming an opinion of it. A skimmed diff produces findings about code the next hunk already fixed.

Core principles

1. Resolve the change scope first

The whole invocation is the target, so /interface-review pr 482 reviews pull request 482. Scope resolution holds the accepted targets and how each resolves.

With no target supplied, resolve in this order and stop at the first match:

  1. HEAD is ahead of git merge-base origin/ HEAD. Review that range plus any uncommitted changes, stating the commit count and the uncommitted file count separately.
  2. The working tree is dirty. Review the uncommitted changes.
  3. Neither. There is no change to review, so follow With no change, ask rather than invent one.

Record the base commit of the resolved range as $BASE and name it in the scope block. Every command in this skill and its references uses it.

Exclude lockfiles, snapshots, generated output, vendored code and binaries per Excluded paths, and name what you excluded. If nothing survives the exclusions, treat it as no change.

2. With no change, ask rather than invent one

A clean tree with nothing ahead of the merge base means there is no change to review. Never fall back to HEAD~1..HEAD on your own. The last commit is whatever happened to land, often a merge or someone else's work.

Gather the facts in Nothing to review, state them, then offer these routes and wait:

  • The open pull request on the current branch, first when there is one. A branch whose commits already landed resolves to no change, while its pull request is still exactly what the user meant.
  • The last commit, HEAD~1..HEAD, named by short SHA and subject so the user sees what they would get.
  • A target they name, such as pr

دانلود ZIP