Activated Claude Code review on new PRs

[Hauke Mehrtens]

Hi,

I was added to the Claude for Open Source Program today and got Claude 
code Max for 6 months for free. Thank you Anthropic.

They also released Claude Code routines today. This allows to trigger a 
predefined action on a timer or event. I configured a trigger to do a 
review on newly opened PRs in the OpenWrt repository. This is not using 
the API payment interface, but the subscription which is much cheaper. 
This is restricted to only 15 runs per day.
https://code.claude.com/docs/en/routines

Here is an example review:
https://github.com/hauke/openwrt/pull/12

It is using my account to read and write the messages, maybe we should 
use a separate bot account.

I attached the current prompt to this mail. We can should modify it 
based on the results. Maybe it is too picky, maybe it missed some stuff.

Hauke

-----------------------------

Review this OpenWrt pull request for problems and policy violations.

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.