ui-code-review

Review UI pull requests and diffs for regressions, scope creep, and cost-weighted findings.

78|27|Updated May 4, 2024
One-click install
npx skills add https://github.com/fedixyz/fedi --skill ui-code-review-fedixyz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ui-code-review
Source: https://github.com/fedixyz/fedi/tree/main/.agents/skills/ui-code-review
Command: npx skills add https://github.com/fedixyz/fedi --skill ui-code-review-fedixyz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Reviewing TypeScript/React pull requests in the Fedi ui/ workspace (web, native, and shared common) is error-prone: regressions hide in untraced callers, silently removed behavior, and hardcoded strings, while reviewers often block on preference instead of real cost. This Skill provides a disciplined review procedure plus concrete, fedi-specific rules so findings are ordered by cost and only named costs block a merge. ## Core Features & Use Cases - Structured review procedure: A checklist that walks the diff chunk by chunk, traces every caller of changed signatures, names behavior removed with deleted lines, and distinguishes root-cause fixes from symptom suppression. - Fedi-specific enforceable rules: Reference rules covering i18n (no hardcoded user-facing strings), shared ui/common code and native/web parity, test conventions, and feature-flag behavior (flag-OFF must reproduce prior behavior). - Cost-weighted findings: Principles that classify comments as blocking, suggest, nit, question, or praise, blocking only on a named cost such as a real bug, performance hit, or security issue. - Use Case: A developer asks for a review of a React Native PR that changes a balance hook. The Skill traces all consumers of the hook, checks for parity with web, flags a hardcoded toast string as an i18n defect, and delivers findings ordered by cost with path:line references. ## Quick Start Ask the assistant to review the current UI pull request or diff in the ui workspace using the ui-code-review skill and report findings ordered by cost.

Frequently Asked Questions about ui-code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a React or React Native pull request for regressions?

Skim the whole diff first, then walk each chunk naming the behavior change in plain language. For every changed signature, return shape, or side effect, trace every caller, and for every removed line name the behavior that went with it. Order findings by cost with path:line references.

What should block a UI pull request from merging?

Block only on a named cost: a real bug, a measurable performance hit, a specific maintainability problem, or a security issue. Convention divergence and personal preference do not block; downgrade those to suggest or nit comments instead.

Does this code review skill cover Rust or backend changes?

No. The skill covers only the ui workspace: web, native, and shared common TypeScript/React code. For Rust, bridge, or infrastructure changes it instructs the reviewer to stop and state that the skill does not apply.

How are hardcoded user-facing strings handled in UI review?

Every user-facing string must go through i18n using t() with a key defined in ui/common/localization/en/common.json. A hardcoded English sentence is a defect, not a nit, because the app ships in roughly twenty locales; proper nouns and data values stay raw.

When should a reviewer demand tests for a UI change?

Demand tests when the change touches high-risk surfaces such as shared state, payments, auth, federation lifecycle, or the bridge boundary and ships without coverage. Do not demand tests for low-risk changes like copy or styling tweaks.

Can an automated PR review bot use this skill?

Yes. Always-on bots like Greptile skip the human procedure and anti-patterns sections, applying only the concrete rules in references/rules scoped to ui/** and the cost-based blocking principle before grading anything as blocking.