Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
| Layer | Technology |
|---|---|
| Backend | Python, psutil, FastAPI (REST API), curses (TUI) |
| Frontend | Vue.js, Bootstrap 5, SCSS |
| Export plugins | InfluxDB, MongoDB, MQTT, DuckDB, and others |
| Infrastructure | GitHub Actions, Helm/Kubernetes, Snap (snapcraft) |
| LLM abstraction | LiteLLM (multi-provider) |
| GPU/NPU monitoring | pynvml, sysfs/debugfs |
Wrap the open() call inside try/except, not just the read(). Snap's strict
confinement blocks host file access at the open stage, not the read stage.
Glances runs unauthenticated by default — this is intentional and documented. Most users deploy on private networks for personal use. See global CLAUDE.md for the general OSS security philosophy (4 rules).
/api/4/configand/api/4/args— never expose credentials in plain text (InfluxDB passwords, MongoDB tokens, MQTT passphrases, SSL key paths, etc.) for unauthenticated access. Use the conditionalas_dict_secure()method, applied whenself.args.passwordisFalse.- CORS:
allow_origins=["*"]+allow_credentials=Trueis invalid per the CORS spec and reflected by Starlette. Default:allow_credentials=False. - DNS rebinding:
TrustedHostMiddlewareviawebui_allowed_hosts(optional). The MCP endpoint is already protected viamcp_allowed_hosts+TransportSecuritySettingsinglances/outputs/glances_mcp.py.
- The code is actively used (no dead code)
- Existing tests pass
- New behaviour is covered by tests
- New configuration keys are documented
- Breaking changes are identified and documented
- The PR targets the correct branch
- Code should be formated and linted (make lint && make format)
| Deliverable | Format |
|---|---|
| Changelog entry | .rst file following the NEWS.rst format |
| Helm Chart | .tgz archive or structured directory |
Stack: Vue.js + Bootstrap 5 + SCSS.
Design principles:
- Strict typographic consistency across all plugins (size, weight, opacity, letter-spacing).
- Pixel-perfect sparkline alignment (CSS grid, fixed row heights).
- Footer = vertical alert list (up to 10 entries), not a single horizontal row.
- No gauges — prefer sparklines with an inline current value.
- 256-colour system with automatic fallback for limited terminals.
- Lightweight hierarchical separators for information density.
These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.