Skip to content

ForgeGuard v1.3.0 — Commit Intelligence

Choose a tag to compare

View all tags
@github-actions github-actions released this 19 Aug 12:07
v1.3.0
d3ed1d1

ForgeGuard v1.3.0 — Commit Intelligence

ForgeGuard v1.3.0 strengthens commit preparation into an evidence-driven engineering step rather than a one-line message generator.

The release makes structured git diff analysis mandatory whenever ForgeGuard prepares a commit message or commit summary.

Highlights

Mandatory diff-first analysis

The real git diff is the primary source of truth. ForgeGuard determines the primary change type from the actual changes and supports Conventional Commit categories including:

  • feat — new capability;
  • fix — bug fix;
  • refactor — restructuring without intended behavior change;
  • perf — performance improvement;
  • docs — documentation-only change;
  • style — formatting/style-only change;
  • test — test-focused change;
  • chore — maintenance work.

If a diff contains materially unrelated changes, ForgeGuard must state that and recommend splitting the work into separate commits when appropriate.

Conventional Commit subject discipline

Preferred format:

<type>(<scope>): <short summary>

When no meaningful scope can be inferred:

<type>: <short summary>

Rules include:

  • maximum 72 characters unless the repository defines a stricter limit;
  • imperative mood;
  • concise and specific wording;
  • scope only when supported by the affected module/service/package/domain;
  • no claims unsupported by the diff.

Mandatory structured Description

The Description section is now mandatory and must not be omitted, even when the user asks only for a commit message.

Required shape:

<type>(<scope>): <short summary>

Description:
- Changes:
  - ...

- Reason:
  - ...

- Implementation Details:
  - ...

- Impact / Risks:
  - ...

- Breaking Changes:
  - None

Evidence-aware Reason

ForgeGuard only explains why a change was made when the reason is inferable from the diff or explicitly supplied task context.

If intent cannot be established, ForgeGuard says so directly instead of inventing a plausible explanation:

- Reason is not inferable from the diff alone.

Evidence-aware verification claims

Commit preparation must not claim that tests, builds, migrations, deployments, benchmarks, or verification steps succeeded without supporting evidence.

ForgeGuard also avoids unsupported claims about:

  • security improvements;
  • compatibility guarantees;
  • performance improvements;
  • production effects.

Explicit Impact / Risks and Breaking Changes

Commit reports now separate observed changes from their direct engineering impact.

Impact / Risks should contain effects reasonably supported by the diff. Breaking Changes must describe actual breaking changes when present; otherwise it must explicitly contain None.

Why this matters

A commit message is part of the engineering record. Agent-generated commits become dangerous when they sound authoritative while inventing intent, verification, or impact that the diff does not prove.

ForgeGuard v1.3.0 treats commit preparation as evidence-backed documentation of the change.

Upgrade

Refresh an existing installation:

npx --yes github:GendByteMaster/ForgeGuard install --force

For Codex installations, start a new session after upgrading so the managed repository instructions reload the updated skill.

Compatibility

No compatibility changes. ForgeGuard remains portable across supported Codex, Claude Code, and Cursor skill locations.

Breaking changes

None to installation or runtime behavior.

Commit-output behavior is intentionally stricter: ForgeGuard now always emits the complete structured Description when preparing commit output.

License

MIT.

Assets 2
Loading