Database Operations
PassAudited by ClawScan on May 1, 2026.
Overview
This instruction-only database helper is coherent and does not install or run code, but its SQL examples can change databases and should be reviewed before use.
This skill appears safe to install as an instruction-only database assistant. Before using its generated SQL in a real database, review migrations, dynamic functions, triggers, and audit logging carefully, especially in production or when user data is involved.
Findings (2)
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 copied directly into an application, a generic soft-delete function could affect unintended tables or expose a broad data-mutation primitive.
The example defines a generic dynamic SQL function that updates whichever table name is supplied. Identifier quoting reduces injection risk, but the pattern is broad unless callers and allowed tables are constrained.
CREATE OR REPLACE FUNCTION soft_delete(p_table TEXT, p_id BIGINT) ... EXECUTE format('UPDATE %I SET deleted_at = CURRENT_TIMESTAMP WHERE id = $1 AND deleted_at IS NULL', p_table)Use an allow-list or per-table functions, restrict EXECUTE permissions, and require human review before applying database-changing SQL.
Audit logs could retain extra copies of sensitive user data if the pattern is applied without redaction or retention controls.
The audit trail pattern stores full before-and-after row values for the users table, whose example schema includes sensitive fields such as email and password_hash.
CREATE TABLE audit_log (... old_values JSONB, new_values JSONB ...); ... AFTER INSERT OR UPDATE OR DELETE ON users ... to_jsonb(OLD) ... to_jsonb(NEW)
Exclude or redact sensitive fields from audit logs, limit who can read audit tables, and define retention policies before using this pattern.