Skip to content
/patternsdocs
Reference

Trust and security

Treat installed guidance as executable influence, verify its source, and pin what your agent follows.

A pattern is prose and metadata, but it changes how a coding agent makes decisions. Treat it with the same care as other development tooling.

Before installing

  • Read the manifest and README at the exact tag or commit.
  • Prefer a verified publisher and a repository you recognize.
  • Inspect rules and recipes for instructions outside the claimed architecture scope.
  • Pin a tag or commit for repeatable installs.
  • Review changes before updating an installed bundle.

What the CLI protects

  • Manifest name must be a safe single path segment.
  • Materialization is constrained to .patterns/<name>.
  • Git refs beginning with option-like values are rejected before reaching Git.
  • The CLI records the resolved commit and source in a local origin sidecar.
  • Unpinned installs prompt for confirmation on an interactive terminal and warn in non-interactive environments.
  • Updates validate the new bundle and refuse an identity change.

What publishing protects

  • A publisher proves push access to the referenced GitHub repository.
  • The server fetches the manifest itself at a resolved commit.
  • Public indexing is rate-limited and validates length caps on untrusted fields.
  • A stable pattern name is first-claim reserved to its original verified owner.

No automated check proves that architectural advice is correct for your system. Source review and engineering judgment remain required.

On this page