How interface-review Resolves Change Scope and Identifies Affected UI Surfaces

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, 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, the skill accepts working, staged, branch, pr <n>, bare <ref>, or explicit <a>..<b> / <a>...<\b> range specifications (line 11).

Merge-Base Calculation for Branch Comparisons

When comparing branches, interface-review computes the merge-base diff using git diff <a>...<b> (three-dot syntax) to identify changes introduced on the target branch since the common ancestor. If the user supplies explicit two-dot syntax (<a>..<b>), 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 <n> targets, the skill fetches the pull request into an isolated remote-tracking ref using git fetch origin "pull/<n>/head:refs/remotes/pr/<n>" (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 (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 (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:

/interface-review working

Analyze a specific pull request in isolation:

/interface-review pr 42

Compare explicit commit ranges:

/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 <a>...<b>) 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 <n> (GitHub pull request), bare <ref> (any commit reference), and explicit ranges using <a>..<b> (direct comparison) or <a>...<\b> (merge-base comparison) syntax as defined in 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).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}