@codacy/verity-cli 0.34.3 → 0.35.0-experimental.ce90a7b

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

@@ -20,8 +20,8 @@ You are running an on-demand Verity analysis. This is like a "second opinion"
 
 ## Step 1: Check configuration
 
-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`"
+1. Verify `.verity/standard.yaml` exists. If not: "Run `/verity-init` (or `verity init` in a terminal) first."
+2. Verify `verity` CLI is available: `which verity`. If not: "Install it: `npm install -g @codacy/verity-cli`, or install the Verity Claude Code plugin."
 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

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

@@ -1,153 +1,125 @@
 ---
 description: >-
-  Set Verity up in this project: ask the setup questions in the session, run the
-  deterministic install with those answers, sign in, and repair a project the Claude
-  Code plugin has just been added to. Use right after installing the Verity plugin,
-  or when Verity says this project is not set up.
+  Set Verity up in this project: ask the setup questions in the session (sign in,
+  and the Standard: use the team's, or write project rules from a repo profile),
+  sign in, and run the install with those answers. Use right after installing the Verity plugin, or when
+  Verity says this project is not set up.
 disable-model-invocation: true
 ---
 # /verity-init — set Verity up in this project
 
-You are running, inside this session, the same setup `verity init` runs at a
-terminal: the same questions, the same install, the same sign-in. The only
-difference is who asks. At a terminal the CLI prompts; here **you** ask, and pass
-the answers down as flags.
+You run, inside this session, the same setup that `verity init` runs at a
+terminal. At a terminal the CLI asks about sign-in and about the Standard. Here
+**you** ask, and pass the answers to the CLI as flags.
 
-**Why this skill exists.** Claude Code has no post-install hook and a plugin
-cannot invoke a skill, so installing Verity repairs nothing: it cannot remove a
-project's superseded skills, stand down duplicate hooks, or derive a Standard.
-All of that needs a command someone runs — this one.
+**Why this skill exists.** Claude Code has no post-install hook, and a plugin
+cannot start a skill. So installing Verity does not set up the project. That needs
+a command, and this skill runs it.
 
-**`verity init` prompts on a terminal, and you are not one.** Run with `--yes`
-alone it takes the unattended answer to every question: stop-only review (no
-commit or push gate), no telemetry, no sign-in, nothing untracked. Every one of
-those is a decision that belongs to the user, so every one is asked here.
+**`verity init --yes` asks nothing.** Without these flags it skips sign-in, uses
+the team's Standard if there is one, and sends no profile. These are the user's
+decisions, so ask them here.
 
-Run every `verity` command below the way this session's context says (the
-plugin's own copy), not with plain `verity`, whenever the context names one.
+When this session's context names the plugin's own copy of the CLI, run every
+`verity` command below with that copy, not with plain `verity`.
 
 ---
 
-## Step 0: Read where the project stands — before asking anything
+## Step 0: Read where the project stands
 
 ```bash
 verity doctor --json
 ```
 
-From that one report:
+Use this one report:
 
 - **`blocked` is true** → show the `prerequisites[].remedy` lines and stop.
-  Nothing below can work.
 - **`hooks.versions.skew` is set** → tell the user first, in one line, with
-  `hooks.versions.skew.remedy`. An older CLI cannot take the answers, so they
-  should hear it now, not after answering.
-- **`answers`** holds what a previous run recorded (`intensity`, `moments`,
-  `telemetry`). On a re-run those are the defaults — pre-select them. The shipped
-  defaults are only for a project with nothing recorded.
-- **`telemetry.enabled`** decides whether the telemetry question is asked at all.
-- **`memory.trackedFiles > 0` and `memory.optedOut` is false** → the graph
-  question applies.
-- **`trackedState.files > 0`** → the committed-state question applies.
+  `hooks.versions.skew.remedy`.
+- **`artifacts.standard` is true** → this project already has a Standard here.
+  Do not ask question 2. Init keeps the Standard and sends no profile.
 
-## Step 1: Ask — once, in one prompt
+When `artifacts.standard` is false, also run:
 
-Use `AskUserQuestion` with every question that applies **in a single call**, in
-this order. It takes at most four; if more apply, put the rest in ONE follow-up
-call. Do not ask one at a time, and do not ask in prose unless `AskUserQuestion`
-is unavailable (then ask in prose and **wait** — never choose for the user).
+```bash
+verity standard history
+```
 
-**1 — "When should Verity review your code?"** (multi-select, always asked)
+- **It lists versions** → the team already has a Standard on the service.
+  Question 2 is **2a**.
+- **It prints "No Standard versions found."** → question 2 is **2b**.
+- **It fails** (for example, not signed in) → question 2 is **2b** for now.
+  Step 2 checks again after sign-in.
+- **`memory.trackedFiles > 0` and `memory.optedOut` is false** → question 3 applies.
+- **`trackedState.files > 0`** → question 4 applies.
 
-| Option | Description |
-|---|---|
-| `After every turn (always on with the plugin, for now)` | Reviews what the agent just wrote, as you work. Fast feedback, never blocks a commit. Under the Claude Code plugin it cannot be turned off yet. |
-| `Before commit` | Reviews the staged diff and blocks the commit on a failing review. |
-| `Before push / PR` | Reviews the commits about to be pushed and blocks on a failing review. |
+## Step 1: Ask, once, in one prompt
 
-Pre-select the recorded moments, or **After every turn** on a first run, and do
-not call it "recommended": under the plugin it runs whatever the answer. Say
-plainly in the question text that choosing only the first means **git commits
-and pushes are not gated**.
+Use `AskUserQuestion` with every question that applies, **in one call**. Do not
+ask one at a time. If `AskUserQuestion` is not available, ask in prose and wait for
+the answer. Never choose for the user.
 
-**2 — "How deeply should Verity review?"** (single-select, always asked)
+**1 — "Sign in to Verity now?"** (always)
 
 | Option | Description |
 |---|---|
-| `Balanced (recommended)` | Security + quality, about 8s per review. |
-| `Lightweight` | Critical security only, about 3s. |
-| `Thorough` | All tools, all rules, about 15s. |
+| `Sign in now (recommended)` | One GitHub sign-in covers every repository on this machine, for 90 days. AI review needs it. If you are signed in already, this only confirms it. |
+| `Skip for now` | Only the local security scan runs. Nothing is saved. Sign in later with `/verity-init` or `verity login`. |
 
-**3 — "Send cost & usage telemetry to Verity?"** (single-select; **only when
-`telemetry.enabled` is false**)
+If the user asks: the GitHub token is used once to check which repositories they
+can write to, then discarded. Signing in does not give Verity access to the
+contents of their repositories.
+
+**2a — "Your team already has a Standard for this repository. Use it, or create a new one?"**
+(only when `verity standard history` lists versions; name the latest version and who pushed it)
 
 | Option | Description |
 |---|---|
-| `Yes, enable it` | Powers the /usage dashboard. Sends Claude Code's own OpenTelemetry metrics and traces: model names, token counts, cost, session ids. Not your prompts, code, or tool input/output. |
-| `No` | /usage stays empty. Enable later with `verity telemetry install`. |
+| `Use it (recommended)` | Reviews use the same rules as everyone else on the project. Nothing is sent. |
+| `Create a new one from a repo profile` | The new Standard becomes the next version for the whole team. Verity sends the repo profile that 2b describes, and writes project rules from it. |
+| `Create a new one with the built-in rules` | The new Standard becomes the next version for the whole team. It has the built-in rules only. Nothing is sent. |
 
-**4 — "Sign in to Verity now?"** (single-select, always asked)
+**2b — "Let Verity write review rules for this repository?"** (only when
+`artifacts.standard` is false and 2a does not apply)
 
 | Option | Description |
 |---|---|
-| `Sign in now (recommended)` | One GitHub login covers every repository you can write to, for 90 days. Needed for run history, cloud memory and the dashboard. If you are already signed in this just confirms it. |
-| `Skip for now` | The gate still reviews your code locally; nothing is saved. Sign in later with `/verity-init` or `verity login`. |
+| `Yes, send the profile (recommended)` | Verity sends a profile of this repository to the Verity service: languages, frameworks and dependency names; folder names, 3 levels deep; the subjects of recent commits and the paths each one changed; the agent docs (CLAUDE.md, AGENTS.md, and those of sub-projects) without their code blocks, or the rule sections of README.md when there are none. This step sends no source code, diffs or author names. Verity does not store the profile. Later, each review sends the code that changed. |
+| `No, use the built-in rules` | The Standard has the built-in rules only. Add project rules later with `verity standard generate`. |
 
-If asked, explain: the GitHub token is used once to check which repositories they
-can write to, then discarded; signing in does not give Verity access to their
-code, which is analyzed in memory and never stored.
+Say in the question text that the profile needs sign-in. If the user skips
+sign-in, question 2b has no effect.
 
-**5 — "Stop tracking Verity's knowledge graph in git?"** (only when the graph
-question applies; say how many files)
+**3 — "Stop tracking Verity's knowledge graph in git?"** (only when it applies;
+say how many files)
 
 | Option | Description |
 |---|---|
-| `Yes, untrack it (recommended)` | Files stay on disk; their removal from the index is staged for you to commit. Generated notes stop appearing in every diff and PR. |
+| `Yes, untrack it (recommended)` | The files stay on disk. Their removal from the index is staged for you to commit. Generated notes stop appearing in every diff. |
 | `No, not now` | Nothing changes. `verity memory track` records it as deliberate. |
 
-**6 — "Untrack committed Verity state?"** (only when `trackedState.files > 0`;
+**4 — "Untrack committed Verity state?"** (only when `trackedState.files > 0`;
 say how many files)
 
 | Option | Description |
 |---|---|
-| `Yes, untrack it (recommended)` | Machine-local files that should never have been committed — they can include copies of flagged secrets. Files stay on disk; the removal is staged. |
+| `Yes, untrack it (recommended)` | These files are machine-local and can include copies of flagged secrets. The files stay on disk, and the removal is staged. |
 | `No, not now` | Nothing changes. |
 
-## Step 2: Run the install with those answers
-
-One command, no prompts, nothing silently defaulted:
-
-```bash
-verity init --yes --no-setup \
-  --moments <stop[,pre-commit][,pre-push] | none> \
-  --intensity <balanced|lightweight|thorough> \
-  [--telemetry on|off] [--untrack-memory] [--untrack-state]
-```
-
-- Pass `--telemetry` only when question 3 was asked. Omitting it leaves the
-  recorded choice alone.
-- Pass `--untrack-memory` / `--untrack-state` only on a yes.
-- Pass `stop` only if they ticked it. Under the plugin the Stop review runs either
-  way and `verity init` says so.
-- An unrecognised value is refused rather than dropped, so a typo cannot quietly
-  remove a gate. If init exits non-zero, show its error and stop.
-
-This is idempotent and does the whole install: removes the project's own
-`.claude/skills/verity-*` copies that the plugin supersedes, stands down duplicate
-`.claude/settings.json` hooks, adopts the team's Standard from the service or
-derives one from the codebase, heals a stale analysis config, and records the
-plugin version — which is what stops Verity asking at every session start.
+Do not ask when Verity reviews. All three moments are on by default: each turn,
+each commit and each push. Step 4 tells the user how to change them.
 
-Init runs before sign-in, so on a first run it says it skipped authentication and
-that telemetry needs a token. That is expected — Step 3 handles both. Do not
-repeat those lines to the user as problems.
+## Step 2: Sign in first, in two halves
 
-## Step 3: Sign in — here, in two halves
+Skip this step if the user chose **Skip for now**.
 
-Skip this step if they chose **Skip for now**; say the gate runs locally and how
-to sign in later.
+⚠ **Sign in BEFORE the install.** Init needs the sign-in to use the team's
+Standard, to write project rules, and to share the Standard. Run the other way
+round, the Standard stays on this machine, and every review fails with
+`STANDARD_NOT_FOUND`.
 
-`verity login` on its own prints a code and then blocks until it is approved, and
-you would only see the code after it ended. So it is split:
+`verity login` waits until the code is approved, and you would see the code only
+after it ends. So use the two halves:
 
 ```bash
 verity login --start
@@ -155,79 +127,94 @@ verity login --start
 
 It prints one JSON object on stdout:
 
-- **`"status": "logged_in"`** → they already are. Say so and go to Step 4.
-- **`"status": "pending"`** → show the user `verification_uri` and `user_code`
-  exactly as given, and ask them to approve it in their browser and tell you when
-  they have. Wait for their reply. Do not run anything in the meantime.
-- **`"status": "failed"`** → show the error, and tell them to run `verity login`
-  in their own terminal later. Go to Step 4.
+- **`"status": "logged_in"`** → the user is signed in. Say so and go to Step 3.
+- **`"status": "pending"`** → show `verification_uri` and `user_code` exactly as
+  given. Ask the user to approve it in the browser and to tell you when they have.
+  Wait for the reply. Run nothing in the meantime.
+- **`"status": "failed"`** → show the error. Tell the user to run `verity login`
+  in a terminal later. Go to Step 3.
 
-When they say it is approved (or ask you to check):
+**After a new sign-in, check the Standard again.** If Step 0 could not run
+`verity standard history` (it failed) and `artifacts.standard` is false, run it
+now. If it lists versions, ask question 2a now, in its own prompt. Its answer
+replaces the answer to 2b.
+
+When the user says it is approved, or asks you to check:
 
 ```bash
 verity login --finish
 ```
 
-Give the tool call at least a 150-second timeout; it waits up to 100 seconds.
+Give this tool call a timeout of at least 150 seconds. It waits up to 100 seconds.
 
 - **exit 0, `"status": "logged_in"`** → report the lines it printed about the
-  account and whether this repository is covered, word for word where it names a
-  link to grant the Verity GitHub App.
+  account and this repository's coverage. Give any link to the Verity GitHub App
+  word for word. Then go to Step 3.
 - **exit 2, `"status": "pending"`** → not approved yet. Show the code again, wait
-  for them, and run `--finish` again.
+  for the user, and run `--finish` again.
 - **exit 1** → `denied`, `expired`, `service_changed`, `no_pending` or `failed`.
-  Show the error. For `expired` or `no_pending`, offer to start again with
-  `--start`.
+  Show the error. For `expired` or `no_pending`, offer to start again with `--start`.
 
-If they change their mind while a code is pending, run `verity login --cancel`.
+If the user changes their mind while a code is pending, run `verity login --cancel`.
 
-⚠ Never run plain `verity login` from here, and never tell a user whose Step 0
-reported a version skew to run it in a terminal until they have fixed the skew —
-the old global CLI can sign the machine in to a different server, and the plugin
-follows that sign-in.
+⚠ Never run plain `verity login` here. If Step 0 reported a version skew, do not
+tell the user to run it in a terminal until they fix the skew: the old global CLI
+can sign the machine in to a different server, and the plugin follows that sign-in.
 
-## Step 4: Finish telemetry, if it waited on sign-in
+## Step 3: Run the install with the answers
 
-If they said yes to telemetry and init reported it needs a token, and Step 3
-signed them in:
+One command. It asks nothing:
 
 ```bash
-verity telemetry install
+verity init --yes [--standard <use|new>] --profile <send|skip> [--untrack-memory] [--untrack-state]
 ```
 
-It takes effect on their next Claude Code session.
+- Question 2a: `Use it` → `--standard use`. `Create a new one from a repo
+  profile` → `--standard new --profile send`. `Create a new one with the
+  built-in rules` → `--standard new --profile skip`.
+- Question 2b: `--profile send` only when the user said yes and signed in.
+  Otherwise `--profile skip`.
+- When question 2 was not asked, leave `--standard` and `--profile` off.
+- `--untrack-memory` and `--untrack-state` only on a yes.
+- Do not pass `--moments` or `--telemetry`. Without them, init keeps the moments
+  the project has, or turns on all three for a new project.
+- If init exits non-zero, show its error and stop.
+
+Init is idempotent. It removes the project's own `.claude/skills/verity-*` copies
+that the plugin replaces, removes duplicate `.claude/settings.json` hooks, keeps
+or adopts or writes the Standard, and records the plugin version. That record
+stops Verity asking at every session start.
 
-## Step 5: Report what happened
+With `--profile send`, init prints the rules that Verity wrote. Each rule has an
+id, one sentence, where it applies and why. Show them to the user as printed.
+
+## Step 4: Report what happened
 
 ```bash
 verity doctor --json
 ```
 
-Summarise from this report, not from memory of what you ran:
-
-- what init removed (superseded skills, duplicate hooks) — those skill
-  directories are usually committed, so the deletions show in `git status` and
-  are the user's to commit;
-- whether the Standard was **adopted** from the service or **derived** from the
-  codebase (init's output says which);
-- the moments and intensity now in effect, and who wires the hooks
-  (`hooks.source`);
-- anything untracked, and that the staged removal is theirs to commit;
-- sign-in and telemetry state;
+Summarise from this report and from init's output, not from memory:
+
+- the Standard: **kept**, **adopted** from the team, **written** from the profile
+  (with its rules), or built from the catalogue. When it is a new one that
+  replaced the team's, say which version it replaced;
+- the moments in effect. Say: "Verity reviews every turn, every commit and every
+  push. To change it, run `verity config moments`, or just ask me.";
+- what init removed (superseded skills, duplicate hooks). Those skill folders are
+  usually committed, so the deletions show in `git status` and are the user's to
+  commit;
+- anything untracked, and that the staged removal is the user's to commit;
+- sign-in state;
 - each line of `next`, if any.
 
-Then offer `/verity-setup` for the part a lookup cannot produce — project-specific
-`custom_patterns` such as *"every route under `api/` uses the auth middleware"* —
-and say it is optional: the gate is already running.
-
 ---
 
 ## What NOT to do here
 
 - **Do not wire hooks or edit `.gitignore` yourself.** `verity init` owns that.
-  Doing it here is how the two flows drifted apart before.
-- **Do not synthesize a Standard by hand.** The CLI derives it in seconds from
-  the same catalogue you would be reading.
-- **Do not answer a question for the user**, including by leaving a flag off
-  because it seemed obvious. An omitted question is an unattended answer.
-- **Do not run plain `verity login`.** Step 3.
+- **Do not write a Standard by hand.** Init gets it from the team, from the
+  profile, or from the catalogue.
+- **Do not answer a question for the user**, and do not leave a flag off because
+  it seems obvious. An omitted answer is an unattended one.
+- **Do not run plain `verity login`.** See Step 2.