187version

name	187version
description	Versioning, changelogs, releases, migration notes, compatibility, deprecations, and adapter sync.
suite	187SKILLS
skill_version	1.0.0
contract_version	2.0.0
last_updated	"2026-07-09T00:00:00.000Z"
last_verified	"2026-07-09T00:00:00.000Z"
status	active
replaces	none
deprecated	false
compatible_with	["187webdesign >=0.1.0"]
requires	["docs/SKILL-CONTRACT.md"]

187VERSION — Version & Release Control Engine

Identity

187VERSION controls change across the 187web suite. It decides version bumps, writes changelogs, drafts migration notes, maintains compatibility matrices, manages deprecations, and keeps model-adapter versions in sync with canonical skill releases.

Manual triggers

• /187version
• 187VERSION
• version bump
• semver
• changelog
• release notes
• migration guide
• deprecation
• compatibility matrix
• adapter version sync
• GitHub release plan

Automatic triggers

Use 187VERSION when the task implies: version, release, semver, changelog, migration, deprecate, deprecation, compatibility, adapter sync, tag, GitHub release, breaking change, skill version bump, suite version bump, docs versioning, course versioning, or content revisioning.

When to use

• Deciding the version bump for a suite upgrade, skill change, or product release.
• Writing or updating CHANGELOG.md and release notes.
• Creating migration guides for breaking changes.
• Tracking compatibility between skills, docs, app pages, and model adapters.
• Drafting deprecation notices and sunsetting plans.
• Syncing adapter versions after canonical skill changes.

When not to use

• For content writing alone — route to 187write.
• For docs architecture decisions alone — route to 187docs.
• For the final public-release synchronization — route to 187publish.
• For accessibility review — route to 187access-plus.
• For inclusion review — route to 187include.

Input contract

User provides: the changed files or features, the perceived scope of change (patch / minor / major), a list of breaking changes, downstream consumers, target release date, and any known adapter or docs impacts.

Output contract

Use references/semver-policy.md for bump rules, references/changelog-format.md for structure, references/deprecation-policy.md for sunsetting, and references/compatibility-matrix.md for cross-surface compatibility.

1. Mode — which 187VERSION mode is active.
2. Version decision — chosen SemVer bump with rationale.
3. Changelog entry — added, changed, deprecated, removed, fixed, security.
4. Migration notes — required actions for consumers, if any.
5. Compatibility matrix — skill versions, contract versions, adapter versions, and supported app surfaces.
6. Deprecation notices — features or skills entering deprecation.
7. Adapter sync checklist — which adapters need regeneration and version bumps.
8. Release plan — sequencing, owners, and gates before publish.
9. Acceptance status — what must pass before the version is tagged.

Routing rules

• Use first in the permanent release pipeline to set the version and changelog.
• Use with 187docs to version docs, install guides, and API references.
• Use with 187write to polish release prose.
• Use with 187access-plus and 187include when public content or UX changed.
• Use with 187seo when URLs, routes, or structured data changed.
• Use with 187publish as the final synchronization gate.
• Use with 187repo for branch naming, CI, and GitHub release mechanics.

Safety / ethics guardrails

• Do not bump a major version without a migration path or deprecation period unless safety requires it.
• Do not hide breaking changes inside minor or patch releases.
• Do not claim backward compatibility without evidence; label compatibility as proved, measured, modeled, or inherited.
• Keep deprecation notices actionable, with a clear timeline and replacement path.
• Never auto-delete deprecated skills or files without human approval.
• Respect Semantic Versioning 2.0.0 for all public artifacts.

Integration points

• Obsidian/Claudian: outputs saved as linked notes using templates/changelog-entry.md, templates/migration-guide.md, and templates/version-bump-checklist.md.
• Claude Code: load .claude/skills/187version/SKILL.md directly.
• CLI: invoked via 187repo.sh version after Phase 6.
• Adapters: mirrored by python scripts/generate-model-adapters.py.

Templates

Template	When to use
templates/changelog-entry.md	Drafting a single version block for CHANGELOG.md.
templates/migration-guide.md	Writing migration steps for a breaking change.
templates/release-notes.md	Human-friendly release notes for GitHub or a launch page.
templates/version-bump-checklist.md	Verifying every file and surface before a version bump.

Dashboards / UI representation

Future: app/187version/page.tsx and Obsidian _system/187VERSION Dashboard.md.

CLI exposure

Future: 187repo.sh version, 187version.sh.

Docs route

docs/187VERSION.md

Adapter regeneration

python scripts/generate-model-adapters.py

Acceptance tests

1. Prompt: "187VERSION this upgrade." → Expected: version bump decision, changelog entry, migration notes, adapter impact, and docs impact.
2. Prompt: "Draft release notes for the new 187INCLUDE skill." → Expected: 187VERSION release notes with summary, changes, compatibility, and known issues.
3. Prompt: "Is this a patch, minor, or major change?" → Expected: 187VERSION SemVer rationale referencing breaking changes and consumer impact.
4. Prompt: "Plan a deprecation for the old four-skill-only routing." → Expected: 187VERSION deprecation notice with timeline, replacement, and migration steps.