@codacy/verity-cli 0.25.0 → 0.26.0-experimental.d7dfc00

package/data/skills/verity-analyze/SKILL.md

@@ -15,7 +15,13 @@ You are running an on-demand Verity analysis. This is like a "second opinion"
 
 1. Verify `.verity/standard.yaml` exists. If not: "Run `/verity-setup` first."
 2. Verify `verity` CLI is available: `which verity`. If not: "Re-run the Verity installer: `curl -fsSL https://raw.githubusercontent.com/codacy/verity/main/install.sh | bash`"
-3. Run `verity auth verify` to check token is valid. If it fails: "Verity not configured. Run `/verity-setup` first."
+3. Run `verity auth verify` to check the token is valid.
+   - **Valid**: proceed with the full deep review.
+   - **Fails / not authenticated**: don't stop. Tell the user Verity is in
+     **local-only mode**, so the review will run static analysis and show findings
+     but won't perform the deep (LLM) review or upload anything. To unlock the deep
+     review they can authenticate with `verity init` (or `verity auth register`).
+     Continue — `verity review` degrades to a local static-only report on its own.
 
 ---
 

package/data/skills/verity-setup/SKILL.md

@@ -310,25 +310,60 @@ Expected: single-digit findings per file, not hundreds. If you see 50+ issues fr
 
 ---
 
-## Step 6: Register with Verity service
-
-Use the `verity` CLI to register. It handles credential storage and service URL automatically.
+## Step 6: Verify authentication
+
+Login now happens in `verity init` (an optional, skippable step), **not** here.
+This step only checks whether the user authenticated during init, and branches
+the rest of setup accordingly.
+
+**If the user asks what signing in does or why it matters, tell them:**
+- It confirms they have **write access to this repository** — the GitHub token is
+  used **once** to verify that, then discarded. Verity never stores it.
+- It does **not** give Verity access to their code. Code checked by the gate is
+  analyzed **in memory and discarded** — Verity never stores their code.
+- It is **required to store and access run history** for the repo (past results,
+  trends, and shareable reports).
+- Skipping keeps Verity fully **local-only**: the gate still runs and shows
+  findings, but nothing is uploaded.
 
 ```bash
-verity auth register --project "PROJECT_NAME" --remote "GIT_REMOTE_URL"
+verity auth verify
 ```
 
-This command:
-- **New project**: Registers, stores token + service URL in `.verity/credentials`, prints `project_id`. Continue.
-- **Already registered**: Automatically discovers the project, ensures `.verity/credentials` has the service URL. If a token already exists in credentials, it updates the file and succeeds. If no token exists, it asks you to paste one.
-- **Other errors**: Show the error and stop.
-
-After this step, `.verity/credentials` will contain both `token` and `service_url` — all subsequent `verity` commands will work.
+- **Token valid** (prints the project name): The user authenticated during
+  `verity init`. Continue to Step 7 — the Standard, config, and knowledge base
+  will upload.
+- **Not authenticated / no token**: The user skipped login in `verity init` (or
+  lacks write access). Verity runs in **local-only mode** — the gate still runs on
+  every stop and surfaces static findings, but nothing uploads and no
+  history/org/repo data is stored. **Skip Steps 7 and 7b** (they require a token)
+  and continue to Step 8. Tell the user they can authenticate anytime to unlock
+  deep review, history, and shareable reports by running:
+
+  ```bash
+  verity init          # re-runs init; offers the auth prompt again
+  # or, directly:
+  verity auth register --project "PROJECT_NAME" --remote "GIT_REMOTE_URL"
+  ```
+
+  Registration is **provider-gated** (GitHub today): the CLI runs a GitHub OAuth
+  **device flow** ("open https://github.com/login/device and enter code
+  WXYZ-1234"), proving the user has **write access** to the repo before the
+  service issues a token.
+
+When authenticated, `.verity/credentials` contains `token`, `service_url`, and
+`provider_token` — all subsequent `verity` upload commands work.
 
 ---
 
 ## Step 7: Upload Standard and config
 
+> **Skip this entire step if the user is not authenticated** (Step 6 reported
+> local-only mode). These commands require a token and will fail without one. The
+> `.verity/standard.yaml` and `.codacy/codacy.config.json` you generated locally
+> still drive the gate; they'll upload the next time the user authenticates and
+> re-runs setup.
+
 ### Upload the Standard
 
 The `verity` CLI handles YAML→JSON conversion automatically:
@@ -359,6 +394,10 @@ This derives a small set of descriptive memory nodes from what you already analy
 
 ## Step 7b: Enable telemetry (only if the user opted in at Step 3b)
 
+> **Skip this step if the user is not authenticated** (local-only mode) — telemetry
+> export requires the token. Note that `/usage` stays empty until they authenticate
+> and run `verity telemetry install`.
+
 If — and only if — the user said **Yes** in Step 3b, enable the Claude Code telemetry export
 now (the token from Step 6 must already exist):
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codacy/verity-cli",
-  "version": "0.25.0",
+  "version": "0.26.0-experimental.d7dfc00",
   "description": "CLI for Verity quality gate service",
   "homepage": "https://verity.md",
   "repository": {