Sitevision Claude Skills

Claude Code skills for working on Sitevision WebApp addons — the domain knowledge needed to build them correctly, plus the two deploy pipelines we actually run day to day.

Built and used at Getonnet.

What's in here

Skill	Trigger	What it does
sitevision-webapp-builder	Automatic	Domain knowledge for building, modifying, and reviewing WebApp/Widget modules: the @sitevision/api server/client/common split, appData vs globalAppData, routing, manifest.json fields, storage, styling with Envision tokens, TypeScript setup. Loads on its own whenever you're in a Sitevision module.
sv-update-dev	/sv-update-dev [addon] [bump]	Commits local changes, optionally bumps the version, then runs npm run dev and watches stdout until the upload lands. Retries recoverable build errors up to 3 times.
sv-deploy	/sv-deploy [addon]	Full production pipeline: patch-bump manifest.json → commit → build → sign via developer.sitevision.se → upload with --activate → verify the addon is actually live.

sv-deploy exists because sitevision-scripts deploy-prod always exits 0, even on a 401/403/500 upload. Trusting the exit code silently ships nothing. The skill scans stdout for the success markers and then does a REST GET /properties round-trip against the deployed addon ID to prove it's live.

Install

Option A — as a plugin (recommended)

/plugin marketplace add Getonnet/sitevision-claude-skills
/plugin install sitevision-skills@sitevision-claude-skills

Updates then come with /plugin marketplace update sitevision-claude-skills.

Option B — copy into your personal skills directory

git clone https://github.com/Getonnet/sitevision-claude-skills.git
cp -R sitevision-claude-skills/skills/* ~/.claude/skills/

Both work. The sv-deploy helper scripts resolve their own location via ${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}/skills/sv-deploy, so they find load-env.sh, bump.js, and sign.js under either layout.

Setup for the deploy skills

sitevision-webapp-builder needs no configuration. The two deploy skills need credentials.

1. .dev_properties.json (per addon)

Generated by Sitevision's own tooling — run this inside the addon directory:

npm run setup-dev-properties

It's interactive and prompts for domain, site name, addon name, and username.

2. .sv_ai_deploy.json (per repo, gitignored)

Holds signing credentials and production overrides. sv-deploy finds it by walking up from the addon directory — the addon itself, then up to 3 parent levels — so a single file at the repo root covers every addon, and a monorepo can keep one per region.

{
  "sign": {
    "username": "your-sitevision-developer-account",
    "password": "…",
    "certificateName": ""
  },
  "prod": {
    "domain": "use-foo.sitevision-cloud.no",
    "password": "…",
    "username": "optional — prod login if it differs from dev",
    "siteName": "optional — prod site name if it differs from dev",
    "addonName": "optional — prod addon name if it differs from dev"
  }
}

The prod.* identity fields are optional and fall back to .dev_properties.json. Set them when production uses a different account than dev — that mismatch is the most common cause of a 401 on upload.

Use the canonical host in prod.domain. A hostname that 301-redirects (e.g. www. → apex) will drop Basic auth and the deploy fails with a confusing 401.

In a monorepo, pass the addon as a path relative to the git root (/sv-deploy norway/megamenu-v2), not just the leaf directory name.

Security

Both credential files hold plaintext passwords. Gitignore them before your first commit:

.sv_ai_deploy.json
.dev_properties.json

sv-deploy verifies .sv_ai_deploy.json is ignored before it will sign anything, and sv-update-dev refuses to stage files matching .env, *.pem, *credential*, or .sv_ai_deploy.json that aren't already ignored. Neither skill echoes a password — confirmation prompts show username / ****.

Nothing in this repo contains credentials. Every hostname and password in the docs is a placeholder.

Notes

• sv-deploy never pushes. It commits the version bump locally and leaves the push to you.
• Production deploys always ask for explicit confirmation first — they're irreversible from the skill.
• The pipeline stops at the first failure and reports it. A failed build or sign never proceeds to upload.

License

MIT — see LICENSE.