Thanks for improving openclaw-security-radar.
This repo should stay practical.
We prefer:
- short review checklists
- reusable templates
- concrete risk language
- field-tested hardening notes
We avoid:
- vague fear-driven writing
- generic security filler
- very long essays with no actionable output
Useful contributions include:
- new checklists
- stronger template wording
- documented risk patterns
- safer operational defaults
- connector-specific review guidance
- Keep content concise.
- Write for builders, not only for security specialists.
- Explain why a risk matters in OpenClaw terms.
- Prefer practical review steps over abstract theory.
- What risk or workflow does this improve?
- Who should use it?
- What action should a builder take after reading it?
- Is the wording simple enough to use in a real review?