Versionkeeping plugin
Versionkeeping is an Agent Plugins package with a native Claude adapter. It owns task-only checkpointing, intent-aware conflict resolution, deterministic exact-lease publication, separately authorized remote-ref deletion, provenance-aware worktree lifecycle, and history-preserving fork synchronization.
It owns local Git integration, fork synchronization, and separately authorized terminal remote-ref deletion. It deliberately does not own Graphite operations; review or pull-request creation, text, readiness, resolution, or merge actuation; or model and delegation policy.
Checkpointing establishes the destination's contribution policy before the first commit. Required DCO sign-offs use the authorized contributor identity; concrete ownership or provenance uncertainty needs evidence or escalation. Repositories without a DCO requirement keep their ordinary commit process.
Skills
| Public name | Responsibility |
|---|---|
$versionkeeping:checkpointing-and-publishing-git-work | Git/index/ref/push safety, separately authorized remote-ref deletion, completion choices, and provenance-aware terminal cleanup. |
$versionkeeping:resolving-merge-conflicts | Conflict interpretation and authorized file edits, with Git mechanics handed to checkpointing. |
$versionkeeping:using-persistent-git-worktrees | Durable sibling worktree location, creation, movement, repair, and handoff. |
$versionkeeping:syncing-forks-with-upstream | Contract-aware fork synchronization that preserves upstream commit identity. |
Layout
plugins/versionkeeping/
├── plugin.json # Canonical Agent Plugins v1 manifest
├── .claude-plugin/plugin.json # Claude adapter manifest
├── skills/ # Shared harness-neutral core
│ └── checkpointing-and-publishing-git-work/
│ ├── references/ # Publication, cleanup, and eval integrity
│ └── scripts/ # Publication and deletion planner/executor routes
│ └── resolving-merge-conflicts/ # Interpretation and authorized resolution edits
├── topology.json # Canonical component, call, and operation map
├── CHANGELOG.md
└── LICENSE
The Claude manifest and skills/*/agents/openai.yaml are thin client adapter
surfaces around the standard package. Shared skills do not assume a client-specific installation location:
they resolve helper scripts from this plugin root.
The schema_version in topology.json versions Versionkeeping's local
topology shape, not a repository-wide interchange schema.
Package validation
From the package root, these checks use only plugin-relative paths:
python3 skills/checkpointing-and-publishing-git-work/scripts/plan_git_publication.py --help
python3 skills/checkpointing-and-publishing-git-work/scripts/execute_git_publication.py --help
python3 skills/checkpointing-and-publishing-git-work/scripts/plan_git_remote_ref_deletion.py --help
python3 skills/checkpointing-and-publishing-git-work/scripts/execute_git_remote_ref_deletion.py --help
The evaluation-gate regression suite is repository-only evidence, not an
installed runtime test. From the repository root, run
python3 tests/plugins/versionkeeping/checkpointing-and-publishing-git-work/test_eval_gate.py.
The planner may fetch bounded objects and create target-local temporary refs; it is not an installed read-only validation gate.
The ordinary publication planner and executor accept only update/create refspecs and never delete a remote ref. Terminal remote-ref deletion is a separate plugin-relative planner/executor route that requires a verified merge outcome plus explicit repository and operator authorization binding the exact remote, full ref, and expected SHA. It deletes under an exact expected-SHA lease and completes only by verifying the ref is absent.
Ordinary publication also observes and binds the push endpoint's symbolic
default branch. A direct push to that observed ref remains blocked unless the
request carries a matching, separately verified repository policy decision
with direct_push_permitted: true; topic refs remain subject to the ordinary
ownership, review, verification, and exact-lease gates.
Repository release validation
Repository maintainers additionally run python3 scripts/validate_versionkeeping.py
and python3 -m unittest tests/test_validate_versionkeeping.py from the
repository root. Canonical development and release evidence lives at
evals/versionkeeping/, tests/plugins/versionkeeping/, and
release/plugin-content-locks/versionkeeping.json; none of it is installed in
the runtime root. The validator reads topology.json as the
canonical component and ownership inventory and verifies the generated semantic
content lock.
License and provenance
The plugin is MIT-licensed. Its Git-publication planner and baseline workflows are migrated from the operator-owned canonical skill stack. No third-party source or attribution requirement was identified in the supplied inputs.