Is after-changes-64d69e safe to install?

SaferSkills independently audited after-changes-64d69e (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.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.hermes/skills/after-changes/SKILL.md · 1 file

.hermes/skills/after-changes/SKILL.md2.2 KB · Markdown

name: after-changes

description: Post-change checklist to run after any set of code edits. Runs three steps in sequence: (1) code review via /simplify, (2) README consistency check and update, (3) git commit. Trigger on phrases like "review and commit", "after-changes", "wrap up changes", "commit my changes", or when the user says to remember to do this after every change.

version: v1.0.0

After-Changes Checklist

Run these three steps in sequence after every set of code changes.

Step 1 — Code Review

Run the /simplify skill. Wait for it to complete and apply all fixes before moving on.

Step 2 — README Check

Run git diff HEAD (or git diff HEAD~1 if already staged/committed) to get the full list of changed files and what changed.
Read README.md.
For each changed file, check: does the README make a claim about this file, its API, its behaviour, or its config that is now stale?
Common staleness patterns:

New env vars / config keys not in the config table
API endpoints added, removed, or renamed
New UI tabs, features, or workflows not described
Architecture claims that no longer match the code
"Cannot do X" statements that are now wrong

If anything is stale or missing, update README.md in-place. Keep changes minimal — add what's missing, fix what's wrong, remove nothing that's still true.
If README is already accurate, say so and skip.

Step 3 — Commit

Run git status and git diff HEAD to review everything that will be committed.
Stage all relevant changed files (be explicit — avoid git add -A).
Write a commit message following this format:

   <type>(<scope>): <short summary under 72 chars>

   - bullet for each logical change
   - explain WHY for non-obvious changes

   Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

Types: feat, fix, refactor, docs, chore, test

Confirm the commit hash and summary.

Notes

If Step 1 (simplify) finds and fixes issues, re-check README in Step 2 for any new staleness those fixes introduced.
If there is nothing to commit (working tree clean), say so and stop.
Do not push — only commit locally unless the user explicitly asks to push.

after-changes-64d69e— agent skill

Is after-changes-64d69e safe to install?

After-Changes Checklist

Step 1 — Code Review

Step 2 — README Check

Step 3 — Commit

Notes

Audit the pieces. Scan the whole. Decide.