review-impl — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited review-impl (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 2 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.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.
What was implemented: Provided by the user as a task description or task tracker reference.
https://github.com/owner/repo/issues/123) or a shorthand reference (e.g. owner/repo#123 or #123), run gh issue view <url-or-reference> --json title,body to fetch the issue title and body. Use the fetched title and body as the canonical task description for all subsequent steps.https://yourcompany.atlassian.net/browse/PROJ-123), use appropriate Agent Skills and/or MCP tools to fetch the issue summary and description, and use those as the canonical task description for all subsequent steps.Before evaluating any changes, build a mental model of the system:
AGENTS.md, README.md, CONTRIBUTING.md, and anything in docs/.Analyze the task description to determine:
Identify the implementation changes using all available signals:
git diff HEAD~1 (and git log --oneline -5 for context). If the change spans multiple commits, widen the range to capture the full scope.Build a change inventory:
| File | Change type | Lines changed | Module/Layer |
|---|
For each changed file, assess:
When the change is a bug fix that ships a test, reading the test is not enough. A test can name the defect, assert on a plausible observable, and still pass against the unfixed code, because something else already on that path produces the same observable. Such a test reads exactly like a real one and locks nothing.
Run the control:
Green at step 3 is a High finding: the test does not lock the fix, and removing the fix later turns nothing red. Say so, and say what the assertion would have to move to - usually the observable only the fixed path can produce, rather than an end state the surrounding code reaches on its own.
The mechanics of the control - what counts as a valid break, restoring without disturbing the tree, cleaning up what a red run leaks - belong to prove-checks. Follow it rather than improvising.
When the session cannot run commands, do not skip the step silently. Record in the review that the new test was read but never observed red, so the reader knows that half of the evidence is missing.
## Implementation Review: [task description, shortened]
### Change Summary
[2-3 sentences: what changed, across which modules, and the overall approach taken]
### Findings
#### [Finding title]
- **Severity:** Critical | High | Medium | Low
- **File:** `path/to/file` (lines N-M)
- **Issue:** [what is wrong, with code evidence]
- **Recommendation:** [concrete fix - not vague advice]
<repeat for each finding, severity-descending>
### What Works Well
[Brief - 1-3 sentences acknowledging sound decisions. Do not pad.]
### Verdict
- **Risk level:** Critical | High | Moderate | Low
- **Decision:** Block | Request changes | Approve with notes | Approve
- **Key actions:**
1. …
2. …
3. …Write the review to .reviews/Review-impl-{slug}.md, where {slug} is a short kebab-case slug derived from the task description (3-5 words max).
Create the .reviews/ directory if it does not exist. If the file already exists, append a numeric index: -2, -3, etc.
After writing, print the path to the created file.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.