$npx -y skills add WithWoz/wozcode-plugin --skill wozWOZCODE 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.
| 1 | # /woz — WOZCODE utilities |
| 2 | |
| 3 | One skill, eight subcommands. The first word of the arguments selects the subcommand: |
| 4 | |
| 5 | | Subcommand | Purpose | |
| 6 | |---|---| |
| 7 | | `login` | Authenticate with the Woz service (browser, API key, or token) | |
| 8 | | `logout` | Clear stored credentials and log out | |
| 9 | | `status` | Show authentication and subscription status | |
| 10 | | `settings` | Show or update WOZCODE plugin settings | |
| 11 | | `update` | Update the WOZCODE plugin to the latest version | |
| 12 | | `share` | Print the referral share message | |
| 13 | | `review` | Deep multi-persona code review of the current branch (requires KnowledgeBase access) | |
| 14 | | `benchmark` | Side-by-side WOZCODE vs vanilla Claude Code comparison on the user's repo | |
| 15 | |
| 16 | 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. |
| 17 | |
| 18 | If no subcommand is given, ask the user which one they want (list them briefly). |
| 19 | |
| 20 | 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. |
| 21 | |
| 22 | ## login |
| 23 | |
| 24 | Dispatch on the arguments after the subcommand: |
| 25 | |
| 26 | - Any argument that starts with `woz_sk_` (regardless of surrounding flags) → API Key Login below. |
| 27 | - `--token <token>` → Token Login below. |
| 28 | - Otherwise → Browser Login. |
| 29 | |
| 30 | ### Browser Login (Preferred) |
| 31 | |
| 32 | Run the Woz authentication flow. This opens a browser for the user to log in: |
| 33 | |
| 34 | ```bash |
| 35 | node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.js login |
| 36 | ``` |
| 37 | |
| 38 | If the command exits with code 0, login succeeded — confirm to the user. |
| 39 | |
| 40 | ### API Key Login |
| 41 | |
| 42 | Use this when the user provides a WozCode API key (a `woz_sk_…` value) — from |
| 43 | `/woz login woz_sk_…`, from a CI setup question, or when they paste one after a |
| 44 | browser-login failure. |
| 45 | |
| 46 | The key is password-equivalent, and any command you build with it inline lands |
| 47 | in your transcript — so when the user can set an env var, prefer |
| 48 | `WOZCODE_API_KEY` (see below). For a direct login, NEVER pass the key as an |
| 49 | argument to the login command (it would show in `ps` for that process) — pipe |
| 50 | it on stdin: |
| 51 | |
| 52 | ```bash |
| 53 | printf %s '<api-key>' | node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.js login --api-key-stdin |
| 54 | ``` |
| 55 | |
| 56 | Replace `<api-key>` with the actual key, single-quoted. Do not echo the key |
| 57 | back to the user in your response. |
| 58 | |
| 59 | On Windows `cmd`/PowerShell there is no `printf`, so don't pipe the key there — |
| 60 | tell the user to set the `WOZCODE_API_KEY` environment variable instead (see |
| 61 | the CI/headless note below). |
| 62 | |
| 63 | On success the CLI prints `Authenticated as <email> (organization: <id>)` — |
| 64 | confirm to the user. On `API key invalid or revoked`, tell the user to check |
| 65 | the key on their WozCode token page (or with their org admin) — existing keys |
| 66 | are shown by preview only, so a new one may need to be issued. |
| 67 | |
| 68 | For CI or headless use, the user doesn't need this skill at all: setting the |
| 69 | `WOZCODE_API_KEY` environment variable makes the plugin bootstrap and re-mint |
| 70 | sessions automatically. |
| 71 | |
| 72 | ### Token Login |
| 73 | |
| 74 | Use this when: |
| 75 | - The user passed `--token <token>` as arguments to this skill |
| 76 | - The browser login above timed out or failed and the user provides a token |
| 77 | |
| 78 | If the browser login failed: |
| 79 | 1. The auth URL is visible in the output above |
| 80 | 2. Tell the user to open that URL in their browser and complete the login |
| 81 | 3. Ask the user to copy the token shown on the auth page after login |
| 82 | |
| 83 | Once you have the token (from args or from the user), run: |
| 84 | |
| 85 | ```bash |
| 86 | node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.js login --token '<token>' |
| 87 | ``` |
| 88 | |
| 89 | Replace `<token>` with the actual token. |
| 90 | |
| 91 | Confirm success or relay any error to the user. |
| 92 | |
| 93 | ## logout |
| 94 | |
| 95 | Log out of Woz by clearing stored credentials: |
| 96 | |
| 97 | ```bash |
| 98 | node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.js logout |
| 99 | ``` |
| 100 | |
| 101 | Confirm that the user has been logged out. |
| 102 | |
| 103 | ## status |
| 104 | |
| 105 | Check the current Woz authentication status: |
| 106 | |
| 107 | ```bash |
| 108 | node --no-warnings=ExperimentalWarning ${CLAUDE_PLUGIN_ROOT}/scripts/wozcode-cli.js status |
| 109 | ``` |
| 110 | |
| 111 | Relay the output to the user. Do not call out or warn about the `Token expires` value — the token is refreshed automatically |