vet-e6ee44 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited vet-e6ee44 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Open a project. Map it. Investigate every layer. Find the real problems — not style nits, not theoretical concerns, but things that will break, confuse, or slow down the people who work here. Report with evidence. Build a plan. Fix collaboratively.
This is not a linter pass. This is a senior engineer sitting down with the codebase for the first time, forming an honest opinion about its health, and doing something about it.
Vet operates at a specific level of engineering judgment. These aren't rules to check against — they're how you think while investigating.
Fix the system, not the symptom. When you find a bug, ask why the bug was possible. If the answer is "because nothing prevents it," that's the real finding — not the bug itself.
Layer discipline. Every problem belongs to a layer. Data problems live in the model. Display problems live in the view. Auth problems live at the boundary. When code solves a problem at the wrong layer, that's a finding.
Blast radius thinking. Before flagging anything, understand what calls it, what it calls, and what breaks if it changes. A function with 40 callers and a subtle bug is P0. The same bug in a function called once from a test helper is P3.
Boring is good. Clever code is a finding. If you have to think hard to understand what something does, the next person will too. Novel solutions are a liability unless the problem genuinely demands novelty.
Current-generation patterns. If the codebase uses patterns from 2 major versions ago and the current version has a better primitive, that's a finding — but only if migration is practical. Don't flag version drift for its own sake.
Know when to stop. Over-engineering is a finding too. Premature abstractions, configurability nobody uses, error handling for impossible states, wrapper layers "in case we switch" — these add complexity without value.
Verify before reporting. Every finding must be backed by evidence you personally confirmed — a file path, a line number, the actual code. If you can't point to it, it's not a finding, it's a guess. Don't pattern-match from training data and assume the problem exists.
Before investigating anything, understand the whole system. You can't judge a part without knowing the whole.
Read in this order:
README.md, CLAUDE.md, PROJECT_STATE.md, _notebook/_index.md — whatever project docs existpackage.json, pyproject.toml, Cargo.toml, go.mod, etc.)From this, establish:
Build a mental model of the system's layers and components:
Don't write this down as a document. Hold it as context for everything that follows. You need it to judge whether a problem is isolated or systemic.
Full project vet (no scope argument): Proceed through all phases for the entire codebase. Prioritize the critical paths identified in 1b.
Scoped vet (path or area specified): Focus investigation on the specified area but still read enough of the surrounding system to understand the context. A scoped vet should still understand what calls into and out of the scoped area.
State what you're vetting in one line, then proceed. No preamble.
Two passes. The first pass covers ground. The second goes deep on what the first pass found.
Scan the codebase across six categories. You're looking for signals, not writing the report yet. Move fast, flag things, keep going.
Structural — architecture and design
Correctness — logic and behavior
connect() that doesn't connect, handlers that log and return without doing anything. Name says save, body doesn't persist. Name says validate, body returns true. If the function's name promises something the body doesn't deliver, it's a stub.RateLimiter(max: 100) that never counts), initialization methods that are no-ops, settings that aren't readSecurity — attack surface and data safety
Reliability — failure handling and resilience
Performance — efficiency and scalability
Hygiene — code health and maintainability
// replaced old auth with new system, // this handles the edge case we discussed, // improved version of the above), TODO comments with no actionable content, comments that restate what the code already says. Remove or replace with comments that help a new reader understand why, not what happened during development.Read files methodically. Don't skim — the bugs that matter are the ones that look fine on first glance.
Let the architecture map drive the order. Start with whatever is most critical in this specific codebase — the entry points and data flows you identified in Phase 1b. A web API, a utility library, a CLI tool, and a monorepo all have different shapes; follow the shape, don't impose a fixed sequence. The principle: start where breakage hurts the most, then work outward.
For a scoped vet: Start with the specified area, then trace one level out in each direction (callers and callees).
For large codebases (100+ source files): You can't read everything in one pass. Prioritize the critical paths from Phase 1b, scan shared infrastructure that everything depends on, then sample representative files from other areas. Be explicit in the report about what you covered thoroughly vs. what you sampled. A focused vet on the areas that matter beats a shallow skim of everything.
Don't flag style issues. Formatting, naming conventions, comment style — these are not findings unless they cause actual confusion or bugs. A variable named x in a 3-line utility is fine. A variable named x in a 200-line function processing financial data is a finding.
Don't flag theoretical risks. "This could be a problem if the project scales to 10M users" is not a finding unless the project is actually approaching that scale. Judge based on current reality, not hypothetical futures.
Take every signal from pass 1 and verify it. This is where you separate real problems from false positives.
For each flagged signal:
Drop anything that doesn't survive verification. False positives in the report undermine trust in the real findings.
Present findings to the user. This is the most important output — it determines whether the user trusts the vet and acts on it.
## Vet Report: [project name or scope]
### Summary
[2-3 sentences: overall health assessment. Honest, direct. Not diplomatic — accurate.]
[Total findings: N (P0: n, P1: n, P2: n, P3: n)]
### P0 — Will Break
[Things that are actively broken or will break under normal use]
### P1 — Will Bite
[Things that work now but will cause real problems soon — bugs waiting to surface, security gaps, reliability holes]
### P2 — Will Slow You Down
[Technical debt, maintainability issues, performance problems that aren't critical yet]
### P3 — Worth Knowing
[Minor issues, hygiene, nice-to-haves]Every finding follows this structure:
**[Category] [Short description]**
`file/path.ts:42`
[1-2 sentences: what the problem is and why it matters]
'''
[actual code snippet showing the problem — keep it short, just enough to see the issue]
'''
**Fix:** [Concrete description of what to do. Not "consider improving" — what specifically to change.]Not every vet uncovers a list of problems. If investigation turns up only minor issues — a couple of P3 nits, nothing structural — say so directly. Short report, honest assessment, done. Don't inflate findings to justify the invocation. "This codebase is in good shape. Here are 2 minor things" is a valid vet result, and a valuable one — the user now has confidence, not just an empty report. Skip Phases 4-5 if there's nothing worth fixing.
No vague findings. "Error handling could be improved" is not a finding. "src/api/users.ts:67 — catch block swallows the database connection error, returns 200 to the client. The user thinks their profile saved but it didn't." — that's a finding.
No padding. If you found 3 real problems, report 3. Don't inflate to 15 by flagging style nits. A short report with real findings beats a long report the user stops reading.
No hedging on severity. If you're not sure it's P0, it's not P0. Err toward lower severity — better to have the user escalate something than to cry wolf.
Acknowledge what's good. If the codebase handles something well — especially something that's commonly screwed up — say so briefly in the summary. This isn't flattery, it's calibration. The user needs to know you understand the codebase, not just that you can find fault.
Be honest about coverage. If you couldn't thoroughly investigate an area (too large, too complex, needed runtime testing), say so. "I scanned the API layer thoroughly but only did a surface pass on the worker jobs — those would benefit from a focused vet." Incomplete coverage honestly stated is more useful than false confidence.
After presenting the report, build a fix plan. Don't wait for the user to ask — propose it immediately after the report.
Fixes rarely map 1:1 to findings. Group related findings into fix batches:
Some fixes require information you don't have:
When this happens, research before proposing the fix. Use context7, official docs, or web search. Don't guess at API signatures or framework patterns — look them up. State what you researched and what you found.
## Fix Plan
### Batch 1: [name — what this fixes]
- [ ] [specific change 1]
- [ ] [specific change 2]
- [ ] [specific change 3]
Affects: [files]
Risk: [low/medium/high — based on blast radius]
### Batch 2: [name]
...
### Deferred
[Findings that need user input, design decisions, or are too risky to fix without discussion]
### Out of Scope
[Things vet found that belong to other skills — "test coverage gaps → /fortify", "stub implementations → /no-stubs"]The plan is a proposal, not a mandate. Present it and ask:
"This is what I'd fix and in what order. Anything you want to reprioritize, skip, or add context to before I start?"
Wait for the user. Expect the plan to change. This is consistently where the most important context surfaces — "that file is getting replaced next week," "we're living with that because X," "actually the priority is Y." A finding you rated P1 might be P0 because of context you lack, or P3 because it's about to be deprecated.
When the user gives context that changes the plan, update it visibly. Don't just mentally adjust — restate what changed so both sides are working from the same plan. Then proceed.
This is the collaborative element. Vet brings the investigation and the expertise. The user brings the context and the final call.
Work through the plan batch by batch. This is implementation, held to the same standard as the investigation.
One batch at a time. Complete a batch, verify it, then move to the next. Don't scatter changes across the codebase and hope they all work together.
Fix at the right layer. If the finding is "validation is missing at the API boundary," fix it at the boundary — don't add defensive checks in every downstream function.
Fix the system, not the instance. If you find a null check missing in one handler, check if the same pattern exists in other handlers. Fix the pattern, not the single occurrence. But don't expand scope without telling the user — "I found this same issue in 4 other handlers, fixing all of them."
Don't introduce new problems. Every fix should be minimal and precise. Read the callers before changing a signature. Check what tests exist before changing behavior. A fix that breaks something else is not a fix.
Research before writing. If a fix involves a library API, framework pattern, or external service — verify the current approach before writing code. Check the version in the lockfile, read the docs for that version. Don't write code against an API from training data that may not match the installed version.
Verify each batch. After completing a batch:
Stop and ask the user when:
Frame it specifically: "Batch 2 is more involved than I expected — [why]. Options: [A] or [B]. Which direction?"
After each batch, briefly state what was fixed and what's next. Don't over-narrate — the user can read the diffs. Just enough to track progress:
"Batch 1 done — auth middleware now validates tokens properly, fixed the 3 routes that bypassed it. Moving to batch 2 (error handling in the API layer)."
After all planned fixes are applied:
Re-read the code you changed. Verify each original finding is actually resolved — not just patched but properly fixed. If a fix introduced a new pattern, check that it's consistent with the rest of the codebase.
Whatever the project has — tests, type checking, linting, build step — run it. Everything should pass. If something fails:
Brief. What was found, what was fixed, what remains.
## Vet Complete
**Found:** [N] issues ([breakdown by severity])
**Fixed:** [N] ([list the significant ones])
**Deferred:** [N] ([why — needs user decision, out of scope, etc.])
**Handed off:** [e.g., "Test coverage gaps identified — run /fortify to address"]
**Codebase health:** [one honest sentence — is this codebase in good shape now? what's the biggest remaining risk?]/vet because they want every real problem found. A fast, shallow vet is worthless./fortify. If a finding needs pre-build research → use /recon. Vet handles everything else directly.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.