Validate

Skill snapsynapse/skill-provenance/skills/validate

Run a focused validation check for a skill bundle. Use when the user asks to validate, verify hashes, check MANIFEST.yaml, confirm files are present, or distinguish a canonical bundle from a derived install or registry copy without opening or closing a full editing session.From its SKILL.md

Install

npx -y skills add snapsynapse/skill-provenance --skill validate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.5 KB, as published. Nobody here has run it

Skill Provenance: Validate

Run the hash and inventory check only. This is a narrow verification command, not the full open-session or close-session protocol.

When to use

Run /skill-provenance:validate when the user wants to know whether the current bundle matches its MANIFEST.yaml, whether files are missing, or whether a copy appears to be canonical or derived.

Protocol

Locate the bundle root. Use the directory containing MANIFEST.yaml. If no manifest exists, report that the bundle is unversioned and suggest /skill-provenance:bootstrap.
Run validate.sh when available. Prefer:
```
./validate.sh
```
If the script is not present, compute SHA-256 hashes for files listed in MANIFEST.yaml and compare them manually.
Report validation results only. Include:
- File count checked
- Missing files
- Hash mismatches
- Explicit hash: null opt-outs
- Structural, unsafe-path, duplicate-path, and symlink errors
- Matching, stale, or malformed validated_against records when present
- Exit code or equivalent pass/fail result
Identify copy type. Use MANIFEST.yaml and local contents to say whether the copy appears to be:
- a canonical source bundle
- a strict-platform install copy
- a registry or .skill package
- incomplete or ambiguous A derived copy is valid if its own manifest describes exactly the files present. Do not treat missing development-only files as corruption unless the copy's manifest lists them.
Do not mutate files. Do not update hashes, bump versions, edit the changelog, create a handoff note, or run the close protocol. If the user asks to fix mismatches, recommend /skill-provenance:close or an explicit validate.sh --update workflow.

Output

Keep the response concise:

Bundle: my-skill 1.2.0
Copy type: canonical source bundle
Files: 7 checked, 0 missing, 0 mismatched, 0 explicit opt-outs
Result: pass

If validation fails, name the specific files and explain that a mismatch means the file no longer matches the recorded manifest state. This is an integrity check, not a trust anchor.