Activated Claude Code review on new PRs

[Daniel Golle]

On Wed, Apr 15, 2026 at 01:53:55AM +0200, Hauke Mehrtens wrote:
> Review this OpenWrt pull request for problems and policy violations.

Many of the prompt instructions seem redundant with the mechanical
existing CI. I'd not include them here again, it's a waste of
resources, as the classic CI costs a fraction -- and LLMs are not
actually that good doing those mechanical and precisely defined
things.

It could be better to ask the LLM to create scripts to carry out
those mechanical tasks than telling it to actually perform them
by itself.

Also, asking for more abstract things like "check if the commit
message accurately describes the intention of the author as well as
ALL the changes made by the commit" can work well.

Apart from that, imho this is a very good source of inspiration when
it comes to this class of tasks, (and you probably know it):

https://github.com/masoncl/review-prompts

Having some useful MCPs accessible during a code review also makes
the results much better -- compare it to having a hammer and a wrench,
or having to use your bare hands for the same task.

eg.
https://github.com/facebookexperimental/semcode
(which is used heavily by the review-prompts above)


Just my 2 cents...


> 
> Check every commit in the PR for the following. Report each problem
> as an inline comment on the relevant line, or in the top-level
> comment when there is no specific line to attach it to.
> Compare the changes with other commits to similar files.
> When new files like new dts files are added compare them to the existing
> files if they follow the same style.
> 
> ## Commit message rules (CI-enforced — hard failures)
> 
> - Subject line must match `<component>: <lowercase description>`.
>   The description must start with a lowercase letter.
> - Commit body must not be empty (only a Signed-off-by line is not enough
> - GitHub noreply addresses are rejected.
> - The name and email in Signed-off-by must exactly match the commit author
> field.
> - Subject line must not end with a period.
> - The commit body must not start with "This PR …" — write in imperative form
> as if it is the commit message, not a PR description.
> 
> ## PR structure
> 
> - No merge commits. The branch must be rebased on top of main.
> - Each commit must be a self-contained logical change. A later
>   commit must not undo or partially revert an earlier one in the
>   same series.
> - Draft PRs ([WIP] or GitHub Draft state) are acceptable while
>   hardware testing is ongoing, but flag if a non-draft PR
>   appears to lack hardware testing evidence.
> 
> ## Kernel patches
> 
> - Kernel patches that are not OpenWrt-specific (no OpenWrt
>   dependencies) should be submitted upstream to the Linux kernel
>   mailing list. Flag any such patches  and suggest upstreaming.
> - Kernel patch files must have a properly git patch header
> - Check that patches are placed in the correct directory
>   (e.g. `pending-<version>` vs `backport`).
> 
> ## DTS / Device Tree files
> 
> - Use the new array syntax for `reg` and similar properties.
> - LED nodes must use `color` and `function` properties — the deprecated
> `label` property must not be used.
> - MAC addresses must be assigned via `nvmem` cells in DTS, not hardcoded or
> left to random assignment at boot.
> - `label-mac-device` must point to the interface whose MAC address is
> printed on the device label sticker.
> - Bootloader and factory partitions must have `read-only`.
> - Multiple `compatible` strings must be separate quoted entries on one line,
> not a single string with a comma inside.
> - `device_type` must not appear except on `memory` and `cpu` nodes.
> 
> ## New device support
> 
> The commit message for any new device must include:
> - Hardware specs: SoC, RAM, flash size and type, Ethernet ports,
>   WiFi chips and bands, LEDs, buttons, USB ports.
> - Serial/UART console pinout (GND, RX, TX, VCC) and baud rate.
> - MAC address assignment table for every interface (LAN, WAN,
>   2.4 GHz, 5 GHz) and confirmation they match vendor firmware.
> - Step-by-step installation instructions (factory and sysupgrade).
> - Recovery instructions (how to return to stock firmware).
> 
> 
> ## Platform-specific checks
> 
> - **qualcommax**: WiFi board data must be submitted to
>   `openwrt/firmware_qca-wireless` first; the Makefile hash must
>   be updated in the same PR.
> 
> ## Coding style
> 
> - Match the indentation style of the surrounding file.
> - No accidental file mode changes (+x on non-executable files).
> - Sort list entries (dependencies, device profiles) alphabetically.
> - Run `./scripts/checkpatch.pl` on kernel C patches — flag any
>   obvious checkpatch violations visible in the diff.
> 
> ## Output rules
> 
> - For every problem tied to a specific file and line number, call
>   mcp__github_inline_comment__create_inline_comment to post an
>   inline comment directly on that diff line.
> - For problems not tied to a specific line (e.g. missing commit
>   body, wrong author), include them in the top-level comment.
> - Do NOT repeat in the top-level comment what you already said
>   in an inline comment.
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel