Overnight Worker
PassAudited by ClawScan on May 10, 2026.
Overview
This appears to be a coherent productivity skill, but it runs unattended with broad local/web tools and optional external notifications, so users should scope tasks carefully.
Before installing, make sure you are comfortable letting this skill run an unattended task with Bash, local file, web-search, and agent tools. Keep tasks narrowly scoped, avoid broad or sensitive local paths unless needed, use trusted notification endpoints, and review the output directory and logs in the morning.
Findings (6)
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.
A broadly worded task could lead the agent to read many local files, search the web, write outputs, or run helper shell commands while the user is away.
The skill grants broad local, web, shell, and agent/delegation tools for an unattended workflow. This is aligned with an overnight work agent, but users should understand the authority being delegated.
allowed-tools:\n - Bash\n - Read\n - Write\n - Edit\n - Grep\n - Glob\n - WebSearch\n - WebFetch\n - Task\n - Agent
Use specific task scopes, name exact directories for code review or data work, and review the generated PLAN.md and progress.log afterward.
If task text containing shell metacharacters were copied into a shell command unsafely, it could behave differently than intended.
The workflow passes the user’s task text into a Bash-based classifier. The referenced script quotes its positional argument, but the skill should ensure the $ARGUMENTS placeholder is not re-rendered into shell code.
TASK_DESC="$ARGUMENTS"\nTASK_TYPE=$(bash "$(dirname "$0")/scripts/task-classifier.sh" "$TASK_DESC")
Treat the task description as data, not executable shell text; avoid pasting untrusted shell-like strings into the task description.
Anyone with access to those environment variables could potentially send messages through the configured bot or endpoint.
The notification helper reads optional environment variables for Telegram and webhook delivery. These credentials/endpoints are expected for the notification feature and are not hardcoded.
TELEGRAM_BOT_TOKEN="${TELEGRAM_BOT_TOKEN:-}"\nTELEGRAM_CHAT_ID="${TELEGRAM_CHAT_ID:-}"\nWEBHOOK_URL="${WEBHOOK_URL:-}"Use a dedicated Telegram bot or webhook endpoint, keep tokens out of shared shells/logs, and unset them when not needed.
Completion details, notification text, timestamps, and output paths may be sent to Telegram or a webhook service.
The webhook notification sends a JSON payload to a user-configured external URL. This is disclosed and purpose-aligned, but it crosses a data boundary.
curl -s -w "\n%{http_code}" \\\n -X POST "$WEBHOOK_URL" \\\n -H "Content-Type: application/json" \\\n -d "$payload"Use only trusted notification endpoints, and choose local macOS/stdout notifications for sensitive work.
Users have less registry-level provenance information to verify where the skill came from.
The registry metadata does not provide a source URL or homepage, although the reviewed artifacts include the helper scripts. This is a provenance limitation rather than evidence of malicious behavior.
Source: unknown\nHomepage: none\nNo install spec — this is an instruction-only skill.
Install only from a trusted registry entry or a repository you can verify, and re-check scripts after updates.
If the normal output directory cannot be written, generated files could be placed outside the documented output tree.
The README presents a strong safety claim. The SKILL.md error matrix also allows a write-failure fallback to `/tmp`, so users should know there is an exception to the normal output-directory boundary.
🛡️ **Safety Contracts** — Write-only to output directory, no file deletion, no arbitrary code execution
Keep the output directory writable, and check progress.log for any fallback writes if a run reports file-write problems.