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 skills add alebgl77/claude-inc --skill vendor-checkgit clone --depth 1 https://github.com/alebgl77/claude-incWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/alebgl77/claude-inc/vendor-check)<a href="https://agentmods.dev/skills/alebgl77/claude-inc/vendor-check"><img src="https://agentmods.dev/badge/skills/alebgl77/claude-inc/vendor-check.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
What 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.1 | $0.00103 | $0.01146 |
| Opus 5 | $0.00051 | $0.00573 |
| Sonnet 5 | $0.00021 | $0.00229 |
| Haiku 4.5 | $0.00010 | $0.00115 |
Grade A, and why
vendor-check 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 8d 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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Vendor Check — Vendor Vetter
"Vet a vendor"
Answers one question fast: can we safely start (or keep) working with this vendor, and what paper is missing? Works from provided documents, pasted excerpts, or the user's answers.
When to use
- "Do we have paper with Acme?" — inventory before new spend
- "Can we onboard this vendor by Monday?" — the go/no-go call
- "What renews with them this quarter?" — expiration radar
- "We're dropping this vendor — what survives termination?" — offboarding read
- A found agreement with ugly clauses goes deeper via
review-contract
Workflow
- Profile the engagement: what the vendor does, what data or systems they touch, annual spend, business criticality, jurisdictions.
- Derive the "needed" list from that profile: MSA always; DPA whenever personal data flows; SOW per work package; SLA when availability matters; insurance certificates (types and minimums) proportional to risk; security review when they touch systems or data.
- Inventory what exists from attached files, pasted excerpts, and the user's answers: document, status (signed / draft / expired / missing), signature date, term.
- Build the gap analysis table: needed vs. exists vs. verdict — OK / EXPIRING / EXPIRED / MISSING / WRONG-SCOPE (e.g., an SOW hanging off a terminated MSA).
- Run the renewal radar: every date that matters — expirations, auto-renewal deadlines with their notice windows, insurance cert renewals — sorted soonest first, with days remaining from today.
- Note surviving obligations: whatever outlives termination or expiry (confidentiality, data return and deletion, audit rights, indemnities), each citing its source document and clause.
- Deliver the onboarding go/no-go checklist: blockers that must exist before access or PO, follow-ups allowed within 30 days, one owner per item, one verdict.
Output format
VENDOR CHECK — <vendor> — <date>
Engagement: <what they do> Touches: <data / systems> Criticality: <H / M / L>
INVENTORY vs. NEEDED
| Document | Needed? | Exists? | Date / term | Verdict |
|-----------------|---------|---------------|-----------------|---------|
| MSA | YES | signed <date> | <term, renewal> | OK |
| DPA | YES | missing | — | MISSING |
| SOW | YES | draft | — | GAP |
| SLA | <Y/N> | <status> | <dates> | <...> |
| Insurance certs | <Y/N> | <status> | <expiry> | <...> |
| Security review | <Y/N> | <status> | <date> | <...> |
RENEWAL / EXPIRATION RADAR (soonest first)
| Date | Event | Notice window | Days out | Action |
|--------|-------------------|-----------------|----------|---------------|
| <date> | <MSA auto-renews> | <60 days prior> | <n> | <decide by …> |
SURVIVING OBLIGATIONS
- <obligation> — source: <doc §n> — runs until <when>
ONBOARDING GO/NO-GO
[ ] BLOCKER: <must exist before access or PO> — owner: <who>
[ ] FOLLOW-UP: <within 30 days> — owner: <who>
VERDICT: <GO / GO WITH CONDITIONS / NO-GO> — <one line>
*Issue-spotting support, not legal advice — engage counsel for binding decisions.*
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.
- 8d ago First seen · 78 lines · 103 tokens per session scan A f4b1f947c060
vendor-check is a skill published in the GitHub repository alebgl77/claude-inc (14 stars, last pushed 6d ago), licensed MIT. It adds 103 tokens to every session and 1,146 once invoked, about $0.0005 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
simplify-code
Parallel 4-agent cleanup of recent code changes.
phx-review
Review changed Elixir/Phoenix code read-only. Check requirements, cite evidence, deduplicate findings, and return a severity-based verdict.
community-research-insight
Extract structured insight briefs from community research transcripts or notes. Produces pain points, stakeholder needs, opportunity maps, risks, and follow-up questions. Requires human review before publication.
phx-mix-compression
Reduce mix output noise (5-15% token savings) by installing rtk filters that compress mix test/credo/dialyzer/compile output before it reaches Claude. Use when long mix output floods context.
output-eval-error-analysis
Systematically review workflow traces to identify failure modes before building evaluators. Use when starting an eval project, after significant pipeline changes, or when production quality drops.
output-dev-code-style
Code style conventions for Output SDK workflow projects. Use when writing or reviewing any TypeScript/JavaScript code. Discovers the project's own linting rules first; falls back to Output SDK conventions when no linter is configured.