Plating is Everything. PRKitchen helps developers prep, refine, and present their work cleanly before it hits the table.
Your pre-PR quality gate that filters low-quality and AI-generated submissions before they reach human reviewers.
Every run — a PR on any platform or a local prkitchen check — flows through five validation stages
prkitchen check RunsA developer opens a pull request — on GitHub, GitLab, or Bitbucket — or runs prkitchen check straight from CI or their laptop. PRKitchen receives the PR metadata, diff, description, and author info from whichever source triggered it.
PRKitchen validates the PR against repo-specific rules defined in .prkitchen.yml: linked issue IDs, required description sections, mandatory checklists, and forbidden file patterns.
The PR size is analyzed: files changed, lines added/deleted, scattershot diff detection. Large, unfocused PRs are flagged before consuming reviewer time.
A scoring engine analyzes the PR for AI-generated content signals: vague language, over-explanation, unnecessary refactors, missing tests for behavior changes, and prior rejection history.
PRKitchen runs the repo's configured test and lint commands against a clean mirror of the codebase. If tests fail or new code lacks test coverage, the gate blocks.
From installation to daily operation in six steps
Add prkitchen to any pipeline — GitHub Actions, GitLab CI, Bitbucket Pipelines, or a local pre-push hook — and generate an ingest key from the dashboard so runs report back. Prefer zero-config on GitHub? Install the optional GitHub App instead. Either way, PRKitchen parses CONTRIBUTING/SECURITY/PR templates and generates an initial .prkitchen.yml policy file.
In the PRKitchen web dashboard, the team customizes rules: required PR fields, maximum diff size, test commands, allowed branches, minimum reviewers. They choose strictness levels and mark PRKitchen as a required status check.
Developers push branches and open PRs as usual — on any platform — or run prkitchen check before they ever push. PRKitchen pulls the latest base branch, runs all policy and code checks, and reports the result back to the dashboard.
If everything passes, the check exits 0 — green status or a clean CI run — and the PR flows normally. If rules fail (missing tests, wrong template, high slop score), prkitchen check exits non-zero: the CI job fails, and on GitHub the PR is converted to draft or closed with structured feedback.
Human reviewers see only passing PRs in their "Ready for review" views. AI-blocked items never clutter their queue. They can visit the "Blocked Items" tab to inspect, override decisions, or tune rules.
Engineering leadership sees dashboards: blocked PRs count, reviewer time saved, common failure reasons, and which contributors/tools cause the most noise. They adjust org-wide policies and export compliance reports.
Start free, scale as you grow