agentleFS
harshanandakharshanandak/forge-legacy/skills/gates/SKILL.md

gates

Skill4 starsChanged 48 days agoMITView on GitHub

Toggle Forge's workflow gates and rails — strong-but-toggleable enforcement. `forge gate enable|disable <gate-id>` flips `workflow.gates.<id>.enabled` in `.forge/config.yaml`; the installed git hooks read resolved config at run time, so disabling a rail makes them genuinely inert. `forge gate approve|reject <issue> <gate>` records durable human-gate approval events; `forge gate status`/`check` query them; `forge control <id> <mandatory|optional|permission>` sets tri-state DECLARED intent (writes the same `enabled` field — no independent runtime enforcement). Use when the user says "disable the gate", "turn off TDD enforcement", "the tdd intent rail is blocking me", "toggle or enable a gate", "loosen enforcement", or "approve a human gate". Common default-ON toggleable rails: `rail.tdd_intent`, `rail.kernel_tracking`, `rail.auto_shepherd` — e.g. `forge gate disable rail.tdd_intent`. NOT for addressing PR review feedback (review), NOT the status snapshot of work in flight (status).

10 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use release.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    release

    Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).

    Also in 3 projects that use this

The file

Files
SKILL.md

Forge's gates and rails are default-strong but toggleable. The gates skill is how you flip one off (or back on), record a human-gate approval, and see enforcement state. The stored truth is one field — workflow.gates.<id>.enabled — and the installed hooks read the resolved config at run time, so a disabled rail is genuinely inert, not cosmetically off.

Toggling gates and rails

When to use

  • "Disable the gate", "turn off TDD enforcement", "the tdd intent rail is blocking me".
  • "Toggle / enable a gate", "loosen enforcement for this repo".
  • "Approve a human gate" (record a durable approval event on an issue).

Toggle a gate or rail (the enforcement switch)

forge gate disable <gate-id>     # set workflow.gates.<id>.enabled = false in .forge/config.yaml
forge gate enable  <gate-id>     # set it back to true

An unknown gate id — or disabling a locked gate — errors before anything is written, never mid-run. Because the hooks resolve config at run time, the flip takes effect immediately with no reinstall.

Common rails (default-ON, toggleable)

RailWhat it enforcesTurn off with
rail.tdd_intentPre-commit TDD gate (source changed ⇒ tests changed). The minimal adoption profile ships it off.forge gate disable rail.tdd_intent
rail.kernel_tracking"File every issue" — nothing discussed goes missing.forge gate disable rail.kernel_tracking
rail.auto_shepherdThe autonomous PR-shepherd daemon fire.forge gate disable rail.auto_shepherd

The gate.* and rail.* id namespaces are disjoint, so forge gate enable|disable governs both through one flat surface.

Human-gate approval events

forge gate approve <issue-id> <gate-id>                     # record a durable gate.approved event
forge gate reject  <issue-id> <gate-id>                     # record gate.rejected
forge gate status  <issue-id>                               # list recorded events for that issue (resume-safe)
forge gate check   <issue-id> <gate-id>                     # exit 0 iff gate DISABLED or an approval exists on that issue

check is the reusable enforcement primitive a stage skill calls: it passes when the gate is disabled or an approval event has been recorded for that specific issue id (approvals are issue-scoped, so pass the same <issue-id> you approved against). Events are durable on the issue, so they survive a compaction or crash.

Tri-state control (declared intent)

forge control <gate-id|rail-id> <mandatory|optional|permission>
forge control status [--json]

forge control sets the declared intent vocabulary and writes the same enabled field that forge gate writes — there is deliberately no parallel key. It is a view/intent layer: today no runtime consumer denies purely on a control flag (MCP/rules/skills are presence-only and refused). For actually turning enforcement off, use forge gate disable.

The doc-update gate

forge gate doc <detect|check|init|...>     # = forge doc-gate (run `forge doc-gate --help`)

The doc-update gate folds under this noun as forge gate doc; bare forge doc-gate stays as a back-compat alias.

Adjacent skills

  • Addressing PR review feedback / resolving threads → review.
  • The snapshot of where the project stands and what's in flight → status.

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.