How to analyze and respond to GitHub PR review comments in NetAlertX. Use this whenever you are addressing PR feedback, review threads, or inline code comments.
74
91%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Run through this before creating or editing any file under test/:
test/db_test_helpers.py for existing factories (make_db, make_device_dict, insert_device_from_dict, DummyDB). Use them. If what you need doesn't exist, add it there — never define it locally in the test file.aa:bb:cc:dd:ee:01). No exceptions.test/ that mirrors the source path (e.g. test/scan/ for server/scan/). Don't add new files directly in test/ root - a handful of existing ones there (e.g. test_plugin_helper.py, test_wol_validation.py) predate this convention; that's not license to add more, but don't migrate them unprompted either.code-standards skill — all code changes must comply with it before replying.testing-workflow skill — any test additions or changes must follow it.database-patterns for DB writes, settings-management for config).For each comment, determine:
| Type | Action |
|---|---|
| Request for code change | Make the change, validate it, then reply with the short commit hash |
| Question about code | Reply with a concise answer (no restatement of the question) |
| Suggestion / feedback | Decide if it is actionable. If yes, act and reply. If not, do not reply. |
| General / praise | Do not reply. |
testing-workflow skill).grep -Pn '[0-9A-F]{2}:[0-9A-F]' test/ must be empty.DummyDB, make_db, or inline DDL defined outside test/db_test_helpers.py.test/ matching the source path, not in test/ root.When a PR targets a non-default branch (e.g. next_release):
014b960
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.