Skip to content

Trusting What You Install

A tool can contain prompts, Python, nested tools, and external MCP calls. Installing one is closer to installing a small program than copying a clever sentence. CmdForge makes the trust signals visible, but the decision remains yours.

Before You Install

cmdforge registry info official/forge-tool
cmdforge registry search "document classifier" --json --limit 5

Read the description, source attribution, version, deprecation state, quality score, coverage, and README. Treat popularity as discovery evidence, not security evidence.

Versions Are Immutable

A published version cannot be silently replaced. Updates require a new semantic version. Project lock files record resolved identities so another machine can verify it installed the same content:

cmdforge lock
cmdforge verify

Integrity and Attestation

Registry downloads carry content hashes and, where available, an Ed25519 attestation and publisher signing key. CmdForge verifies the full content identity and transitive dependency hashes. A valid signature answers “did this key sign these bytes?” It does not answer “is this behavior safe?”

Moderation Is a Gate, Not a Warranty

Public releases enter moderation. Scrutiny examines transparency, suspicious patterns, scope, and efficiency; a moderator may approve, reject, or request changes. Private and unlisted tools follow different visibility rules. Always inspect code steps and external access yourself.

Follow Deprecation Chains

A release can carry a deprecation message and replacement. Prefer the maintained replacement, then re-run preflight and your own behavioral tests. Deprecation is guidance; it never silently rewrites your project.

Publish in Two Stages

cmdforge registry publish ./my-tool --dry-run
cmdforge registry publish ./my-tool

The first stage is evidence gathering. The second is an immutable ecosystem event. That pause is where maintainers catch accidental secrets, stale metadata, missing contracts, and misleading claims.