Meticulous CLI Update

Install or update the Meticulous CLI

The @alwaysmeticulous/cli package is under active development and ships frequent changes and improvements. Other Meticulous skills assume the meticulous command is on PATH and up to date, so run this skill once at the start of any Meticulous workflow.

This only needs to run once per conversation. If you've already run it earlier in this conversation, skip it — there's no need to re-check the version or re-update on every Meticulous skill invocation.

Using the MCP server instead of the CLI? Steps 1-4 are about installing/updating the meticulous CLI binary and its own local auth — neither applies when calling tools on the hosted Meticulous MCP server, which is already on the latest version and authenticates via the MCP connection itself, not meticulous auth login. Skip straight to Step 5: the installed skills (this document set) are a separate thing from the CLI/MCP tool itself and still need to stay current either way, regardless of which one you're calling tools through.

Full setup instructions — installing the CLI, connecting the MCP server, and installing these skills — live at app.meticulous.ai/docs/agents/setup.

How to handle the install/update commands

This skill normally runs as a sub-step of another Meticulous skill. The install/update commands below (Steps 1, 3, and 5) are security-sensitive — they install packages and reach the network — so treat them as best-effort and non-blocking:

• You generally can't tell in advance whether a command is whitelisted. If it's whitelisted it runs silently; if not, attempting it surfaces a permission prompt. Either outcome is fine — let that be how you find out.
• If a command needs permission you don't have (a prompt appears, or the user declines it), treat that as the signal to recommend rather than force. Tell the user it's recommended to do XYZ — e.g. "It's recommended to update the Meticulous CLI by running npm install --global @alwaysmeticulous/cli@latest" — and move on. A declined prompt is not a failure; it just means "do it later."
• If the user doesn't want to run it now, continue anyway. Do not stop the workflow; carry on with the remaining steps and then return to the calling skill. The only hard requirement is that the meticulous command exists at all (Step 1) — if it's genuinely not installed and the user declines to install it, no Meticulous skill can proceed, so stop there.

The read-only checks (meticulous --version, npm view …, meticulous auth whoami) are safe to run directly.

Step 1 — Check the installed version

meticulous --version

If the command is not found, the CLI is not installed. Install it globally (best-effort, see the note above):

npm install --global @alwaysmeticulous/cli@latest

If installing isn't whitelisted, recommend the user run that command themselves. Because no Meticulous skill can run without the CLI, this is the one case where you should stop and wait if the user declines — there's nothing to continue with. Once installed, re-run meticulous --version to confirm it's on PATH, and skip to Step 4.

Step 2 — Check the latest published version

npm view @alwaysmeticulous/cli version

Step 3 — Update the CLI if outdated

If the installed version already matches the latest, skip to Step 4.

Otherwise, update according to how the CLI is installed (best-effort, see the note above — if updating isn't whitelisted, recommend the user run the appropriate command and continue regardless):

• Globally installed (typical — which meticulous resolves to a path outside the current project):

  npm install --global @alwaysmeticulous/cli@latest

• Locally installed in the project (@alwaysmeticulous/cli appears in the project's package.json and which meticulous resolves inside node_modules/.bin):

  npm install --save-dev @alwaysmeticulous/cli@latest
  # or, if the project uses pnpm:
  pnpm add --save-dev @alwaysmeticulous/cli@latest
  # or yarn:
  yarn add --dev @alwaysmeticulous/cli@latest

If the update ran, re-run meticulous --version and confirm it matches the latest before proceeding.

Step 4 — Check authentication and project selection

Verify the user is authenticated with Meticulous and has a project selected:

meticulous auth whoami

Add --json if you'd rather branch on structured output — it prints authenticatedVia and selectedProject.

There are four outcomes:

(a) Signed in via OAuth, with a project selected

Authenticated via: OAuth
Logged in as: Jane Smith (jane@example.com)
Organizations: acme-corp (member)
Selected project: acme-corp/Web App

Nothing to do — continue to Step 5.

(b) Authenticated by an API token or injected credentials

Authenticated via: project API token (METICULOUS_API_TOKEN environment variable)
Pinned project: acme-corp/Web App

Also seen as project API token (~/.meticulous/config.json), test-run API token, or credentials injected at request time (agent platforms that attach a bearer credential to outbound requests to app.meticulous.ai). These credentials are scoped to a single project, which is already pinned, so there is nothing to select — do not run meticulous auth set-project: with an API token it errors out (the token is bound to one project), and with injected credentials there is likewise nothing to choose. Continue to Step 5.