/woz

name: woz
description: WOZCODE utilities. Subcommands — login, logout, status, settings, update, share, review (deep multi-persona code review), benchmark (WOZCODE vs vanilla comparison). Invoke as `/woz <subcommand>`, e.g. `/woz login` or `/woz review`.
argument-hint: login | logout | status | settings | update | share | review | benchmark
arguments: subcommand
allowed-tools: Bash(node *), Bash(printf *), Read

/woz — WOZCODE utilities

One skill, eight subcommands. The first word of the arguments selects the subcommand:

| Subcommand | Purpose | |---|---| | `login` | Authenticate with the Woz service (browser, API key, or token) | | `logout` | Clear stored credentials and log out | | `status` | Show authentication and subscription status | | `settings` | Show or update WOZCODE plugin settings | | `update` | Update the WOZCODE plugin to the latest version | | `share` | Print the referral share message | | `review` | Deep multi-persona code review of the current branch (requires KnowledgeBase access) | | `benchmark` | Side-by-side WOZCODE vs vanilla Claude Code comparison on the user's repo |

TRIGGER when: the user runs `/woz <subcommand>`, or says "log in to woz", "woz status", "woz settings", "configure woz", "toggle attribution", "update woz", "refer a friend", "deep review", "final check before pushing", "review my branch", "is this ready to ship", "compare woz", "how much does woz save", "benchmark woz", or similar.

If no subcommand is given, ask the user which one they want (list them briefly).

Only the frequent, low-risk subcommands are auto-approved (`allowed-tools` is just `Bash(node *), Read`). The rare, heavier paths run through a normal permission prompt on purpose — least privilege on the common account/auth paths: `update` will prompt for `claude`/`rm`, and `benchmark` for `git`/`Write`/`mkdir`/etc. Approve those when the user runs them.

login

Dispatch on the arguments after the subcommand:

• Any argument that starts with `woz_sk_` (regardless of surrounding flags) → API Key Login below.
• `--token <token>` → Token Login below.
• Otherwise → Browser Login.

Browser Login (Preferred)

Run the Woz authentication flow. This opens a browser for the user to log in:

node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.cjs login

If the command exits with code 0, login succeeded — confirm to the user.

API Key Login

Use this when the user provides a WozCode API key (a `woz_sk_…` value) — from `/woz login woz_sk_…`, from a CI setup question, or when they paste one after a browser-login failure.

The key is password-equivalent, and any command you build with it inline lands in your transcript — so when the user can set an env var, prefer `WOZCODE_API_KEY` (see below). For a direct login, NEVER pass the key as an argument to the login command (it would show in `ps` for that process) — pipe it on stdin:

printf %s '<api-key>' | node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.cjs login --api-key-stdin

Replace `<api-key>` with the actual key, single-quoted. Do not echo the key back to the user in your response.

On Windows `cmd`/PowerShell there is no `printf`, so don't pipe the key there — tell the user to set the `WOZCODE_API_KEY` environment variable instead (see the CI/headless note below).

On success the CLI prints `Authenticated as <email> (organization: <id>)` — confirm to the user. On `API key invalid or revoked`, tell the user to check the key on their WozCode token page (or with their org admin) — existing keys are shown by preview only, so a new one may need to be issued.

For CI or headless use, the user doesn't need this skill at all: setting the `WOZCODE_API_KEY` environment variable makes the plugin bootstrap and re-mint sessions automatically.

Token Login

Use this when:

• The user passed `--token <token>` as arguments to this skill
• The browser login above timed out or failed and the user provides a token

If the browser login failed: 1. The auth URL is visible in the output above 2. Tell the user to open that URL in their browser and complete the login 3. Ask the user to copy the token shown on the auth page after login

Once you have the token (from args or from the user), run:

node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.cjs login --token '<token>'

Replace `<token>` with the actual token.

Confirm success or relay any error to the user.

logout

Log out of Woz by clearing stored credentials:

node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.cjs logout

Confirm that the user has been logged out.

status

Check the current Woz authentication status:

node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.cjs status

Relay the output to the user. Do not call out or warn about the `Token expires` value — the token is refreshed automatically, so framing the expiry as something the user needs to act on is misleading.

settings

Manage WOZCODE plugin settings. The user-facing knobs (attribution, status line, spinner verbs, the live-reviewer toggles, …) live in `~/.claude/settings.json` under the `wozcode` key. Prefer the `--show` / `--set` helper below over hand-editing — it applies the right side effects.

Show current settings

node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/settings-helper.cjs --show

Display the JSON output as a readable table for the user.

Update a setting

node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/settings-helper.cjs --set <key> <value>

Where `<key>` is a setting name and `<value>` is `true` or `false` (or, for `sql`, a JSON policy object — see [The `sql` connection policy](#the-sql-connection-policy) below).

**Available settings:**

| Key | Default | Description | |-----|---------|-------------| | `attribution` |