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. The check reads the PR's diff, description, and author right there in the pipeline — the code never reaches PRKitchen's servers.
PRKitchen validates the PR against repo-specific rules defined in .prkitchen.yml: linked issue IDs, required description sections, mandatory checklists, and forbidden file patterns. Starting out? prkitchen init --starter docs, open-source or infra writes a working .prkitchen.yml you can edit.
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, code shape (complexity piled into a few functions, duplicated blocks, common agent code smells), 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.
An AI check grades the PR description against the diff (clear, thin, mismatched or slop), and Wild Goose Guard flags PRs that drift from the project’s stated purpose. Terraform PRs need a plan and a blast-radius statement, and orgs that manage GitHub in Terraform get their access and branch-protection changes checked. When a PR is low risk and every other check passed, Spice Rack can approve it — it never 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. In GitHub Actions it can also comment on, draft, or approve the PR with the job's own token; on GitLab and Bitbucket that part is a custom setup. Enterprise teams can ask for the GitHub App as a custom setup. 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 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