# How interface-review Resolves Change Scope and Identifies Affected UI Surfaces > Learn how interface-review resolves change scope by calculating Git diffs and identifies affected UI surfaces by analyzing import graphs to pinpoint consumer components. - Repository: [Jakub Krehel/skills](https://github.com/jakubkrehel/skills) - Tags: how-to-guide - Published: 2026-09-12 --- **The `interface-review` skill resolves change scope by transforming user-provided Git targets into concrete file lists through merge-base diff calculations and pathspec exclusions, then expands those changes to affected UI surfaces by traversing import graphs to prioritize consumer components that actually render the modified code.** The `interface-review` skill in the jakubkrehel/skills repository automates the precise determination of which files have changed and which UI components are materially impacted. By processing Git references through a multi-stage resolution pipeline defined in [`scope-resolution.md`](https://github.com/jakubkrehel/skills/blob/main/scope-resolution.md), it produces a reproducible, bounded set of surfaces for accessibility, layout, and typography analysis. ## Resolving the Change Scope from Git Targets The resolution process begins by normalizing diverse target formats into a concrete file list. According to the source code in [`scope-resolution.md`](https://github.com/jakubkrehel/skills/blob/main/scope-resolution.md), the skill accepts **working**, **staged**, **branch**, **pr \**, bare **\**, or explicit **\..\** / **\...\<\b\>** range specifications (line 11). ### Merge-Base Calculation for Branch Comparisons When comparing branches, `interface-review` computes the **merge-base diff** using `git diff ...` (three-dot syntax) to identify changes introduced on the target branch since the common ancestor. If the user supplies explicit two-dot syntax (`..`), the skill compares endpoints directly without merge-base calculation (lines 13-16). This distinction ensures accurate scope detection whether reviewing feature branches or arbitrary commit pairs. ### Handling Uncommitted and Untracked Files To prevent data loss, the skill incorporates uncommitted changes by executing `git ls-files --others --exclude-standard` (line 17). This captures newly added files that would otherwise be silently omitted from the review scope, ensuring the working tree state is fully represented. ### Pull Request Isolation For `pr ` targets, the skill fetches the pull request into an isolated remote-tracking ref using `git fetch origin "pull//head:refs/remotes/pr/"` (lines 21-23). It then examines the content via `git show` rather than checking out the fork's working tree, preventing contamination of the upstream codebase while accurately capturing the proposed changes. ### Edge Case Resilience The implementation gracefully handles repository states that typically break automation. In [`scope-resolution.md`](https://github.com/jakubkrehel/skills/blob/main/scope-resolution.md) (lines 35-39), the skill detects **detached HEAD**, **shallow clones**, and **mid-rebase/merge** states, falling back to explicit SHA references or aborting with a clear "unresolvable" message rather than producing ambiguous results. ### Applying Exclusions via Pathspecs After resolving the raw file list, the skill applies exclusion patterns for **lockfiles**, **generated assets**, **vendored code**, and **media files** as pathspec filters (lines 61-72). The final scope block reports the resolved Git reference, the definitive file count, and any excluded patterns, providing full transparency into the boundary of analysis. ## Expanding Changes to Affected UI Surfaces A diff alone does not constitute a UI surface. As documented in [`scope-resolution.md`](https://github.com/jakubkrehel/skills/blob/main/scope-resolution.md) (lines 74-78), `interface-review` expands the resolved file list by traversing import relationships to identify **consumer files** that actually render the changed components. ### Consumer File Traversal The expansion logic traverses one hop from the changed file (or two hops for token-level changes) to locate components that import or depend on the modified code. This transformation bridges the gap between implementation changes and their visual manifestations in the application. ### Deterministic Surface Prioritization Consumer files are ordered using a three-tier deterministic strategy (lines 84-88): 1. **Route and layout entry points** — Framework-specific page files (`app/**/page.*`, `pages/**`, `src/views/**`) receive highest priority as they represent actual rendered surfaces. 2. **Importer count** — Components imported by many files are prioritized because they affect broader swaths of the UI. 3. **Proximity** — Files within the same package or feature directory are examined before distant dependencies. The first five consumer files receive detailed review, while remaining consumers are counted and reported with a notation that ordering beyond the top five is arbitrary (line 88). ## Practical Usage Examples Review the current working tree including untracked files: ```bash /interface-review working ``` Analyze a specific pull request in isolation: ```bash /interface-review pr 42 ``` Compare explicit commit ranges: ```bash /interface-review main..feature-branch ``` In each invocation, the skill executes four phases: resolves the target into a file list, applies exclusion pathspecs, expands to consumer surfaces using the deterministic ordering, and produces a scope block documenting the resolved ref and file count. ## Summary - `interface-review` accepts multiple Git target formats including working directories, staged changes, branches, PRs, and explicit commit ranges. - Branch comparisons use merge-base diff logic (`git diff ...`) unless overridden by two-dot syntax. - Uncommitted changes are captured via `git ls-files --others --exclude-standard` to prevent silent omissions. - Pull requests are isolated using remote-tracking refs to avoid upstream contamination. - Exclusions for generated and vendored files are applied via pathspecs before surface expansion. - Affected UI surfaces are identified by expanding changes to consumer components using deterministic priority: route entry points first, then high-import components, then proximal files. ## Frequently Asked Questions ### What target formats does interface-review support? `interface-review` supports **working** (working tree), **staged** (index), **branch** (current branch vs default), **pr \** (GitHub pull request), bare **\** (any commit reference), and explicit ranges using **\..\** (direct comparison) or **\...\<\b\>** (merge-base comparison) syntax as defined in [`scope-resolution.md`](https://github.com/jakubkrehel/skills/blob/main/scope-resolution.md) (line 11). ### How does interface-review handle uncommitted changes? The skill executes `git ls-files --others --exclude-standard` to include untracked files and incorporates staged changes, ensuring that newly created files in the working directory are not silently excluded from the review scope (line 17). ### Why does interface-review expand to consumer files instead of reviewing diffs directly? A diff represents implementation changes but not UI impact. By expanding one or two hops to **consumer files** (lines 74-78), the skill identifies the actual rendering surfaces—such as page components and layouts—that execute the changed code, enabling analysis of accessibility, layout, and visual consistency rather than just code correctness. ### How many consumer files does interface-review analyze in detail? The skill performs detailed review on the **first five consumer files** identified by its deterministic ordering algorithm. Additional consumers are counted and reported in summary form, with explicit documentation that ordering beyond the fifth file is arbitrary (line 88).