Skill Dropshipping Fulfillment

v1.2.3

Automates order fulfillment by pushing WooCommerce orders to CJ Dropshipping. Fetches "Processing" orders, matches line items to CJ variants via a supplier s...

0· 293·1 current·1 all-time
byZero2Ai@zero2ai-hub
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
high confidence
!
Purpose & Capability
Name/description matches the code's functionality (fetch WooCommerce orders, map SKUs, call CJ API, update WooCommerce). However the registry metadata lists no required credentials/config paths while the code requires both WooCommerce and CJ credentials (read from JSON files) and will modify remote WooCommerce products in rebuild-mapping.js. Also the code's default file paths point at /home/aladdin/* which contradicts SKILL.md examples using relative paths — an incoherent default that could cause the skill to read/write unexpected user files.
!
Instruction Scope
SKILL.md describes fetching processing orders, mapping, submitting to CJ, updating WooCommerce and logging — which matches the scripts. But the scripts also: (a) read/write local JSON credential files, (b) update WooCommerce product SKUs (backfill) in rebuild-mapping.js, and (c) persist CJ access tokens back into cj-api.json. These are powerful write operations and the SKILL.md does not fully call out the default absolute paths (/home/aladdin/*) used by the code. The instructions also rely on several environment overrides (WOO_API_PATH, CJ_API_PATH, CJ_SELECTION_PATH, FULFILL_LOG_PATH, REJECTION_LOG_PATH, FBA_PRODUCT_IDS) that are not declared in registry metadata.
Install Mechanism
No install spec (instruction-only) and package.json only depends on axios. No external arbitrary download URLs or extract operations present. This is low-risk from an install mechanism perspective, but users must still inspect and run Node scripts.
!
Credentials
Registry metadata shows no required env vars or primary credential, but the code requires WooCommerce credentials and CJ API keys stored in local JSON files (woo-api.json, cj-api.json) and uses environment variables to override file paths and FBA_PRODUCT_IDS. The omission of these required credentials from metadata is a mismatch and raises risk: the skill will access local files for secrets (and will write CJ tokens back to disk).
Persistence & Privilege
always:false and the skill does not modify other skills or system configuration. It does persist data: writes logs (cj-fulfillment-log.json, cj-rejection-log.json), updates/creates cj-supplier-selection.json and updates cj-api.json with refreshed tokens, and rebuild-mapping.js can call WooCommerce PUT endpoints to backfill SKUs. Those are within its functional scope but are write-capable operations that merit caution.
What to consider before installing
This package implements the dropshipping workflow but has several red flags you should address before running it on real data: - Credentials and paths: The code expects WooCommerce and CJ credentials in local JSON files (woo-api.json, cj-api.json) but the registry metadata does not declare these. Confirm where you'll store credentials and put those files in a safe location. Prefer using environment-variable overrides to point paths to a controlled directory. - Default absolute paths: The runtime scripts default to /home/aladdin/*. That contradicts the SKILL.md examples and could cause the tool to read or overwrite files in an unrelated user's directory. Always set WOO_API_PATH, CJ_API_PATH, CJ_SELECTION_PATH, FULFILL_LOG_PATH, and REJECTION_LOG_PATH to safe paths before running. - Backfill behavior: rebuild-mapping.js can PUT updates to your WooCommerce store (backfilling SKUs). Run with --dry-run first and review the mapping output; only run live after verifying results. - Token persistence: The tool will refresh CJ access tokens and write them to cj-api.json. Ensure that file is secured (permissions) and located where you expect. - Test in isolation: Run the scripts in a disposable container or VM and use dry-run mode initially. Inspect the scripts line-by-line (they are small) or run them with network disabled to observe behavior. Consider creating throwaway API keys/accounts for initial tests. - If you need tighter security: require the vendor to declare required env vars/primary credential in metadata, remove hard-coded absolute defaults, and avoid writing tokens to predictable locations. Given the coherent functionality but the mismatches (undisclosed credential/file usage and risky defaults), treat this skill as suspicious and do not run it against production stores until you've corrected/configured paths and validated behavior in a safe environment.

Like a lobster shell, security has layers — review code before you run it.

latestvk977k8hbdq7jxnhk7338zkx4pn821hp6

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Runtime requirements

Binsnode

Comments