agentleFS
Sign inStart free
martincjarvismartincjarvis/development-skills/skills/semantic-version-impact/SKILL.md

semantic-version-impact

Skill4 starsChanged 10 months agoMITView on GitHub

Use this skill whenever changes affect a deployable component or library to determine the correct semantic version bump based on conventional commits, scope, and observed impact.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before tagging, releasing, or deploying

    line 18
  2. Distinctive:

    When reviewing change sets for release readiness

    line 19
  3. Distinctive:

    Verification: Verify that the calculated version correctly reflects the impact on the component's public contract.

    line 45
  4. Distinctive:

    Documentation: Document the proposed version bumps and the rationale for each.

    line 46
  5. Distinctive:

    Verify breaking changes trigger major version increments

    line 54
  6. Distinctive:

    Verify patch/minor are used appropriately for fixes/features

    line 55
  7. Distinctive:

    Must consume incremental-change-impact output

    line 85
  8. Distinctive:

    If breaking status is ambiguous, escalate and document decision

    line 87

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Semantic Version Impact Assessment

Intent

Derive correct semantic version changes per component/library from observed impact and change intent, ensuring releases are immutable and traceable.

When to Use

  • Any time a component/library changes and may be released
  • Before tagging, releasing, or deploying
  • When reviewing change sets for release readiness

Precondition Failure Signal

  • Version bumps are arbitrary or inconsistent
  • Conventional commit semantics are ignored or misapplied
  • Breaking changes ship under minor/patch versions
  • Components that did not change are version-bumped unnecessarily

Postcondition Success Signal

  • Each impacted component/library has a justified version bump
  • Unchanged components do not receive a new version
  • Version decisions align with change intent and observable impact
  • Release notes can be derived from the version decision

Process

  1. Source Review: Inspect the impact set and all commit messages since the last release for each impacted component.
  2. Implementation: Calculate the appropriate semantic version bump based on the nature of the changes (breaking, feature, fix).
  3. Verification: Verify that the calculated version correctly reflects the impact on the component's public contract.
  4. Documentation: Document the proposed version bumps and the rationale for each.
  5. Review: Tech Lead and Platform Engineer review the version bump calculations.

Example Test / Validation

  • Given a change set, identify impacted components and derive version bumps
  • Verify breaking changes trigger major version increments
  • Verify patch/minor are used appropriately for fixes/features
  • Confirm unchanged components remain at current versions

Common Red Flags / Guardrail Violations

  • “Just bump minor to be safe”
  • Bundling multiple components into one version decision without need
  • Downgrading breaking changes to avoid major bump
  • Skipping impact analysis and relying on assumptions

Recommended Review Personas

  • Tech Lead – validates semantic correctness and consistency
  • Release/Platform Engineer – validates traceability and component scoping
  • Domain Expert – validates whether change is breaking in practice

Skill Priority

P2 – Consistency & Governance

Conflict Resolution Rules

  • Must consume incremental-change-impact output
  • Correctness of version semantics overrides convenience
  • If breaking status is ambiguous, escalate and document decision

Conceptual Dependencies

  • incremental-change-impact

Classification

Governance

Notes

Version numbers are contracts. Treat them as part of the public surface area.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free