review-against-intent — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited review-against-intent (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.
<what-to-do>
Load the active intent. If PATHMODE_API_KEY is set, call get_current_intent (Pathmode MCP). Otherwise read intent.md from the project root.
Identify the changed files using git diff against the base branch (or staged changes if no base specified).
For each outcome in the intent, check whether the changes actually deliver it — with specific file/line evidence. For each constraint, check whether the changes respect it. For each edge case, check whether it's handled.
Report:
Do NOT review for unrelated code style, formatting, or quality concerns. That's not this skill's job. Stay anchored to the intent.
</what-to-do>
<supporting-info>
Most code review tools check correctness, style, or security. They cannot check whether the code does what it was MEANT to do, because they don't see the intent.
This skill bridges that gap. It treats the intent spec as a contract and the code change as the proposed satisfaction of that contract. A PR can pass every other check and still fail this one — because the intent it was supposed to deliver isn't actually delivered.
For an outcome like "Payment completes in under 3 seconds (p95)":
A code change that adds a feature without a corresponding metric does NOT deliver this outcome. Surface that gap.
Constraints are hard limits — "PII must not survive a logout", "checkout must not block on network calls > 500ms", etc.
If a change introduces a constraint violation, treat it as a blocker. Be specific: name the constraint, name the file/line, explain how the change violates it.
When the review finds gaps, the user often wants to record what's not yet done so a future session can pick it up. Call log_implementation_note for each significant gap. Make the note self-contained — the next reader won't have this conversation's context.
</supporting-info>
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.