linux-kernel-review
Orchestrator for agentic Linux kernel patch review. Converts the Sashiko
multi-stage review protocol (sashiko-dev/sashiko) into Qodo skills. It runs
no tools. It routes a kernel diff through specialized review lenses and
enforces the shared discipline that keeps noise down.
How to apply
- Review the diff, not the whole tree. Judge changed lines plus the context
needed to prove or disprove a concern.
- Reason statically. You cannot build or run the code.
- Assume the patch has bugs, including in its commit message and comments.
Every claim must be proven correct against the code.
- Prefer a few proven, high-value findings. Noise is the failure mode.
Lens routing (the Sashiko stages, as skills)
Apply every lens whose scope the diff touches. A patch can match several.
| Lens skill |
Sashiko stage |
Scope |
| kernel-change-intent |
1-2 |
Goal, architecture, UAPI, claim-vs-code verification |
| kernel-execution-flow |
3 |
Control flow, error paths, NULL derefs, off-by-one |
| kernel-resource-lifecycle |
4 |
Leaks, UAF, double free, refcounts, async teardown |
| kernel-locking-concurrency |
5 |
Deadlocks, atomic-context sleeps, RCU, races |
| kernel-security-audit |
6 |
OOB, integer overflow, TOCTOU, info leaks |
| kernel-driver-hardware |
7 |
Registers, DMA, barriers, IRQ, suspend/resume |
| kernel-subsystem-guides |
context |
Per-subsystem invariants, loaded by trigger table |
| kernel-review-discipline |
9-10 |
False-positive gate, severity, specificity, ALWAYS |
Sashiko stages 8 (dedup), 9 (conflict resolution), and 11 (report format)
are pipeline mechanics; the Qodo platform consolidates and renders findings.
Their reasoning rules survive inside kernel-review-discipline.
Review order
- Load kernel-subsystem-guides and match the diff against its trigger
table. Load every matching guide before analysis.
- Apply each in-scope lens to the diff. Collect candidate concerns.
- Pass every candidate through kernel-review-discipline: prove it or drop
it, then calibrate severity. Only survivors become findings.
Mapping a finding to the contract
- action_level: action_required for a proven correctness, memory-safety,
locking, or security defect; remediation_recommended for a weaker or
speculative case; informational for a note.
- category: Security, Correctness, or Maintainability.
- evidence: cite file, function, exact line when known, the triggering
condition, and the lens rule id. Never invent line numbers.
What NOT to flag
- Style, naming, formatting, typos in comments (checkpatch territory).
- Defensive checks you cannot prove are reachable with bad data.
- Ignored returns from calls that cannot fail, or from debugfs APIs.
- Pre-existing low/medium issues not introduced by this patch.
- Removal of assertions/WARN/BUG as a regression.
Sourcing
Protocol derived from Sashiko (Apache-2.0, sashiko-dev/sashiko) and Chris
Mason's review-prompts (MIT, masoncl/review-prompts). Reference files under
the lens skills reproduce masoncl content under its MIT license.
1---2name: linux-kernel-review3description: Use when a PR diff modifies Linux kernel code (C or Rust in a kernel tree: drivers/, fs/, mm/, net/, kernel/, block/, include/linux/, arch/), orchestrator for the kernel review suite: routes the diff through the kernel-* lenses, enforces the shared low-noise contract (prove it against the code, diff-scope only, few high-value findings). Skip for non-kernel diffs.4license: Apache-2.05---67# linux-kernel-review89Orchestrator for agentic Linux kernel patch review. Converts the Sashiko10multi-stage review protocol (sashiko-dev/sashiko) into Qodo skills. It runs11no tools. It routes a kernel diff through specialized review lenses and12enforces the shared discipline that keeps noise down.1314## How to apply1516- Review the diff, not the whole tree. Judge changed lines plus the context17 needed to prove or disprove a concern.18- Reason statically. You cannot build or run the code.19- Assume the patch has bugs, including in its commit message and comments.20 Every claim must be proven correct against the code.21- Prefer a few proven, high-value findings. Noise is the failure mode.2223## Lens routing (the Sashiko stages, as skills)2425Apply every lens whose scope the diff touches. A patch can match several.2627| Lens skill | Sashiko stage | Scope |28|---|---|---|29| kernel-change-intent | 1-2 | Goal, architecture, UAPI, claim-vs-code verification |30| kernel-execution-flow | 3 | Control flow, error paths, NULL derefs, off-by-one |31| kernel-resource-lifecycle | 4 | Leaks, UAF, double free, refcounts, async teardown |32| kernel-locking-concurrency | 5 | Deadlocks, atomic-context sleeps, RCU, races |33| kernel-security-audit | 6 | OOB, integer overflow, TOCTOU, info leaks |34| kernel-driver-hardware | 7 | Registers, DMA, barriers, IRQ, suspend/resume |35| kernel-subsystem-guides | context | Per-subsystem invariants, loaded by trigger table |36| kernel-review-discipline | 9-10 | False-positive gate, severity, specificity, ALWAYS |3738Sashiko stages 8 (dedup), 9 (conflict resolution), and 11 (report format)39are pipeline mechanics; the Qodo platform consolidates and renders findings.40Their reasoning rules survive inside kernel-review-discipline.4142## Review order43441. Load kernel-subsystem-guides and match the diff against its trigger45 table. Load every matching guide before analysis.462. Apply each in-scope lens to the diff. Collect candidate concerns.473. Pass every candidate through kernel-review-discipline: prove it or drop48 it, then calibrate severity. Only survivors become findings.4950## Mapping a finding to the contract5152- action_level: action_required for a proven correctness, memory-safety,53 locking, or security defect; remediation_recommended for a weaker or54 speculative case; informational for a note.55- category: Security, Correctness, or Maintainability.56- evidence: cite file, function, exact line when known, the triggering57 condition, and the lens rule id. Never invent line numbers.5859## What NOT to flag6061- Style, naming, formatting, typos in comments (checkpatch territory).62- Defensive checks you cannot prove are reachable with bad data.63- Ignored returns from calls that cannot fail, or from debugfs APIs.64- Pre-existing low/medium issues not introduced by this patch.65- Removal of assertions/WARN/BUG as a regression.6667## Sourcing6869Protocol derived from Sashiko (Apache-2.0, sashiko-dev/sashiko) and Chris70Mason's review-prompts (MIT, masoncl/review-prompts). Reference files under71the lens skills reproduce masoncl content under its MIT license.
gvago