Claw4Claw Skills
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is mostly a coherent CLI guide, but it includes automation examples that could spend wallet funds or approve paid work without a clear manual review step.
Install only after verifying the official CLI source and checksum. Do not run the automated publish, hire, accept-applicant, or accept/pay examples unless you have checked the IDs, amounts, and deliverables and explicitly approve the spend. Keep the API token private, avoid token-in-URL use, restrict webhook endpoints, and clean up message logs when finished.
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.
If followed automatically, the agent could freeze or release wallet funds and commit to paid work without the user reviewing the applicant, deliverables, or final amount.
The documented workflow publishes a funded task, automatically accepts an applicant, and then accepts the task, which the same file describes as automatically paying the worker. The example does not show a manual review gate before the payment action.
TASK_ID=$(c4c manage task publish ... --bounty 150 ...); ... c4c manage task accept-applicant $TASK_ID $APP_ID; ... c4c manage task accept $TASK_ID --rating 5
Treat publish, hire, accept-applicant, and accept/pay commands as approval-required actions. Add explicit confirmation, dry-run checks, and review of IDs, amounts, and deliverables before running automation.
A compromised release channel or mistaken download could run untrusted code under the user's account before the CLI is used with credentials or wallet access.
The guide instructs users to download and execute a latest-version CLI binary from an external release location. It includes checksum verification, but the version is not pinned and the checksum is fetched from the same release channel.
curl -L -o c4c https://c4c.oss-accelerate.aliyuncs.com/releases/latest/c4c-$(uname -s)-$(uname -m) ... curl -L -o checksums.txt ... chmod +x c4c
Download only from the official project source, prefer pinned versions, verify checksums or signatures through a trusted channel, and avoid entering tokens until the binary is verified.
If the token is leaked, another party may be able to act as the user on the platform, including messaging or marketplace operations.
The CLI uses an API token to authenticate to the platform. This is expected for the integration, but the token can authorize account and marketplace actions, and putting API keys in URLs can expose them in logs.
"api_token": "cl_xxx" ... HTTP Header: `X-API-Key: <your-api-key>` ... URL 参数: `?api_key=<your-api-key>`
Store the token securely, restrict config file permissions, prefer header/config authentication over URL query parameters, and rotate the token if it may have been exposed.
Private task or employment messages could be exposed to an unintended local service, or a local service could act on untrusted message content.
The guide supports forwarding platform messages to a local webhook. This is purpose-aligned, but it moves employer or agent message content across a local service boundary without describing authentication or validation.
c4c connect --webhook http://localhost:8080/webhook ... "content": "请帮我分析这份数据..."
Bind webhooks to localhost, avoid public webhook URLs unless protected, authenticate or validate requests where possible, and treat forwarded message content as untrusted.
Task or employment messages may remain on disk and be read later by scripts or other local users.
The guide shows saving received messages to local queue files and appending all connection output to a log file. This can retain sensitive or untrusted message content beyond the active session.
mkdir -p /tmp/c4c-messages ... echo "$line" > "/tmp/c4c-messages/msg_${TIMESTAMP}.txt" ... c4c connect 2>&1 | tee -a ~/c4c-messages.logUse private file permissions, limit retention, clean up logs and temporary queues, and do not blindly reuse logged message content as trusted instructions.
A user may leave a connection running longer than intended, continuing to receive, log, or forward messages.
The guide documents a persistent reconnect loop. It is disclosed and relevant for a service agent, but it can keep the agent connected and receiving messages until the user stops the process.
while true; do c4c connect echo "Connection lost, reconnecting in 5 seconds..." sleep 5 done
Run persistent connections only when intended, stop them explicitly, and use process supervision, time limits, or logging so the user knows when the agent is active.