| name | pr-analysis |
| description | 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. |
PR Analysis
Before Writing Any Test Code — Non-Negotiable Checklist
Run through this before creating or editing any file under test/:
- Helpers first: Check
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.
- MAC literals must be lowercase: Every MAC string in fixtures, parametrize, assertions, docstrings, and comments must be lowercase hex (e.g.
aa:bb:cc:dd:ee:01). No exceptions.
- Test file location: Place tests under a subdirectory of
test/ that mirrors the source path (e.g. test/scan/ for server/scan/). Never put test files directly in test/.
- No inline imports: All imports at the top of the file.
Before Acting on Any PR Comment
- Load
code-standards skill — all code changes must comply with it before replying.
- Load
testing-workflow skill — any test additions or changes must follow it.
- Load any domain-specific skill relevant to the files being changed (e.g.
database-patterns for DB writes, settings for config).
Comment Classification
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. |
Acting on Comments — Step by Step
- Identify all actionable comments before touching any file.
- Load relevant skills to understand conventions that apply.
- Prepare a plan — list each file and the exact change required.
- Make changes one comment at a time — keep commits focused.
- Run targeted tests after each change (
testing-workflow skill).
- Reply only after the commit is pushed. Include the short SHA.
Reply Guidelines
- Be concise. Do not summarize or restate the original comment.
- State what was done and (optionally) why.
- Include the short commit hash when relevant.
- Do not thank or compliment the reviewer.
What to Check After Every Batch of Changes
- MAC literals lowercase — grep for uppercase hex in every changed test file:
grep -Pn '[0-9A-F]{2}:[0-9A-F]' test/ must be empty.
- No local DB helpers — no
DummyDB, make_db, or inline DDL defined outside test/db_test_helpers.py.
- No inline imports — all imports at the top of the file.
- Tests live under a subdirectory of
test/ matching the source path, not in test/ root.
Stacked / Base-Branch Issues
When a PR targets a non-default branch (e.g. next_release):
- Do not retarget the branch yourself; note it in a reply so the author can do it from the GitHub UI.
- Check CI failures on the base branch first before checking your branch.
