dcc-mcp-3dsmax: Skill for Claude Code

VX Best Practices

Golden rule: Always prefix tool commands with vx in vx-managed projects. Use vx.toml for project-level tool versions, commit vx.lock for reproducibility, prefer templates over custom code when creating providers, and prefer structured or compact output before reading large logs.

General Principles

1. Always Use vx Prefix

In vx-managed projects, always prefix tool commands with vx:

# ✅ Correct
vx npm install
vx cargo build
vx just test

# ❌ Wrong (might use system tools)
npm install
cargo build
just test

2. Prefer Project-Level Configuration

Use vx.toml to ensure consistency across team members:

# ✅ Correct - defined in vx.toml
vx sync

# ❌ Wrong - manual installation
vx install node@22

3. Commit Lock Files

Always commit vx.lock to ensure reproducible builds:

vx git add vx.lock
vx git commit -m "chore: update dependencies"

4. Keep Agent Work Small and Observable

When an AI agent uses vx, optimize for correctness, speed, judgment, and token efficiency:

• Read enough surrounding code to understand the local pattern, then stop exploring.
• Prefer targeted searches, focused file sections, scoped diffs, selected JSON fields, and capped logs.
• Make the smallest maintainable change that solves the request.
• Reuse existing project helpers before creating new abstractions.
• Avoid single-use wrappers, speculative architecture, and unrelated cleanup.
• Validate according to risk: focused tests for narrow changes, broader checks for shared behavior.
• Preserve evidence from the actual command, CI job, or runtime surface when debugging.

For large or unknown output, scope first and filter through vx-managed tools:

vx rg -n -m 20 "SearchTerm" src
vx git diff --stat
vx git diff --name-only origin/main...HEAD
vx gh pr view 123 --json title,state,files
vx gh run view 456 --json status,conclusion,jobs --jq '.jobs[] | {name,conclusion}'
vx gh run view 456 --log | vx rg -n -m 50 "error|failed|panic|Traceback|FAILED"
vx --compact gh run view 456 --log