Striff logo
For public GitHub pull requests

See architectural risk before merge.

Striff reviews pull requests at the system level inside GitHub, surfacing unusual dependencies, boundary drift, and structural blast radius before line-by-line review eats your time.

Install extension View examples

Start in public repos. Move into private-team checks only after the signal proves itself on real pull requests.

openapitools/openapi-generator PR #19423 Java
Structural diff in GitHub
Structural diff Changed relationships in context
Changed packages 1 unusual edge
adapter/web BillingController
review/core ReviewOrchestrator
review/core StructuralSignals
storage RepositoryStore
shared/core ModelUtils
github/checks CheckRunWriter

Grounded note

BillingController now reaches into ModelUtils, which usually sits behind review-core services.

Anomalous edges 2
Flagged components 1
Structural changes 3

One artifact first

The structural diff is the main review surface.

The GitHub Check slides in while you scroll the hero so the story is clear: Striff shows the architecture, then points at the specific risky changes it wants reviewed.

What it catches

Catch the changes file diffs hide.

Striff earns attention when a pull request changes the shape of the system, not just the lines in a file. These are the changes it should make easier to see first.

New cross-layer dependency

Spot when an API or controller starts depending directly on persistence, internals, or the wrong side of a boundary.

Reversed dependency direction

See when a service starts reaching into transport DTOs or other upstream concerns that usually point the other way.

Coupling jump on a shared component

Notice when fan-in, complexity, or architectural reach grows on a class other teams already depend on.

Structurally unusual new edges

Flag new relationships that look rare compared with healthy codebases, then explain why they deserve attention.

Why Striff

Why not just use file diffs?

File diffs are good at edits. Striff is built for architecture movement.

Large, AI-generated, or cross-cutting pull requests often hide the risky part in plain sight. Striff gives reviewers a structural first pass before they dive into files.

Research roots at ICCQ 2021, with the product focused on practical PR review.

File Diff

Shows edited lines and moved code.

Striff

Shows new dependencies, boundary movement, and architectural blast radius.

File Diff

Makes reviewers hunt through files for the risky part.

Striff

Highlights the changed components and relationships worth reading first.

File Diff

Can make AI-generated changes look tidy at the syntax level.

Striff

Focuses review on structural drift, unusual edges, and the questions to ask before merge.

Two surfaces

The check says what is concerning. The diff explains why.

Striff makes more sense as review infrastructure with two linked views than as a diagram tool with extra features.

GitHub Check

Fast triage

Scannable structural triage in the PR checks tab

Use the Check Run to see what changed structurally, which edges look unusual, and which components deserve a second look.

  • Highlights unusual new edges and flagged components.
  • Keeps the summary terse, structured, and easy to scan in GitHub.
  • Works even when AI notes are unavailable.

Interactive Diff

Deep review

Dive into the structural diff when you need the why

Open the diagram to inspect changed relationships, metric shifts, and grounded review notes attached to the part of the system they describe.

  • Attaches review notes to the package or component they describe.
  • Keeps changed relationships, metrics, and context in one artifact.
  • Lets maintainers judge the system effect before debating line edits.

Real OSS examples

One polished PR example for each supported language.

These rows now use real Striff output from public PRs. Open any language to see a GitHub-style check summary layered directly over the structural diff artifact, with pan and zoom for the diagram.

Live public PR artifacts
Java spring-projects/spring-boot #50455 Public PR

Generalize port file writing support

2 detector findings · 7 components · 6 relationships
Focused review surface
7 components in the focused structural diff6 changed relationships across 3 package clusters
Open Generalize port file writing support
spring-projects/spring-boot #50455
Conversation 22 Checks 11 Files changed 17

striff / architectural-review

Architectural review completed

Completed with 3 findings across 7 components in the focused structural diff.

Java Striff structural diff for spring-projects/spring-boot #50455
striff / architectural-review
Completed in GitHub Checks
Completed 1 check run with findings
Summary Findings 3

Review headline

A new event path crosses package boundaries around port binding.

Boundary movement and a new public writer path deserve review before merge.

7 components in the focused structural diff 6 changed relationships across 3 package clusters
!

New directional boundary crossing

org.springframework.boot.context now points into org.springframework.boot.context.event, which did not exist before this PR.
!

Second boundary crossing through web server context

org.springframework.boot.web.server.context also now points into org.springframework.boot.context.event, expanding the event surface.
~

Writer class is becoming a coordination point

NetworkServerPortFileWriter lands as a public, fairly heavy class, making it a likely coupling magnet if more behaviors collect there.

Review prompts

  • Review NetworkServerPortFileWriter as the new central node.
  • Check whether PortBound belongs in the event package or behind a narrower abstraction.
  • Confirm WebServerInitializedEvent is still the right owner for this event flow.

This is a strong Java example because the line diff looks tidy, but Striff immediately shows the new event-oriented shape spanning boot context and web-server packages.

Open PR on GitHub
Python PrefectHQ/prefect #22018 Public PR

Add delete flow run automation action

7 components · 2 relationships · duplicated delete-flow concept
Focused review surface
7 components in the structural diff2 changed relationships around flow-run actions
Open Add delete flow run automation action
PrefectHQ/prefect #22018
Conversation 22 Checks 11 Files changed 17

striff / architectural-review

Architectural review completed

Completed with 3 findings across 7 components in the structural diff.

Python Striff structural diff for PrefectHQ/prefect #22018
striff / architectural-review
Completed in GitHub Checks
Completed 1 check run with findings
Summary Findings 3

Review headline

Delete-flow behavior now exists in parallel event and server namespaces.

The main concern is boundary blur, not line-level complexity.

7 components in the structural diff 2 changed relationships around flow-run actions
!

Parallel DeleteFlowRun types now exist

Event-layer and server-layer delete actions now live side by side, which increases the chance of drift and duplicated semantics.
~

Client, server, and event responsibilities are touching

OrchestrationClient, DeleteFlowRun, and FlowRunAction now form a tighter cluster around the same behavior.
i

Good review question

Should delete-flow semantics have one source of truth rather than separate layer-specific types?

Review prompts

  • Compare the two DeleteFlowRun classes before approving the abstraction split.
  • Check whether OrchestrationClient.delete_flow_run should remain the primary seam.
  • Use the diff to see whether event actions are depending on server concerns too directly.

This Python PR is valuable because it shows how Striff can call out architectural duplication and blurred ownership even when there are few edges in the raw diff.

Open PR on GitHub
TypeScript vitest-dev/vitest #10362 Public PR

feat(reporters): add fileTemplate option to JUnit reporter

7 components · 4 relationships · reporter template surface expansion
Focused review surface
7 components in the diff4 relationships anchored on `JUnitReporter`
Open feat(reporters): add fileTemplate option to JUnit reporter
vitest-dev/vitest #10362
Conversation 22 Checks 11 Files changed 17

striff / architectural-review

Architectural review completed

Completed with 3 findings across 7 components in the diff.

TypeScript Striff structural diff for vitest-dev/vitest #10362
striff / architectural-review
Completed in GitHub Checks
Completed 1 check run with findings
Summary Findings 3

Review headline

A smaller refactor still grows the reporter's template surface in meaningful ways.

The reviewer can focus on one hotspot instead of reading the whole reporter file first.

7 components in the diff 4 relationships anchored on `JUnitReporter`
!

JUnitReporter remains the hotspot

Complexity dropped, but the class is still much heavier than the repo norm and remains the main coordination point for this reporter path.
~

New template interfaces widen the surface area

SuiteNameTemplateVariables and FileTemplateVariables extend the local abstraction set around JUnit formatting.
i

Good review question

Is the new template surface converging toward a coherent reporter model, or are narrowly-scoped interfaces starting to fragment the design?

Review prompts

  • Start at JUnitReporter and inspect the new spokes first.
  • Check whether FileTemplateVariables is a stable abstraction or a one-off convenience type.
  • Use the structural diff to reason about future reporter option growth.

This TypeScript example is good because the diagram stays compact and legible while still surfacing how one reporter class is anchoring several new template interfaces.

Open PR on GitHub
C# AvaloniaUI/Avalonia #21310 Public PR

Improve composition hit testing performance with per-visual AABBs

Focused 7-component subdiagram · rendering-path review
Focused review surface
Focused 7-component subdiagram for the homepageReview centers on hit-test tree, renderer, and composition target
Open Improve composition hit testing performance with per-visual AABBs
AvaloniaUI/Avalonia #21310
Conversation 22 Checks 11 Files changed 17

striff / architectural-review

Architectural review completed

Completed with 3 findings across focused 7-component subdiagram for the homepage.

C# Striff structural diff for AvaloniaUI/Avalonia #21310
striff / architectural-review
Completed in GitHub Checks
Completed 1 check run with findings
Summary Findings 3

Review headline

Hit-testing logic thickens inside the rendering path and adjacent composition types.

The diagram narrows a bigger C# PR down to the renderer-facing cluster that actually matters for review.

Focused 7-component subdiagram for the homepage Review centers on hit-test tree, renderer, and composition target
!

CompositionHitTestAabbTree is the new center of gravity

The review highlights the hit-test tree as the critical component in this change set, which is exactly where reviewers should start.
~

Renderer-path neighbors are pulled into the same cluster

CompositionContainerVisual, CompositionTarget, and CompositingRenderer all become part of the same focused review surface.
i

Good review question

Does the new AABB-tree logic stay a contained performance layer, or is it starting to absorb responsibilities from the surrounding renderer path?

Review prompts

  • Use the focused subdiagram instead of the full 14-component graph on the homepage.
  • Start with CompositionHitTestAabbTree, then inspect how it touches the target and renderer types.
  • Check whether comparer/candidate internals are staying private implementation details.

The full PR is larger, so this example uses a focused subdiagram around the hit-test tree and renderer-facing components to keep the architecture story readable.

Open PR on GitHub

How it works

Deterministic structural signals first. AI explanation second.

The system stays useful by grounding the model in architectural facts. The AI is there to explain evidence, not invent concerns.

Step 1

Generate the structural diff

Parse the pull request into changed components, relationships, and architectural facts instead of treating it as a flat set of files.

Step 2

Rank what deserves review

Combine deterministic rules, learned graph signals, and GNN-style structure scoring to rank the unusual edges and changed components that deserve attention.

Step 3

Explain the concern in context

Use a neurosymbolic pipeline to keep the model grounded in architectural facts, then render concise review notes directly on the affected component or relationship.

Adoption path

Use it in public repos first. Roll it out to teams when the value is clear.

Public repositories are the easiest place to evaluate Striff on real pull requests. Teams can then add private-repo coverage, automated checks, and shared review workflow when they want it in daily use.

Public OSS

Free review workflow for public repositories

Install the extension and use Striff on public pull requests where maintainers need fast architectural context.

Private Teams

Automated checks for private-team review

Add the GitHub App when your team wants shared structural checks and repeatable review coverage on private pull requests.

Deep Integration

Library and private deployment options

Use the OSS library or talk to us about internal deployment when you need deeper integration with your engineering workflow.

Install extension Team pricing GitHub App