Back to skill
Skillv1.0.1
ClawScan security
Auto Sec Blogger · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
SuspiciousMar 14, 2026, 7:46 AM
- Verdict
- suspicious
- Confidence
- high
- Model
- gpt-5-mini
- Summary
- The code and runtime instructions largely match a blog automation pipeline, but there are multiple incoherences (hardcoded user paths, mismatched environment variable names, and scripts that execute git/npx and write to the host) that make this package risky to run without manual audit and configuration.
- Guidance
- Before installing or running this skill: - Treat the package as a third-party repo snapshot that needs manual review — it contains hardcoded user paths (e.g., /Users/rebugui, /Users/nabang) and will try to read .env files from those locations. - Expect it to require API keys (GLM/Notion) and a GitHub token even though the registry metadata lists none. Verify and set the exact environment variable names the code expects (search for INTELLIGENCE_* vs GLM_API_KEY/NOTION_API_KEY) and remove/rename any references to other users' paths. - Audit all scripts that call subprocess (git, npx/mermaid-cli) and any filesystem writes (creating posts, logs). These will modify your home/workspace and can push to remote repositories. - If you want to test: run in an isolated environment (container or dedicated test user) with minimal-scope tokens (restrict GitHub token to the single repo, use Notion integration with scoped DB access), and point BLOG paths to a disposable repo. - Do not enable background service/launchd or cron scheduling until you confirm configuration, remove hardcoded paths, and are comfortable with automatic pushes to GitHub. - If you are not comfortable auditing the code, avoid installing or only use a vetted fork from a known source (e.g., the original GitHub repo) and verify environment-variable and path changes before running.
Review Dimensions
- Purpose & Capability
- noteThe files implement the claimed functionality (news collection → LLM generation → Notion draft → Git publish). That matches the description. However, the package appears to be a direct copy of an existing repo repackaged for this skill (references to github.com/rebugui/intelligence-agent) and contains many project-specific defaults and user-home absolute paths which are not appropriate for a generic skill.
- Instruction Scope
- concernSKILL.md asks you to set GLM/Notion/GitHub env vars and run scripts, but the actual code reads many environment variables with different names (e.g., INTELLIGENCE_* prefixes) and loads a .env from hardcoded locations. Scripts also instruct and perform actions outside the narrow 'generate a draft' scope: they read/write files in the user home, create logs, convert Mermaid via npx, run git commit/push, and include a background service (launchd) helper. These actions grant broad filesystem, network, and git access beyond a simple content generator.
- Install Mechanism
- noteNo install spec is provided (instruction-only), so nothing will be automatically downloaded by the skill system. However, the code assumes external tools (git, node/npx, mermaid-cli) and Python dependencies exist and will call subprocesses (npx, git). That implicit reliance on host tooling increases runtime risk if the host environment is not tightly controlled.
- Credentials
- concernThe registry metadata declares no required env vars, but SKILL.md and code demand multiple secrets (GLM API key, Notion API key/database id, GitHub token, DB path, blog repo path, etc.). There are inconsistent variable names across files (GLM_API_KEY vs INTELLIGENCE_LLM_API_KEY; NOTION_API_KEY vs INTELLIGENCE_NOTION_TOKEN; BLOG_DATABASE_ID vs INTELLIGENCE_BLOG_DATABASE_ID), which can cause the code to load unexpected values or fall back to defaults. Some scripts load a .env from absolute user paths (e.g., '/Users/rebugui/...'), which could accidentally expose local secrets if present.
- Persistence & Privilege
- concernThe skill does not set always:true, but included scripts are designed to run as background services (git_publisher_service, auto_publish_approved) and to be scheduled (cron/apscheduler). If a user enables them, they will run periodically, access Notion and GitHub, modify local blog repositories, and push to remote origins. Combined with the filesystem and subprocess usage, this capability allows autonomous publishing and persistent activity — so treat service enablement carefully.
