Githits Package

Use GitHits package intelligence before making dependency claims from memory.

CLI Invocation

• Run commands as githits ....
• If githits is not found, retry the same command as npx -y githits@latest ....
• Keep default text for model-read summaries, comparisons, and counts. Use --json only when code consumes the raw response or text omits a required field.
• Do not expose credentials. If auth is required interactively, run githits login; use githits login --no-browser only when the user can complete the printed URL flow. In noninteractive eval/CI, do not start OAuth; report that GITHITS_API_TOKEN or prior login is required.
• If a command returns TERMS_ACCEPTANCE_REQUIRED, run githits settings terms accept or use the returned authenticated acceptance URL, then retry once.

Package Spec

• Most package commands use <registry>:<name>[@<version>], for example npm:lodash@4.17.20 or pypi:requests.
• pkg info always reports the latest published version and does not accept a version pin.
• pkg changelog is package-only. Pin @version for one release; use @from..to or --from/--to for ranges. Repository and site targets are rejected.

Core Commands

githits pkg info npm:express
githits pkg info npm:express --verbose

githits pkg vulns npm:lodash@4.17.20 --severity high
githits pkg vulns npm:lodash --scope all --include-withdrawn
githits pkg vulns npm:lodash@4.17.21 --scope non_affecting
githits pkg vulns npm:express@4.17.1 --transitive --scope all

githits pkg deps npm:express
githits pkg deps npm:express --lifecycle all
githits pkg deps npm:express --depth 3

githits pkg changelog npm:express --limit 3
githits pkg changelog npm:express@5.2.1
githits pkg changelog npm:express --from 4.18.0 --to 4.19.0

githits pkg upgrade-review npm:zod@4.3.6 --to 4.4.3
githits pkg upgrade-review --package npm:zod@4.3.6..4.4.3 --package npm:lint-staged@16.2.7..16.4.0

Decision Flow

• Need a canonical target for an OSS dependency name: use githits resolve "<name>"; skip resolution for known canonical targets. Reuse only an unambiguous EXACT/HIGH best with CLEAR or NOT_APPLICABLE malicious-content status. Other or missing statuses are non-actionable; narrow or explicitly choose an actionable candidate for MEDIUM/LOW or ambiguity. Never auto-select, and do not treat CLEAR as vulnerability-free. A selected site: is docs-only.
• Need current package health: start with githits pkg info <registry:name>.
• Need security status for a specific installed version: use githits pkg vulns <registry:name@version>.
• Need vulnerabilities in resolved dependency versions: add pkg vulns --transitive; this opt-in adds graph-analysis cost and audits the resolved graph, not a local application lockfile.
• Need historical advisories that do not affect the inspected version: use pkg vulns --scope non_affecting; use --scope all for affected plus historical rows.
• Need dependency footprint: start with pkg deps; add --lifecycle all for non-runtime groups and --depth <n> for aggregate transitive graph data.
• Need upgrade evidence for dependency updates, outdated package bumps, or lockfile changes: prefer pkg upgrade-review because it compares current vs target vulnerabilities, changelog range evidence, deprecation metadata, peer changes, dependency changes, and transitive security evidence by default. It reports facts only; you still own the final assessment. Use signals as a starting point to evaluate the impact of changes on the codebase. You can use pkg changelog and code diff to obtain full release-note and source-change details.
• Need release notes without a current-to-target comparison: use pkg changelog; --no-body for compact timelines.
• Need exact source changes to supplement upgrade evidence, including missing or uninformative release notes: use the githits-code skill and githits code diff <registry:name> <current>..<target>. Diff is repository-wide even for package targets; report scope and content limits, and combine it with advisory evidence rather than inferring compatibility from the patch.