
wix-cli-app-validation
Use when testing app readiness, verifying runtime behavior, or validating before releases and after changes in the code. Triggers include validate, test, verify, check readiness, preview validation, build verification, TypeScript compilation.
- Installs
- 287
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/wix/skills --skill wix-cli-app-validation- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads wix-cli-app-validation automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Wix App Validation
Validates Wix CLI applications through a four-step sequential workflow: package installation, TypeScript compilation check, build, and preview.
Validation Workflow
Execute these steps sequentially. Stop and report errors if any step fails.
Step 1: Package Installation
Ensure all dependencies are installed before proceeding with the build.
Detect package manager:
- Check for
package-lock.json→ usenpm - Check for
yarn.lock→ useyarn - Check for
pnpm-lock.yaml→ usepnpm - Default to
npmif no lock file is found
Run installation command:
# For npm
npm install
# For yarn
yarn install
# For pnpm
pnpm install
Success criteria:
- Exit code 0
- All dependencies installed successfully
- No missing peer dependencies warnings (unless expected)
node_modulesdirectory exists and contains expected packages
On failure: Report the installation errors, check the debug log for detailed diagnostics, and stop validation. Common issues:
- Network connectivity problems
- Corrupted lock files
- Version conflicts
- Missing Node.js or package manager
Step 2: TypeScript Compilation Check
Run TypeScript compiler to check for type errors.
Full project check:
npx tsc --noEmit
Targeted check (specific files/directories):
When validating after implementing a specific extension, you can run TypeScript checks on just those files:
# Check specific directory
npx tsc --noEmit src/extensions/dashboard/pages/survey/**/*.ts src/extensions/dashboard/pages/survey/**/*.tsx
# Check dashboard pages only
npx tsc --noEmit src/extensions/dashboard/pages/**/*.ts src/extensions/dashboard/pages/**/*.tsx
# Check site widgets only
npx tsc --noEmit src/extensions/site/widgets/**/*.ts src/extensions/site/widgets/**/*.tsx
# Check dashboard modals only
npx tsc --noEmit src/extensions/dashboard/modals/**/*.ts src/extensions/dashboard/modals/**/*.tsx
# Check backend only
npx tsc --noEmit src/extensions/backend/**/*.ts
When to use targeted checks:
- After implementing a single extension (faster feedback)
- When debugging type errors in a specific area
- During iterative development
When to use full project check:
- Before final validation
- When changes affect shared types
- Before building/deploying
Success criteria:
- Exit code 0
- No TypeScript compilation errors
- All type checks pass
On failure: Report the specific TypeScript errors and stop validation. Common issues:
- Type mismatches between expected and actual types
- Missing type declarations for imported modules
- Incorrect generic type parameters
- Properties not existing on declared types
- Incompatible function signatures
Step 3: Build Validation
Run the build command and check for compilation errors:
npx wix build
Success criteria:
- Exit code 0
- No TypeScript errors
- No missing dependencies
On failure: Report the specific compilation errors, check the debug log for detailed diagnostics, and stop validation.
Step 4: Preview Deployment
Start the preview server:
npx wix preview
Success criteria:
- Preview server starts successfully
- Preview URLs are generated (both site and dashboard)
URL extraction: Parse the terminal output to find both preview URLs. Look for patterns like:
- Site preview:
Site preview: https://...orSite URL: https://... - Dashboard preview:
Dashboard preview: https://...orPreview URL: https://...orYour app is available at: https://...
Extract both URLs and provide them to the user for manual verification.
On failure: Report the preview startup errors, check the debug log for detailed diagnostics, and stop validation.
Validation Report
After completing all steps, provide a summary:
Pass:
- Dependencies: ✓ All packages installed successfully
- TypeScript: ✓ No compilation errors
- Build: ✓ Compiled successfully
- Preview: ✓ Running at [URL]
Fail:
- Identify which step failed
- Provide specific error messages
- Suggest remediation steps
Debug Log on Errors
When a validation step fails (non-zero exit code, error output, or the CLI crashes/hangs), check .wix/debug.log in the project root for the full error trace. Only read this file when errors occur — skip it when steps pass or when the terminal output already makes the error clear (e.g. a straightforward TypeScript type error).
The .wix/ directory is automatically created by the Wix CLI and contains internal configuration and log files. Don't edit it, but reading debug.log for troubleshooting is expected.
Read: .wix/debug.log
# If the file is large, read the last 100 lines for the most recent errors
Read: .wix/debug.log (with offset to the end)
Common Issues
| Issue | Cause | Solution |
|---|---|---|
| Package installation fails | Missing lock file, network issues, or corrupted node_modules | Delete node_modules and lock file, then reinstall |
| TypeScript compilation fails | Type mismatches, missing declarations, or incorrect types | Fix TypeScript errors shown in npx tsc --noEmit output |
| Build fails | TypeScript errors, missing dependencies, or internal CLI error | Fix TypeScript errors in source; for non-obvious failures, check .wix/debug.log |
| Preview fails to start | Port conflict, config issue, or internal CLI error | Check wix.config.json; if unclear, check .wix/debug.log for details |
| Console errors in preview | Runtime exceptions | Check browser console output |
| UI not rendering | Component errors | Review component code and imports |
| CLI error with no clear message | Truncated terminal output | Read .wix/debug.log for the full error trace and stack details |
| Mysterious failures after config change | Stale CLI state | Read .wix/debug.log to confirm, then delete .wix/ and rebuild |
FAQ
What does the wix-cli-app-validation skill do?
Use when testing app readiness, verifying runtime behavior, or validating before releases and after changes in the code. Triggers include validate, test, verify, check readiness, preview validation, build verification, TypeScript compilation.
How do I install wix-cli-app-validation?
Run npx skills add https://github.com/wix/skills --skill wix-cli-app-validation in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/wix-cli-app-validation/ (personal) or .claude/skills/wix-cli-app-validation/ (project).
Which AI agents can use wix-cli-app-validation?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is wix-cli-app-validation safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains wix-cli-app-validation?
It is published by wix in wix/skills, and it is an official skill from the maker of the technology it covers. It has 287 recorded installs.
More from wix/skills
wix-docs
wix/skills
Look up the Wix API/SDK documentation to confirm an exact endpoint, HTTP method, request/response shape, field, enum, or error before writing Wix code — never guess a Wix API from memory. A lookup is a short flow: find the right page, then read it. Two ways: (1) plain curl (zero dependencies) — find a page by semantic search (POST /mcp-docs-search/v1/docs/search, natural-language { searchterm, documenttype(s) }, incl. the SKILLS recipe corpus for multi-step workflows) or by browsing a docs portal as a menu — a structured, typed, counted browse of the REST, SDK, CLI, Build Apps, and Headless portals (POST /mcp-docs-search/v1/docs/menu/browse), or the .md menu tree from the llms.txt root for any surface — then read the page by appending .md to its URL; (2) the Wix MCP doc tools when present. Triggers: look up a Wix API, find the Wix endpoint/method, confirm a Wix request body or field, verify a Wix API shape, explore Wix docs, which Wix API do I call, read a Wix m
wix-manage
wix/skills
REST recipes to configure and manage a Wix site's business solutions — stores, bookings, donations, payments, CMS, and more. Open the matching recipe for the exact endpoint, method, and payload before calling — never guess a Wix API, never write Wix dashboard URL from memory. Routes to: automations, stores, bookings, donations, get-paid, CMS, contacts, forms, media, app-installation, custom-apps, pricing-plans, restaurants, ricos rich-content, sites, collaborators, blog, calendar, domains, events, site-properties, ecommerce, marketing, google-ads, google-business-profile, analytics, accessibility, seo, dashboard-navigation.
wds-docs
wix/skills
Open the skill to read its SKILL.md instructions.
wix-cli-dashboard-modal
wix/skills
Open the skill to read its SKILL.md instructions.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work