Whole-repo context
A review sees more than the diff: the context pack is built from the changed files and their relations in the indexed base-branch snapshot, plus a vector search over your knowledge base.
AI Code Review
A reviewer that reads the whole repository, not just the diff
Skitflow reviews every pull request against an indexed snapshot of your base branch, confirms each finding against real code before posting it, and scores merge readiness out of 5. Self-hosted, on your own models, inside your own network.
#1248feat(billing): prorate plan downgrades
- queued
- indexing
- reviewing
- publishing
- completed
Ready for merge
Readiness 4/5 meets the required 3/5 with no blocking findings. The same verdict is written to the check run your branch protection gates on.
mediumA retry can credit the refund twicesrc/billing/prorate.ts:142
lowHelper duplicates the existing clampToCyclesrc/billing/prorate.ts:201
How a review runs
Every finding is confirmed against code before the author sees it
Between candidate generation and publishing sits the Investigate phase: one evidence lookup per candidate against the indexed base-branch snapshot, then a single confirm-or-kill judgement for the whole batch. What cannot be backed by code is never posted.
Pull requestopened · updated · comment command
Indexbase-branch snapshot, changed-file context pack
Generatecandidate findings from the diff
Investigateconfirm or kill, one batch verdict
Publishsummary · inline comments · check run
Repo index + KBvector-searched docs
Org review skillsyour rules, per path glob
Policy filterseverity and confidence floors, memory, dedupe
review flowcontext & evidencediscarded candidates
Candidates the investigate pass cannot back with code, and findings below your floors, are dropped before publishing rather than posted and argued about afterwards.
What the reviewer brings to a pull request
The investigate phase
One evidence lookup per candidate, then a single verdict for the batch. Candidates beyond the ceiling pass through unchanged rather than being dropped, and the phase is skipped outright when a review has no repository-aware context.
Noise dies in policy
Severity and confidence floors from the strictness profile, suppression of what your team already dismissed, de-duplication of repeats. All of it is applied before publishing, not after.
Inside your own infra
The reviewer is part of your self-hosted Skitflow: code, index and vectors stay in your cluster, and models are reached through your own AI gateway.
Merge readiness
One score out of 5, and the check run says the same thing
The score is derived from the published findings by rules you can read, not from the model's mood. A blocking severity can never score 5/5, and a pile of small findings pulls the score down just like one serious problem does.
| Score | When | Why |
|---|---|---|
| 5/5 | A single finding no worse than medium, or a clean review the reflection pass is sure about | Nothing to act on before merge |
| 4/5 | 2–4 findings, none worse than medium | Count cap |
| 3/5 | 5–9 findings, none worse than medium | Count cap |
| 2/5 | A high-severity finding, or ten findings and more | Severity cap / count cap |
| 1/5 | A critical-severity finding | Severity cap |
| not scored | Finding quality degraded, so no score is claimed | The gate closes rather than passing silently |
Your threshold
You set the required minimum. “Ready for merge” means the score is at or above it and no finding is blocking.
One verdict, two surfaces
The check-run conclusion and the readiness line in the summary comment come from the same value, so branch protection and the pull request conversation can never disagree.
When nothing is found
A clean review is not automatically 5/5: a separate reflection pass scores the empty review 0–10, and readiness is that score halved.
Severity, not P-numbers
Five levels: info, low, medium, high, critical. High and critical are blocking and cap the score.
Comparison
Our reviewer vs a hosted AI reviewer
Capabilities line up where they line up. The table lists only what the product does, with no benchmark numbers and no percentages. Two differences are structural: the review runs inside your own infrastructure, and it knows your deployment topology.
| Skitflow | Typical hosted AI reviewer | |
|---|---|---|
| Where it runs | Self-hosted in your cluster, models through your own AI gateway | Vendor SaaS: code and index leave your network |
| Context | Indexed base-branch snapshot plus a vector search over your knowledge base | Varies; diff-only in many tools |
| Verification before posting | The investigate phase confirms or kills each candidate against code | Usually posts what the model drafted |
| Merge signal | Readiness 0–5 and a check run your branch protection gates on | Often a comment or an opaque rating |
| Noise control | Three strictness profiles with explicit severity and confidence floors, plus suppression driven by your team's dismissals | A nitpickiness switch |
| Your rules | Organisation review skills: YAML, scoped by path glob, up to 200 per organisation | A prompt file, usually repository-wide |
| Model choice | fast / balanced / premium / auto tiers through your gateway | The vendor's model, no choice |
| Infrastructure awareness | Builds an infra graph: desired state, what is deployed, and what this pull request proposes | None: the reviewer does not know your deployment topology |
| Providers today | GitHub, GitLab, Gitea | Usually GitHub first |
Tuning
Strictness is a number, not a mood
A profile sets two explicit floors: minimum severity and minimum confidence. Anything under the floor is not published.
chill
Medium and above only, confidence at least 85. For repositories that want nothing but the serious signal.
standard · default
Low and above, confidence at least 70. The default balance.
strict
Low and above, confidence at least 60. More findings, borderline ones included.
What you teach it, it remembers
Review memory
When your team keeps dismissing one kind of finding, that family gets suppressed. The threshold is explicit: a dismissal share of 60% or more, not a hunch.
Review skills
Your team's rules in YAML, scoped by path glob. Skills are review guidance only: they cannot request files, environment variables, network access or side effects.
Knowledge base
Your documents are indexed as vectors and pulled in by relevance to the files a pull request touches.
Labels and description
Up to three labels per pull request from your own taxonomy, plus a generated description of the change and a changelog entry.
Models and providers
You choose how hard a review thinks
Every tier resolves through your own AI gateway, so the model and its credentials stay yours.
fast
A quick pass for small pull requests.
balanced · default
The working default for everyday review.
premium
The strongest model, for changes you are nervous about.
auto
The tier is picked for you.
Where it reviews today
Each provider is enabled by a per-organisation rollout flag.
GitHub
GitHub App: webhooks, check runs, inline comments, comment commands.
GitLab
Merge requests through a connection token.
Gitea
Self-hosted Gitea through a connection token.
Frequently asked
Does my code leave my network?
No. The reviewer is part of your own Skitflow installation: the index, the vectors and the findings live in your database, and model calls go through your own AI gateway.
What if the model invents a problem that isn't there?
That is what the investigate phase is for: a candidate with no evidence in the code is not published. If finding quality degrades, no readiness score is claimed at all and the gate closes rather than passing silently.
Can a review block a merge?
Only through the check run you added to branch protection yourself, and only against your own readiness threshold. The check-run conclusion and the summary line are computed from one value.
Does it learn from our project?
Yes, in a narrow sense: families of findings your team keeps dismissing get suppressed against an explicit threshold. It is not fine-tuning a model on your code.
Which code hosts are supported?
Today GitHub, GitLab and Gitea, each behind a rollout flag.
Point the reviewer at your first repository
Enabled per organisation, tuned per repository, reviewing on infrastructure you already run.