module-version-increment

Increment Intent Architect module versions and propagate changes to dependent modules.

23|10|Updated Aug 31, 2017
One-click install
npx skills add https://github.com/IntentArchitect/Intent.Modules --skill module-version-increment-intentarchitect
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: module-version-increment
Source: https://github.com/IntentArchitect/Intent.Modules/tree/main/Tests/ModuleBuilderSkills/.opencode/skills/module-version-increment
Command: npx skills add https://github.com/IntentArchitect/Intent.Modules --skill module-version-increment-intentarchitect

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Module versions determine whether consuming applications receive a change, and getting them wrong in either direction breaks distribution: too low and consumers never see the update, too high and they expect a compatibility break that never happened. This Skill governs when and how to bump a module's semantic version so changes are actually picked up. ## Core Features & Use Cases - Up-front incrementing: Move the version before implementing a change, choosing patch, minor, or major based on impact to consumers of the module's generated output. - In-flight gating: Check configured module feeds (with prereleases included) to confirm nothing at or beyond the current version is already published before bumping, avoiding phantom prerelease increments. - Dependent propagation: Update pinned dependency versions, shared-contract participants, and minimum-version floors across modules affected by the change. - Use Case: Before modifying a module's template code, run this Skill to bump its version from 1.2.0 to 1.2.1-pre.0, verify via feed search that 1.2.1 is unpublished, and update every dependent module that pins the old version. ## Quick Start Increment the version of every module this task will change, choosing the right component based on consumer impact, and confirm dependents are updated at close-out.

Frequently Asked Questions about module-version-increment

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide between patch, minor, and major version bumps?▼

Judge impact on consumers of the module's generated output, not its source. Patch covers small fixes or narrow settings, minor covers genuinely new capability dimensions, and major covers changes to how users already interact with the module. When ambiguous, choose the higher component.

When should I increment a module version during a task?▼

Increment before implementing, as soon as you know which modules the task will touch. A module rebuilt at an already-published version is silently ignored in favor of the published copy, so work done before the version moves cannot be verified.

How do I check if a module version is already published?▼

Search the module's configured feeds with the prerelease flag included, since prereleases are hidden without it. Compare results by semver precedence, and ignore the machine-local build-output repository, which only reflects your own compiles.

Why does my rebuilt module not get picked up by consumers?▼

Rebuilding at a version that is already published is shadowed by the published copy. Move the prerelease component forward so the new build is installable, and consolidate to the final release version when the work is done.

Do dependent modules need version updates too?▼

Yes. Every module whose template or extension code changed needs its own increment, shared-contract participants must move together, and modules pinning this one need their dependency entries or minimum-version floors updated.

Why did my .imodspec regeneration show no changes after a version edit?▼

The Software Factory silently refuses to regenerate if the new version sorts lower than the version already on disk, and prerelease suffixes sort below the same release number. Temporarily lower the version line, then reapply the intended version and regenerate.