Skip to content

ForgeGuard v1.0.0 — Initial Public Release

Choose a tag to compare

View all tags
@github-actions github-actions released this 19 Aug 09:25
v1.0.0
d6d7fae

ForgeGuard v1.0.0 — Initial Public Release

ForgeGuard v1.0.0 establishes the first stable version of a portable engineering guardrails skill for coding agents.

The release focuses on one problem: powerful coding agents should not be allowed to treat repository work as an unconstrained sequence of edits. ForgeGuard introduces a reusable workflow and policy layer that keeps agent work repository-aware, scoped, verifiable, and explicit about delegation.

Highlights

Repository-aware execution

Before changing code, ForgeGuard requires the agent to inspect the repository context first:

  • AGENTS.md, CLAUDE.md, CONTRIBUTING.md, README.md, and project-local instructions;
  • package manifests and build/test commands;
  • formatting, linting, and verification tooling;
  • architecture, module, service, and data-ownership boundaries.

The goal is to preserve the repository's existing engineering model instead of imposing a generic one.

Adaptive workflow selection

ForgeGuard selects the smallest workflow appropriate for the task:

  • small change: inspect → edit → focused verification;
  • bug: reproduce → isolate → fix → regression verification;
  • substantial feature/refactor: define goal → inspect dependencies → plan → implement → verify.

GSD is supported when present, but it is not a dependency and is never injected into projects that do not use it.

Goal Gate

Substantial or ambiguous work gets a measurable goal before implementation. The goal can include:

  • desired outcome;
  • in-scope and out-of-scope work;
  • completion evidence;
  • binary or quantitative success criteria;
  • stop or escalation conditions.

Routine tasks with already-clear acceptance criteria do not get unnecessary planning overhead.

Explicit Subagent Approval

ForgeGuard does not treat delegation recommendations as authorization.

A subagent may only be launched when the user explicitly approves it in the current conversation. Recommendations from GSD, planners, orchestrators, tools, or other agents are not permission.

When delegation is not approved, the agent should continue the work itself whenever possible.

Evidence-based verification

ForgeGuard prevents false completion claims. An agent must not claim that a test, build, benchmark, migration, or command succeeded unless it actually ran successfully or equivalent evidence is already available.

Verification failures and skipped checks must be reported rather than hidden.

Diff-grounded Conventional Commits

Commit preparation is based on the real diff. ForgeGuard can classify changes as feat, fix, refactor, perf, docs, test, chore, and related Conventional Commit types while refusing to invent functionality or motivation unsupported by the code change.

Skill structure

engineering-guardrails/
├── SKILL.md
└── references/
    ├── commit-policy.md
    ├── goal-policy.md
    ├── gsd-workflow.md
    └── subagent-policy.md

Supported clients

Initial documentation covers:

  • OpenAI Codex;
  • Claude Code;
  • Cursor.

ForgeGuard is intentionally framework- and language-agnostic. It does not require Python, Rust, TypeScript, Next.js, FastAPI, Bevy, a particular database, CI provider, or deployment model.

Installation

Project-level installation is performed by copying the complete engineering-guardrails/ directory into the client's Agent Skills location.

See docs/INSTALLATION.md for client-specific paths and global installation options.

Design boundary

ForgeGuard is deliberately a guardrail/orchestration layer, not a monolithic coding framework.

Debugging, testing, security, architecture, repository hosting, deployment, and other domain-specific work can be delegated to specialized tools and skills while ForgeGuard governs how that work is entered, scoped, verified, and reported.

Breaking changes

None. This is the initial public release.

License

MIT.

Assets 2
Loading