PostgreSQL Database
WarnAudited by ClawScan on May 18, 2026.
Overview
This appears to be a legitimate PostgreSQL administration skill, but it can use database credentials to run arbitrary SQL against production databases without built-in confirmation or scoping safeguards.
Install only if you intentionally want an agent to help operate PostgreSQL. Use least-privileged credentials, prefer read-only accounts for inspection, avoid running it in untrusted project directories, and require manual review before any data-changing SQL, restore, export, or backup-retention action.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If used with a powerful database account, a mistaken or overbroad instruction could alter, delete, or expose production database data.
The helper passes the caller-supplied SQL string directly to psql. This is coherent for a database skill, but it gives the agent raw database mutation authority with no built-in approval, read-only mode, transaction wrapper, or destructive-action guard.
PGPASSWORD="${DB_PASSWORD}" psql \
-h "$DB_HOST" \
-p "$DB_PORT" \
-U "$DB_USER" \
-d "$DB_NAME" \
-c "$1"Use a least-privileged database user, prefer read-only credentials for inspection tasks, and require explicit human approval plus backups/transactions before UPDATE, DELETE, DDL, restore, or bulk export operations.
Users may not realize at install time that the skill will rely on credentials capable of accessing or changing their database.
The skill explicitly requires database credentials and local credential files, while the supplied registry metadata lists no required env vars and no primary credential. That under-declares a high-impact permission boundary.
本技能需要以下权限： - 读取数据库凭证（`.env` 或 `~/.pgpass`） ... 需要环境变量：DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD 或使用~/.pgpass 文件存储凭证。
Declare the required DB credential environment variables in metadata, document the expected privilege level, and use separate low-privilege/read-only accounts whenever possible.
Running the script in a directory with an untrusted .env file could execute unintended shell commands.
The scripts load .env with shell source semantics. This is a common way to load DB settings, but it executes any shell content in .env rather than only parsing key/value variables.
if [ -f .env ]; then
source .env
fiOnly run these scripts in trusted directories, keep .env files simple and private, or replace source .env with a safer key/value parser.
Unexpected invocation or a poorly chosen backup directory could remove older recovery files matching the database-name pattern.
The backup script automatically deletes matching backups older than seven days in the chosen backup directory. This is disclosed and scoped, but backup deletion can affect recovery options.
find "$BACKUP_DIR" -name "${DB_NAME}_*.sql.gz" -mtime +7 -deleteConfirm the backup directory and retention policy before running, and keep independent backups for important production databases.