Close

Skill snapsynapse/skill-provenance/skills/close

Update version tracking when finishing work on a skill bundle. Use when you're done editing a skill project and need to bump version headers, recompute manifest hashes, update the changelog, flag stale files, or prepare a commit message. Triggers on: "close the session", "update versions", "save the bundle", "I'm done editing", "prepare to commit", "wrap up this skill session".From its SKILL.md

Install

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

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

3.5 KB, as published. Nobody here has run it

Skill Provenance: Close

Update all version-tracking artifacts when finishing a skill editing session. This ensures the bundle leaves the session in a consistent, verifiable state.

When to use

Run /skill-provenance:close after you've finished editing files in a skill bundle and before committing, packaging, or handing off.

Protocol

Validate before mutation. Run verify-only validate.sh first when available. Resolve structural grammar, unsafe or duplicate paths, symlink components, and missing files before updating hashes. Hash mismatches and missing or malformed hashes may then be repaired with an explicit validate.sh --update workflow; hash: null remains an intentional opt-out.
Update internal version headers. For each changed file that carries YAML frontmatter with version metadata:
- Increment version by 1.
- Set version_date to today.
- Set previous_version to the old version number.
- Write a change_summary (1-3 sentences describing what changed, not just that something changed).
Update MANIFEST.yaml. For every changed versioned file:
- Update version to match the new internal version.
- Recompute and update hash.
- For files that don't carry internal headers (JSON, scripts, binaries), the manifest version field is authoritative — increment it there.
- Bump bundle_version (semver): PATCH for fixes/docs, MINOR for new features, MAJOR for breaking changes.
- Update bundle_date to today.
- If the user deployed or reinstalled the skill this session, update relevant deployments metadata.
Update CHANGELOG.md. Add a new entry at the top:
- Use the new bundle_version and today's date as the heading.
- Name every file that changed and what changed in it.
- Flag staleness explicitly. If a versioned file was changed but a dependent file was not updated (e.g., SKILL.md changed but evals.json wasn't updated to match), say so in the entry.
Final validation. Run verify-only validation after all version, changelog, and hash updates. Do not package or commit a failing bundle.
Deliver. Provide the user with the changed files plus updated MANIFEST.yaml and CHANGELOG.md.
Git commit message. If the bundle is in a git repo, provide a ready-to-use commit message:
```
bundle-name MAJOR.MINOR.PATCH: one-line summary

- file1.md: what changed
- file2.json: what changed
- Stale: file3.js (not updated this session)
```
Return the message inline. Only write a git_commit.txt file if the user explicitly asks for one.

Conventions referenced

Per-file versions are integers. Bundle version is semver.
change_summary is required for every version after v1. Describe what changed, not just that something changed.
previous_version creates a chain so any session can trace lineage.
MANIFEST.yaml is not self-listed. It tracks other files only.
Hashes are SHA-256 of file contents.

For the full spec: https://skillprovenance.dev