Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Database Schema Sync
v1.0.0Database schema management using idempotent sync script instead of Alembic migrations. Use when (1) Adding new database tables, (2) Adding new columns to exi...
⭐ 0· 51·1 current·1 all-time
byToby Morning@urbantech
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The skill claims to manage production schema via an idempotent sync script and includes examples and a verification helper. That purpose aligns with the example code and docs. However, the manifest declares no required env vars or config paths, while SKILL.md and the verify script expect a production DATABASE_URL and a script located at /Users/tobymorning/Desktop/core/scripts/sync-production-schema.py. The skill does not include the actual sync-production-schema.py file. Hard-coded, single-user absolute paths in 'Required Locations' are disproportionate for a reusable skill and suggest either a packaged personal repo or incomplete packaging.
Instruction Scope
Runtime instructions tell the agent to run python scripts/sync-production-schema.py --dry-run and --apply against production, export DATABASE_URL, and run psql against the production DB. Those actions are expected for schema tooling, but the instructions assume a local file location that may not exist and instruct running scripts that are not present in the package. The included verify script also attempts to change file permissions (chmod +x) on an absolute path and greps for functions in that file—these are file-system modifications and checks outside the skill manifest. SKILL.md references environment variables (DATABASE_URL) and exact filesystem paths that are not declared in the skill metadata. The instructions are prescriptive ('ALWAYS use', 'NEVER run alembic in production') and could lead to dangerous operations if the actual sync script is malicious or buggy.
Install Mechanism
There is no install spec — instruction-only plus a small verify script — so nothing will be automatically downloaded or installed. That reduces supply-chain risk. However, the verify script (provided) will attempt to modify local filesystem permissions when executed, so running it has side effects despite no formal install step.
Credentials
The manifest lists no required environment variables or primary credential, but the SKILL.md explicitly instructs exporting and using DATABASE_URL (production DB credentials). Requesting production DB access is reasonable for a schema tool, but the omission from requires.env is an incoherence. The skill also expects access to a specific user's filesystem path; those path requirements are not declared. The combination (undeclared use of sensitive DB credentials + hard-coded local paths) is disproportionate and should be clarified before use.
Persistence & Privilege
The skill is not always-enabled and does not request permanent presence or elevated platform privileges. It does, however, permit the agent to be invoked normally. There is no evidence it tries to modify other skills or system-wide agent settings.
What to consider before installing
Do not run anything on production until you inspect the actual sync script. Specific actions to take before using/installing: 1) Ask the publisher for the full scripts/sync-production-schema.py used by the skill (it is not included) and review its source for any network calls, secrets exfiltration, or unsafe SQL. 2) Confirm why the skill manifest omits DATABASE_URL and other env requirements — treat DATABASE_URL as a sensitive secret and only provide it in a controlled CI environment or ephemeral shell after code review. 3) Beware the included verify script: it will check for the script at an absolute user-specific path and attempt to chmod it; running the verifier may change file permissions on your machine. 4) Prefer running the sync script first against a copy of production (snapshot or staging) and always run --dry-run. 5) If you rely on this approach, require code review, automated testing, and backups/DB snapshots before applying to production. If you cannot review the sync script, do not run it against production; consider using well-known migration tools (Alembic) or a vetted internal process instead.Like a lobster shell, security has layers — review code before you run it.
latestvk97dy4zeeft8n77kpwv1t3jz0s83gkbq
License
MIT-0
Free to use, modify, and redistribute. No attribution required.