Vx Best Practices
v1.0.1Best practices for using vx effectively. Use when following recommended patterns for tool management, project setup, and team workflows with vx.
⭐ 0· 74·1 current·1 all-time
byHal@loonghao
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
The skill name and description match the SKILL.md content: guidance for vx usage, project setup, CI, and team workflows. There are no unrelated environment variables, binaries, or config paths requested that would be out of scope for a documentation-style skill.
Instruction Scope
The instructions are confined to vx-related workflows (vx.toml, vx.lock, vx commands, git, CI config). They do recommend using a GitHub Action (loonghao/vx@main) and run commands like git commit and vx install — appropriate for a how-to doc but these are operational commands users should review before executing. Minor supply-chain note: the example action references the 'main' branch of a third-party repo rather than a pinned release, which is a recommended hardening step.
Install Mechanism
There is no install specification and no code files — the skill is instruction-only and does not download or write code to disk.
Credentials
The SKILL.md mentions environment variables as examples (e.g., API_KEY, DATABASE_URL) but the skill does not request or require any credentials or secrets. No disproportionate or unrelated credential access is requested.
Persistence & Privilege
The skill is not marked always:true and does not request persistent presence or modify other skills or system-wide settings. Autonomous invocation is allowed (platform default) but not combined with other red flags.
Assessment
This skill is a documentation-only guide for vx and appears internally consistent. Before acting on any suggested commands: (1) review and understand commands like 'vx install', 'git commit', and 'vx setup' — don't run them blindly; (2) verify the third-party GitHub Action example (loonghao/vx@main) and prefer pinning to a specific release or commit to reduce supply-chain risk; (3) never paste real secrets into example files shown here — follow your usual secrets management practices; and (4) if you don't use vx in your projects, this skill is not needed. If you want a deeper check, provide the source of the referenced vx tooling or your repository so I can flag any risky commands or unpinned external dependencies.Like a lobster shell, security has layers — review code before you run it.
latestvk97bj7qpw5v80r8wep0xt8t435849w2e
License
MIT-0
Free to use, modify, and redistribute. No attribution required.