ℹ
Purpose & Capability
Name/description (dating/matching) align with required items: node/npm and a single LOVECLAW_API_TOKEN for a cloud API. Declared optional vars (LOVECLAW_API_BASE, OPENCLAW_BIN) are coherent for overriding endpoints or locating the CLI. Some local file access (session mapping, agent routes) is broader than a minimal chat-to-cloud router but is explainable by the need to resolve delivery targets and map phone→openclaw targets.
!
Instruction Scope
SKILL.md promises the heavy lifting occurs on the FC cloud side, but runtime scripts access several local files and system state: scripts/load-workspace-env.js reads ~/.openclaw/workspace/.env (claimed to filter keys), scripts/cloud-cron.js reads ~/.openclaw/workspace/skills/loveclaw/sessions.json and ~/.openclaw/agents/main/sessions/sessions.json to build routing tables, and scripts/cloud-handler.js contains functions to extract local media paths and calls cloud-data.uploadPhoto (which can accept base64), implying local files may be read and uploaded. The skill also instructs creating and parsing cron-run outputs and to forward message content exactly as returned by handlers. Those local reads and potential uploads are within notification/messaging scope but are safety-relevant and worth auditing.
ℹ
Install Mechanism
There is no automated installer in the registry metadata; SKILL.md tells operators to run npm install. Dependencies are standard npm packages (ali-oss, aliyun-sdk, firebase, tablestore, etc.). This is a normal installation pattern but it does require pulling many third-party packages from npm — review package-lock/package.json if you need supply-chain assurance.
ℹ
Credentials
The skill declares a single required secret: LOVECLAW_API_TOKEN (primaryEnv). Optional LOVECLAW_API_BASE and OPENCLAW_BIN are reasonable. The code also reads ~/.openclaw/workspace/.env via a helper that claims to whitelist keys; confirm that file contains only permitted keys and that the whitelisting logic is actually implemented in scripts/load-workspace-env.js (full contents were not shown).
!
Persistence & Privilege
The skill invokes the OpenClaw CLI (execFileSync openclaw ...) to add/remove cron jobs and will attempt to register a daily matching job and per-user evening-report cron entries. Creating scheduled tasks in the agent environment is a persistent side-effect and gives the skill ongoing ability to trigger actions. This behavior is explained in SKILL.md (cron templates) and matches the notification use case, but it is a higher-privilege action and should be approved explicitly by the operator.
What to consider before installing
What to check before you install
1) API token scope: Provide a minimal-scope LOVECLAW_API_TOKEN that only grants the cloud function endpoints the needed API surface (register/profile/report) — do not reuse broad cloud provider or admin credentials. Confirm where the token is provisioned and that the backend domain (default: https://loveclaw-cgbnqltfhd.cn-hangzhou.fcapp.run) is the expected service.
2) Inspect load-workspace-env.js: SKILL.md says it will only inject LOVECLAW_* and OPENCLAW_BIN (and standard proxy vars) from ~/.openclaw/workspace/.env. Open that script and verify the allowlist is implemented correctly. If you cannot verify, keep unrelated secrets out of that workspace .env.
3) Review session files the skill reads: The skill reads ~/.openclaw/workspace/skills/loveclaw/sessions.json and ~/.openclaw/agents/main/sessions/sessions.json to build routing. Ensure those files do not contain secrets you wouldn’t want read by this skill, and consider placing LoveClaw in an isolated workspace if possible.
4) Cron/job creation: The skill will call the openclaw CLI to add scheduled jobs (daily match and per-user evening reports). If you are uncomfortable with automatic cron registration, do NOT allow the agent to run those setup steps automatically — create the cron jobs yourself after review or disable cron setup in the code.
5) Media handling / local file upload: The code includes logic to parse local media attachment paths and the cloud upload functions accept base64 data; audit the remainder of cloud-handler.js (full file truncated in the manifest) to confirm it only uploads expected user-submitted temporary files and does not read arbitrary local files.
6) Third-party packages: npm install will pull many dependencies (aliyun SDK, firebase, etc.). If supply-chain risk is a concern, review package-lock.json and consider auditing or pinning versions, or install in an isolated environment.
7) Test in an isolated workspace first: Run the skill in an isolated user/workspace with a throwaway LOVECLAW_API_TOKEN to observe exactly what files it reads, what cron changes it requests, and what it sends to the remote API.
What would change this assessment
- If full contents of load-workspace-env.js show no proper whitelisting, or if cloud-handler.js includes code that reads arbitrary files and uploads them to the remote API, I would raise the verdict to more strongly suspicious or malicious.
- If the agent sessions file parsing exposes tokens or sensitive data beyond routing metadata, or if the backend domain is unknown/untrusted, that would increase concern.
Bottom line: The skill is largely coherent with the stated purpose, but it performs several broad local operations (reading agent session files, creating cron jobs, handling local media and uploads). Those behaviors are explainable for a notification router, yet they are powerful and deserve operator review and limiting the API token scope and workspace contents before trusting the skill in production.