Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent Postgres best-practices reference skill, with expected database-change guidance but no hidden execution, persistence, or exfiltration behavior.
Install this as a documentation/reference skill for Postgres work, not as an automation you blindly apply to production. Review generated SQL before execution, especially examples involving ALTER SYSTEM, COPY, EXPLAIN ANALYZE, DROP, grants/revokes, RLS policies, or statistics resets, and prefer staging or backups for high-impact changes.
The manifest description says to load the skill before writing or changing 'anything that lives in a Postgres database' and also for many diagnosis scenarios. This trigger scope is extremely broad and lacks explicit boundaries or negative examples, increasing the chance of unintended invocation across routine database work.
This is a markdown file, so SQP-2 applies to omitted warnings about behaviors that could affect user data or system integrity. The guidance uses alter system and reloads configuration to terminate idle or idle-in-transaction sessions, but it does not warn users that affected sessions may be disconnected and uncommitted work may be lost or rolled back.
This markdown file falls under the markdown scope for missing user warnings. The guidance introduces a high-impact database operation that reads from a local path and loads data into a table, but it provides no warning about validating the file source, target table, or the risk of large-scale unintended data modification.
This guidance recommends EXPLAIN ANALYZE broadly and says it executes the query, but it does not warn that on non-SELECT statements it will actually run the statement and can trigger writes, function side effects, triggers, or external actions. In a database best-practices skill, that omission is risky because users may apply the advice to UPDATE, DELETE, INSERT, or function calls while diagnosing production issues.
The guidance recommends calling pg_stat_statements_reset() without warning that it clears accumulated query statistics for the entire tracked dataset. In a monitoring and tuning context, this can cause loss of historical performance visibility, disrupt ongoing investigations, and make before/after comparisons unreliable if run prematurely or by the wrong operator.
No suspicious patterns detected.
