Verglos on the CLI, with coding agents, and in CI

The useful Verglos workflow starts with one real surface: a local scan of a JavaScript or TypeScript project.

npx verglos scan

Check the repository and npm package for current flags, supported environments, and output behavior. Because 2.0.0-alpha.1 is an alpha, pin the version before relying on it in a repeatable pipeline.

With a coding agent

Verglos does not currently claim a shipped MCP server or named integrations for coding agents. An agent can still invoke the same CLI command if its environment permits shell execution, then present the report for human review.

Keep that use bounded: require approval before installing dependencies or changing files, do not expose production secrets to the agent, and do not let an agent reinterpret “no finding” as “secure.” The scanner output remains one source of evidence, not authority to deploy.

In continuous integration

A team can evaluate the CLI in CI by installing a pinned version, running the documented scan command, and retaining its artifacts. Before making the job blocking, verify the package's actual exit-code behavior and decide which policy belongs in the CI wrapper.

Do not describe that wrapper as a built-in Verglos CI product unless the public package exposes and documents one. The distinction matters when a failing scan can stop a release.

A practical adoption sequence

Start manually on a representative repository. Review false positives and unsupported project shapes. Pin the tool version. Store the report with the build or review record. Only then introduce a policy gate with a documented override and owner.

The same sequence applies to agent use: first learn what the scanner actually reports, then automate the boring invocation, and keep security decisions visible to a person.