Borrowing it
Nothing to install: this file belongs to aveproject/ave. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/aveproject/ave/main/.claude/skills/add-ave-record/SKILL.mdgit clone --depth 1 https://github.com/aveproject/aveWrote 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/aveproject/ave/add-ave-record)<a href="https://agentmods.dev/skills/aveproject/ave/add-ave-record"><img src="https://agentmods.dev/badge/skills/aveproject/ave/add-ave-record/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/aveproject/ave/add-ave-record"><img src="https://agentmods.dev/badge/skills/aveproject/ave/add-ave-record.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 114 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00000 | $0.02505 |
| Opus 5.5 | $0.00000 | $0.01002 |
| Sonnet 5.5 | $0.00000 | $0.00501 |
| Haiku 4.5 | $0.00000 | $0.00250 |
Grade A, and why
add-ave-record 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 1mo 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 — 210 lines — stays where its author put it; the contents beside it link to each section on GitHub.
add-ave-record
The main workflow for this repo. Adds one new AVE record end to end.
Steps
1. Grill the vulnerability class first
Run grill-with-docs. Answer:
- What does a vulnerable component DO? (behavioral_fingerprint)
- What attack_class is this? (new or existing?)
- What is the worst-case impact? (drives AIVSS)
- Which engines can detect it? (evidence_basis_engines)
- Can a static scan see it, or does it need runtime? (detection_stage)
- Does it chain with other AVEs? (derivable_into)
2. Assign the next ave_id
Format AVE-YYYY-NNNNN. Never reuse a number. Check records/ for the highest.
3. Write the record JSON
records/AVE-YYYY-NNNNN.json. Must validate against the schema. Include the evidence fields:
- evidence_kind_default
- detection_stage
- detection_layer
- confidence_baseline
- evidence_basis_engines
- derivable_into
The researcher field, a common, real mistake, not a hypothetical
one: defaulting to the AVE maintainer's own name because it's the
name most readily at hand while drafting. Check first: does this
record trace to a real external CVE, paper, vendor disclosure, or
existing tool implementation? If yes, and it almost always is yes,
that source's own name or organization belongs in researcher, not
the person writing the AVE record. This exact mistake shipped on two
published records before being caught by an external maintainer being
credited incorrectly himself. See docs/specs/researcher-process.md's
Accountability and sourcing section for the full rule.
The four governance/framework fields — owasp_mcp, owasp_asi,
mitre_atlas, nist_ai_rmf — always include the key, never let one go
missing. These are the fields a CISO reads first; a security team
maps an AVE record onto their own reporting frameworks through these.
An absent key silently reads as "nobody checked this framework." An
empty array reads as "checked, no real fit was found." Only the second
one is an honest, defensible state.
owasp_mcp: required oncestatusisactive/deprecated(schema-enforced,minItems: 1) — needs at least one real mapping, verified against the OWASP MCP Top 10's own primary-source category text, not inferred from how a similar-sounding record in the corpus happened to tag itself.owasp_asi,mitre_atlas,nist_ai_rmf: not yet schema-required (that's a tracked v1.2.0 change, see the roadmap issue), but always write the key. Verify each against its own primary source (liveATLAS.yamlfor MITRE ATLAS, the actual NIST AI 100-1 text for NIST AI RMF, the framework's own published category list for OWASP ASI) before adding a value. Genuinely checked and found nothing that fits? Set it to[]and say so inaivss.notes— don't just leave the key out because the array would otherwise be empty. This exact mistake (a silently-missingowasp_asikey, not an empty one) shipped on AVE-2026-00078/00079/00080 and was caught reviewing that same PR — see docs/specs/researcher-process.md's Common Mistakes section.
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.
- 1mo ago First seen · 210 lines · 0 tokens per session scan A e4973cc9fdac
add-ave-record is a skill published in the GitHub repository aveproject/ave (24 stars, last pushed 2d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 2,505 tokens. 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
skill-inspector
Review AI agent skills before installation using NVIDIA SkillSpector and source-aware semantic review. Use when asked whether a skill or downloaded skill folder is safe, trustworthy, installable, over-permissioned, or malicious.
stock-report
Prepare a read-only availability report from an identified stock snapshot. Use when a task asks whether a stated quantity is available, without reserving or ordering stock.
crossval-harness
Orchestrate a static + dynamic, exploit-validated red-team of an AI agent — read the source to find candidate vulnerable paths, then run the dynamic skills to confirm or refute each one empirically. The arbiter of truth is whether the exploit works, not a model vote. Authorized testing of agents you own or are…
redteam-an-agent
The end-to-end methodology for red-teaming a specific AI agent — adaptively, exploit-validated, and honestly. Read THIS target's own code, stand up a disposable harness, and prove or refute each weakness through a real attacker-reachable entry point. This is the orchestration + discipline that makes a finding…
audit-agent-code
Security-audit an AI agent's OWN framework code for classic appsec vulnerabilities the LLM can't defend — path traversal, command injection, SSRF, fail-open security controls, missing/late auth, unsafe deserialization — especially at the untrusted-input boundaries (channels, file/media handlers, config & skill…
rt6-memory-poisoning
Red-team an AI agent's persistent memory for cross-session prompt injection ("memory poisoning") — does untrusted content the agent processes get written into long-term memory and re-fire in future sessions with no attacker present? Authorized testing of agents you own or are permitted to test.