Security audit
Security checks for vulnerabilities and agentic risk
This is a plain coding-standards guide with some opinionated or broad guidance, but no hidden execution, persistence, credential use, or data access.
Install this if you want a strict, Alibaba-inspired OOP coding standards reference applied broadly to code review and generation. Review the naming and documentation preferences against your team's conventions, especially boolean fields and comment language, because the skill may push opinionated style choices.
The invocation description is broad enough that the skill could activate for many generic engineering tasks, including code generation, architecture, tests, and schema design across many languages. Over-broad activation can cause unintended instruction injection into unrelated workflows, overriding user intent or introducing rigid rules where they were not requested.
The document states that boolean fields in data objects must not be prefixed with is, giving isDeleted as a bad example. Later, it requires database boolean/flag fields to be named is_xxx, which directly conflicts when the skill is used for schema design alongside object/model design. This is an active contradiction inside the skill's own guidance, creating intent-code divergence in the documented standards.
The guidance says to prefer clear native language comments over broken English, which imposes a language choice without indicating user or team preference. This is a natural-language policy issue because it directs output/comment language behavior without offering opt-in or documenting a justified locale constraint.
