Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/githits-com/githits-cli/githits-packagenpx skills add githits-com/githits-cli --skill githits-packagegit clone --depth 1 https://github.com/githits-com/githits-cliWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00073 | $0.01295 |
| Opus 5 | $0.00036 | $0.00647 |
| Sonnet 5 | $0.00015 | $0.00259 |
| Haiku 4.5 | $0.00007 | $0.00129 |
Grade A, and why
githits-package scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Use GitHits package intelligence before making dependency claims from memory.
CLI Invocation
- Run commands as
githits .... - If
githitsis not found, retry the same command asnpx -y githits@latest .... - Use
--jsonwhen comparing versions, counting vulnerabilities, or extracting fields. - Do not expose credentials. If auth is required interactively, run
githits login; usegithits login --no-browseronly when the user can complete the printed URL flow. In noninteractive eval/CI, do not start OAuth; report thatGITHITS_API_TOKENor prior login is required. - If a command returns
TERMS_ACCEPTANCE_REQUIRED, rungithits settings terms acceptor use the returned authenticated acceptance URL, then retry once.
Package Spec
- Most package commands use
<registry>:<name>[@<version>], for examplenpm:[email protected]orpypi:requests. pkg infoalways reports the latest published version and does not accept a version pin.pkg changelogaccepts<registry>:<name>or--repo-url <url>; do not pass<spec>@<version>to changelog. Use--to <version>instead.
Core Commands
githits pkg info npm:express
githits pkg info npm:express --verbose --json
githits pkg vulns npm:[email protected] --severity high
githits pkg vulns npm:lodash --scope all --include-withdrawn --json
githits pkg vulns npm:[email protected] --scope non_affecting
githits pkg deps npm:express
githits pkg deps npm:express --lifecycle all
githits pkg deps npm:express --depth 3 --json
githits pkg changelog npm:express --limit 3
githits pkg changelog npm:express --from 4.18.0 --to 4.19.0
githits pkg changelog --repo-url https://github.com/expressjs/express --limit 2 --no-body
githits pkg upgrade-review npm:[email protected] --to 4.4.3
githits pkg upgrade-review --package npm:[email protected] --package npm:[email protected] --json
Decision Flow
- 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 historical advisories that do not affect the inspected version: use
pkg vulns --scope non_affecting; use--scope allfor affected plus historical rows. - Need dependency footprint: start with
pkg deps; add--lifecycle allfor 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-reviewbecause 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. - Need release notes without a current-to-target comparison: use
pkg changelog; use--from/--tofor ranges and--no-bodyfor compact timelines.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 92 lines · 73 tokens per session scan A 00d76e938343
githits-package is a skill published in the GitHub repository githits-com/githits-cli (87 stars, last pushed 4d ago), licensed Apache-2.0. It adds 73 tokens to every session and 1,295 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
kayba-stage-3-metrics
Define metrics from Kayba insights, implement them as Python measurement code, run against traces, and iterate until the metrics are clean and meaningful. Trigger when the user says "run stage 3", "define metrics", "build metrics", "compute baselines", or when invoked by the kayba-pipeline orchestrator. Requires…
kayba-stage-5-action-plan
Triage each insight into discard/code-fix/prompt-fix and produce a prioritized action plan with specific recommendations. Trigger when the user says "run stage 5", "make action plan", "triage skills", or when invoked by the kayba-pipeline orchestrator. Requires eval outputs from stages 1-4.
kayba-stage-4-rubric
Organize computed metrics into a tiered evaluation rubric with leading, lagging, and quality indicators. Trigger when the user says "run stage 4", "build rubric", "tier metrics", or when invoked by the kayba-pipeline orchestrator. Requires eval/baselinemetrics.json and eval/computebaselines.py to exist.
kayba-stage-6-hitl
Human-In-The-Loop gate that presents the action plan with full context, collects an informed approval/modification/rejection decision, and records the outcome. Trigger when the user says "run stage 6", "HITL review", "approve action plan", or when invoked by the kayba-pipeline orchestrator. Requires eval/actionplan.md…
kayba-pipeline
End-to-end agent evaluation and improvement pipeline. Takes a traces folder and optional HITL flag, then orchestrates sub-agents through 7 stages — each stage is its own skill invoked by a dedicated sub-agent. Trigger when the user says "run the pipeline", "kayba pipeline", "evaluate and fix", "full eval", "analyze…
kayba-stage-2-domain-context
Gather domain context about the repository and agent — system prompt, tool definitions, domain docs, and behavior patterns from traces. Trigger when the user says "run stage 2", "gather context", "domain context", or when invoked by the kayba-pipeline orchestrator.