mirror of
https://github.com/jokob-sk/NetAlertX.git
synced 2026-09-14 15:25:32 -04:00
chore: add missing pr-analysis and logging-standards skills
Co-authored-by: jokob-sk <96159884+jokob-sk@users.noreply.github.com>
This commit is contained in:
copilot-swe-agent[bot]andjokob-sk authored and GitHub committed
1 parent
f52cc50705
commit
66db9a4b57
6 files changed
+243
No files matched your search
@@ -0,0 +1,67 @@
|
||||
---
|
||||
name: logging-standards
|
||||
description: Logging conventions for NetAlertX backend Python code. Use this when adding, modifying, or reviewing log statements.
|
||||
---
|
||||
|
||||
# Logging Standards
|
||||
|
||||
## Import
|
||||
|
||||
```python
|
||||
from logger import mylog
|
||||
```
|
||||
|
||||
Never import `logging` directly in application code. Use `mylog` exclusively.
|
||||
|
||||
## Function Signature
|
||||
|
||||
```python
|
||||
mylog(level, message_or_list)
|
||||
```
|
||||
|
||||
`message_or_list` can be a plain string or a list of values — the logger joins them with spaces.
|
||||
|
||||
## Log Levels
|
||||
|
||||
Levels from least to most verbose (higher number = more output):
|
||||
|
||||
| Level | Numeric | When to use |
|
||||
|-------|---------|-------------|
|
||||
| `"none"` | 0 | Always printed regardless of user setting. Reserve for startup, fatal errors, and one-time permission checks. |
|
||||
| `"minimal"` | 1 | Important state transitions visible by default (scan start/end, plugin finish, restart). |
|
||||
| `"verbose"` | 2 | Informational progress — what the system is doing without clutter (e.g. "No changes to report"). |
|
||||
| `"debug"` | 3 | Developer-level detail — loop decisions, branch taken, counts. |
|
||||
| `"trace"` | 4 | Granular per-item tracing — individual device rows, SQL queries, raw values. |
|
||||
|
||||
## Message Format
|
||||
|
||||
Prefix every message with a `[Module]` tag matching the file/function context:
|
||||
|
||||
```python
|
||||
mylog("debug", [f"[device_handling] Processing MAC: {mac}"])
|
||||
mylog("verbose", ["[Scan] Scan complete — devices updated:", count])
|
||||
```
|
||||
|
||||
Use `f-strings` inside a list element, not string concatenation:
|
||||
|
||||
```python
|
||||
# Correct
|
||||
mylog("debug", [f"[NIC] parent={parent_mac} nic_online={nic_online}"])
|
||||
|
||||
# Avoid
|
||||
mylog("debug", "[NIC] parent=" + parent_mac + " nic_online=" + str(nic_online))
|
||||
```
|
||||
|
||||
## Timestamp
|
||||
|
||||
`mylog` / `file_print` prepend the current local-timezone time automatically via `timeNowTZ`. Do **not** add a timestamp manually inside the message.
|
||||
|
||||
## What NOT to Log
|
||||
|
||||
- Do not log raw user input without sanitization.
|
||||
- Do not log full SQL query strings at `"none"` or `"minimal"` — use `"trace"` at most.
|
||||
- Do not use `print()` in server code — use `mylog`. `file_print` is an internal helper; do not call it directly.
|
||||
|
||||
## Log File Location
|
||||
|
||||
Written to `{logPath}/app.log` (`logPath` from `const.py` → `/tmp/logs` at runtime). Do not hardcode this path.
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
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 Acting on Any PR Comment
|
||||
|
||||
1. Load `code-standards` skill — all code changes must comply with it before replying.
|
||||
2. Load `testing-workflow` skill — any test additions or changes must follow it.
|
||||
3. 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
|
||||
|
||||
1. **Identify all actionable comments** before touching any file.
|
||||
2. **Load relevant skills** to understand conventions that apply.
|
||||
3. **Prepare a plan** — list each file and the exact change required.
|
||||
4. **Make changes one comment at a time** — keep commits focused.
|
||||
5. **Run targeted tests** after each change (`testing-workflow` skill).
|
||||
6. **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
|
||||
|
||||
- All MACs are lowercase everywhere (code-standards).
|
||||
- No mocks or DB helpers are re-defined locally — use `test/db_test_helpers.py` (code-standards).
|
||||
- No inline imports — all imports at the top of the file (code-standards).
|
||||
- Tests live under a subdirectory of `test/` matching the source path, not in `test/` root (code-standards).
|
||||
|
||||
## 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.
|
||||
@@ -24,6 +24,8 @@ Skills with the same purpose exist in both, sometimes under different names and
|
||||
| Project navigation | `project-navigation` | `project-navigation` | Copilot version has full path tables and env vars; Gemini version is a brief reference |
|
||||
| Plugin dev | `plugin-development` | `plugin-run-development` | Copilot version is comprehensive (data contract, phases, formats); Gemini version is a brief checklist pointing to `docs/PLUGINS_DEV.md` |
|
||||
| Devcontainer | `devcontainer-management` | `devcontainer-services` + `devcontainer-setup` + `devcontainer-configs` | Gemini combines into one (uses `docker exec`); Copilot splits into 3 focused skills |
|
||||
| PR review | `pr-analysis` | `pr-analysis` | How to classify and respond to PR comments; pre-flight skill loading checklist |
|
||||
| Logging | `logging-standards` | `logging-standards` | `mylog` levels, message format, what not to log |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
name: netalertx-logging-standards
|
||||
description: Logging conventions for NetAlertX backend Python code. Use this when adding, modifying, or reviewing log statements.
|
||||
---
|
||||
|
||||
# Logging Standards
|
||||
|
||||
## Import
|
||||
|
||||
```python
|
||||
from logger import mylog
|
||||
```
|
||||
|
||||
Never import `logging` directly in application code. Use `mylog` exclusively.
|
||||
|
||||
## Function Signature
|
||||
|
||||
```python
|
||||
mylog(level, message_or_list)
|
||||
```
|
||||
|
||||
`message_or_list` can be a plain string or a list of values — the logger joins them with spaces.
|
||||
|
||||
## Log Levels
|
||||
|
||||
Levels from least to most verbose (higher number = more output):
|
||||
|
||||
| Level | Numeric | When to use |
|
||||
|-------|---------|-------------|
|
||||
| `"none"` | 0 | Always printed regardless of user setting. Reserve for startup, fatal errors, and one-time permission checks. |
|
||||
| `"minimal"` | 1 | Important state transitions visible by default (scan start/end, plugin finish, restart). |
|
||||
| `"verbose"` | 2 | Informational progress — what the system is doing without clutter (e.g. "No changes to report"). |
|
||||
| `"debug"` | 3 | Developer-level detail — loop decisions, branch taken, counts. |
|
||||
| `"trace"` | 4 | Granular per-item tracing — individual device rows, SQL queries, raw values. |
|
||||
|
||||
## Message Format
|
||||
|
||||
Prefix every message with a `[Module]` tag matching the file/function context:
|
||||
|
||||
```python
|
||||
mylog("debug", [f"[device_handling] Processing MAC: {mac}"])
|
||||
mylog("verbose", ["[Scan] Scan complete — devices updated:", count])
|
||||
```
|
||||
|
||||
Use `f-strings` inside a list element, not string concatenation:
|
||||
|
||||
```python
|
||||
# Correct
|
||||
mylog("debug", [f"[NIC] parent={parent_mac} nic_online={nic_online}"])
|
||||
|
||||
# Avoid
|
||||
mylog("debug", "[NIC] parent=" + parent_mac + " nic_online=" + str(nic_online))
|
||||
```
|
||||
|
||||
## Timestamp
|
||||
|
||||
`mylog` / `file_print` prepend the current local-timezone time automatically via `timeNowTZ`. Do **not** add a timestamp manually inside the message.
|
||||
|
||||
## What NOT to Log
|
||||
|
||||
- Do not log raw user input without sanitization.
|
||||
- Do not log full SQL query strings at `"none"` or `"minimal"` — use `"trace"` at most.
|
||||
- Do not use `print()` in server code — use `mylog`. `file_print` is an internal helper; do not call it directly.
|
||||
|
||||
## Log File Location
|
||||
|
||||
Written to `{logPath}/app.log` (`logPath` from `const.py` → `/tmp/logs` at runtime). Do not hardcode this path.
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: netalertx-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 Acting on Any PR Comment
|
||||
|
||||
1. Load `code-standards` skill — all code changes must comply with it before replying.
|
||||
2. Load `testing-workflow` skill — any test additions or changes must follow it.
|
||||
3. Load any domain-specific skill relevant to the files being changed (e.g. `database-patterns` for DB writes, `settings-management` 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
|
||||
|
||||
1. **Identify all actionable comments** before touching any file.
|
||||
2. **Load relevant skills** to understand conventions that apply.
|
||||
3. **Prepare a plan** — list each file and the exact change required.
|
||||
4. **Make changes one comment at a time** — keep commits focused.
|
||||
5. **Run targeted tests** after each change (`testing-workflow` skill).
|
||||
6. **Reply** only after the commit is pushed via `report_progress`. 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
|
||||
|
||||
- All MACs are lowercase everywhere (code-standards).
|
||||
- No mocks or DB helpers are re-defined locally — use `test/db_test_helpers.py` (code-standards).
|
||||
- No inline imports — all imports at the top of the file (code-standards).
|
||||
- Tests live under a subdirectory of `test/` matching the source path, not in `test/` root (code-standards).
|
||||
- Secret scan (`runtime-tools-secret_scanning`) before committing.
|
||||
|
||||
## 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.
|
||||
@@ -24,6 +24,8 @@ Skills with the same purpose exist in both, sometimes under different names and
|
||||
| Project navigation | `project-navigation` | `project-navigation` | Copilot version has full path tables and env vars; Gemini version is a brief reference |
|
||||
| Plugin dev | `plugin-run-development` | `plugin-development` | Copilot version is comprehensive (data contract, phases, formats); Gemini version is a brief checklist pointing to `docs/PLUGINS_DEV.md` |
|
||||
| Devcontainer | `devcontainer-services` + `devcontainer-setup` + `devcontainer-configs` | `devcontainer-management` | Copilot splits into 3 focused skills; Gemini combines into one (uses `docker exec`) |
|
||||
| PR review | `pr-analysis` | `pr-analysis` | How to classify and respond to PR comments; pre-flight skill loading checklist |
|
||||
| Logging | `logging-standards` | `logging-standards` | `mylog` levels, message format, what not to log |
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in new issue
Block a user