Skip to main content

PR Analysis

Every pull request tells a story. Octokraft reads that story in the context of your full codebase — not just the diff — and gives reviewers the information they need to make confident merge decisions.

What Happens When You Open a PR

When a pull request is opened or updated in a connected repository, Octokraft automatically runs a full analysis. Within minutes, you see results directly in your dashboard.
1

Context-aware analysis

Octokraft analyzes changes in the context of your full codebase. A function rename in one file is checked against every caller in other files. A new API endpoint is evaluated against your existing API design patterns. This catches issues that isolated diff review cannot.
2

Issue detection

Static analyzers and AI-powered semantic analysis run in parallel, detecting issues across 5 severity levels. Each issue includes the file, line numbers, explanation, and suggested fix.
3

Classification

The PR is classified by intent (feature, bugfix, refactor, etc.) and change category (business logic, API, data schema, etc.) to help reviewers quickly understand what they are looking at.
4

Merge readiness

A clear signal — blocked, needs review, or ready — tells you whether this PR is safe to merge.
5

Health impact projection

Octokraft projects how merging this PR will affect your codebase health score, broken down by category.

Classification

Every PR is automatically classified along three dimensions to help reviewers prioritize and understand changes at a glance.

Primary Intent

What the PR is trying to accomplish:
IntentDescription
FeatureNew functionality that did not exist before
EnhancementImprovement to existing functionality
BugfixCorrection of incorrect behavior
RefactorStructural change with no behavior change
Security FixRemediation of a security vulnerability
PerformanceOptimization for speed, memory, or resource usage
DocumentationUpdates to docs, comments, or READMEs
InfrastructureCI/CD, build system, deployment configuration
Dependency UpdateUpgrading or adding third-party dependencies

Change Categories

What areas of the codebase are affected:
  • business_logic — Core domain rules and workflows
  • api_interfaces — Public API endpoints, request/response contracts
  • data_schema — Database schema, data models, migrations
  • ui_client — Frontend components, user-facing behavior
  • infrastructure — Deployment, CI/CD, build configuration
  • testing — Test files, test utilities, fixtures
  • documentation — Non-code documentation
A single PR can span multiple change categories. A feature PR that adds an API endpoint, a database migration, and frontend components is tagged with all three.

Risk Signals

Flags that indicate a PR needs extra scrutiny:

migration_risk

Breaking changes to existing behavior. Callers, consumers, or downstream systems may need to adapt.

security_sensitive

Changes touching authentication, authorization, cryptography, or access control.

correctness_sensitive

Changes where bugs have high impact — financial calculations, data integrity, state machines.

cross_cutting

Changes affecting multiple modules or services. Higher coordination cost and broader blast radius.

public_surface

Changes to public APIs, SDKs, or interfaces consumed by external users.

Issues

Issues found during PR analysis use the same 5 severity levels as Code Health:
SeverityMeaningMerge Impact
CriticalMust fix — security holes, data loss risk, system crashBlocks merge
HighShould fix — significant bugs, breaking changesBlocks merge
MediumReview carefully — quality or correctness concernAdvisory
LowMinor — improvement opportunitiesAdvisory
InfoAwareness — no action neededInformational

What Each Issue Includes

Every issue provides enough context for a reviewer to understand and act on it:
  • File path and line numbers — Navigate directly to the problem
  • Category — security, logic, data_integrity, error_handling, performance, maintainability, and others
  • Why it matters — The impact if this issue is not addressed
  • Suggested action — A concrete recommendation for how to fix it
  • Confidence score — How certain the finding is (only issues meeting a high confidence threshold are surfaced)
Issues below the confidence threshold are not shown. Octokraft prioritizes actionable, high-confidence findings over noisy, speculative ones.

Merge Readiness

Every PR gets a clear merge readiness signal:

Blocked

The PR has critical or high-severity issues that must be resolved before merging. These represent concrete risks — security vulnerabilities, data integrity problems, or breaking changes.

Needs Review

No blocking issues, but medium or low-severity issues exist that a reviewer should evaluate. These may be acceptable trade-offs or may warrant changes.

Ready

No significant issues found. The PR can be merged with confidence based on the automated analysis.
Merge readiness is a signal, not a gate. Octokraft provides the assessment; your team makes the decision.

Health Impact

Every PR shows its projected impact on your codebase health score before you merge it:
  • Issues introduced — New issues this PR would add to the codebase
  • Issues resolved — Existing issues this PR fixes or removes
  • Category-level changes — Which of the 8 health categories are affected, and by how much
  • Overall score delta — The net effect on your project’s health score
This lets you make an informed decision: a PR that adds a critical feature but introduces 3 medium-severity code smells might be worth merging now with a follow-up to address the smells. A PR that degrades security scores is a different conversation.
Over time, health impact data reveals patterns. If PRs from a particular area of the codebase consistently introduce issues, that area may need architectural attention.

Scope Drift

Octokraft detects when changes in a PR fall outside the PR’s stated intent. If a pull request titled “Add user deletion endpoint” also refactors the logging system, renames utility functions, and updates unrelated configuration, scope drift flags the unrelated changes. This helps teams:
  • Keep PRs focused and reviewable
  • Identify changes that should be separate PRs
  • Reduce review fatigue from oversized, unfocused PRs
Scope drift is advisory — it highlights the drift without blocking the PR. The decision to split is yours.

Conflict Detection

Octokraft identifies potential conflicts with other open PRs — not just file-level git conflicts, but semantic conflicts where two PRs modify related logic. For example: PR #42 changes how user permissions are evaluated. PR #45 adds a new endpoint that depends on the current permission model. Even if these PRs do not touch the same files, merging one may break the assumptions of the other. Conflict detection surfaces these relationships so teams can coordinate merges and avoid integration surprises.

Stacked PRs

When pull requests build on each other, Octokraft detects the dependency chain and shows it clearly:
  • Which PRs depend on the current PR
  • Which PRs the current PR depends on
  • The recommended merge order
This helps teams that work with PR stacks — a common pattern where a large feature is broken into a chain of incremental, reviewable PRs. Without visibility into the stack, merging out of order or rebasing the wrong branch causes unnecessary churn.