# step-gate: making an agent skip steps physically impossible > step-gate is an agent skill package that turns a step-by-step workflow into one enforced by a program rather than by prompt wording. A state machine, an admission receipt and a command whitelist make it impossible for an agent to complete a step it was never handed, and the package ships prebuilt binaries for five platforms. The last push was on 2026-09-05 and there are no releases. **daixudk96-max/agent-skill-gate** — Agent Skill 步进治理体系：由程序保证 Agent 不跳步骤（step-gate Rust 门控 + 交付门 + 链治理） - Repository: https://github.com/daixudk96-max/agent-skill-gate - Stars: 574 · Forks: 15 - Language: Python - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/daixudk96-max-agent-skill-gate ## Enforcement in code instead of instructions in prose The central claim of this project is that the program, not the model, guarantees an agent cannot skip a step. That distinction is the whole design, and it comes from a specific failure mode. A skill written as prose tells an agent what to do, and a model can read a step description and act as though it has done the work, or produce an answer for a later step without ever having seen the guidance for that step. Nothing in the prompt prevents it. step-gate moves the constraint out of the prompt. A local program holds the workflow state, decides which step is current, hands out the guidance for that step and only that step, and refuses completion unless a receipt proves the guidance was delivered. The result is described as being physically impossible to bypass, which is a strong claim, but the mechanism behind it is straightforward and worth reading precisely. The package is a standard-format agent skill, made of a SKILL.md file, a runtime and tools, and it is installed into an agent's skill directory. The intended use is a single instruction to the agent, telling it to convert an existing skill into a step-gated one, at which point the agent runs through three gated steps: understand the target skill, transform and govern it by generating a flow.yaml, guides and validators, then accept and distribute it. The audience is anyone building multi-step agent workflows where order matters, and the tooling is deliberately platform-agnostic, with support named for several coding agents and a per-platform binary shipped in the package. ## Copy the directory and pick a platform Installation is a file copy, not a package manager step. The instruction is to copy the entire skills/step-gate/ directory into the agent's skill directory, keeping the directory name step-gate, and three locations are given. For Claude Code it is the .claude/skills/step-gate/ directory under the user home. For DSH, Cursor, OpenCode and Gemini CLI at project level, it is the .agents/skills/step-gate/ directory under the project root, and at global level the same .agents/skills/step-gate/ path under the user home. What removes the usual install friction is that the package ships with binaries for five platforms built in, covering windows-x64, linux-x64, linux-arm64, macos-x64 and macos-arm64, and the README states there are zero runtime dependencies. No Python environment, no compiler, no download step at install time. The package layout explains where the work happens. There is a SKILL.md in the standard Anthropic format with frontmatter and progressive disclosure, a flow.yaml holding the step gate declaration for the skill itself, a guides directory holding the per-step guides that are delivered on demand, a bin directory with the five platform binaries, a scripts directory with run.cmd and run.sh launchers that select the platform automatically and enforce a command whitelist, a tools directory with skill-converter.py, skill-pack.py and check_bins.py, all written with the standard library only, plus INSTALL.md and LICENSE.txt. The division of labour is sensible. The launchers stay thin, the tools are portable Python, and the actual enforcement lives in a compiled binary, which is what makes the guarantee independent of the agent runtime. ## The state machine and the admission receipt Two mechanisms carry the enforcement, and they work together. The first is the state machine. Every step starts pending, moves to current when it is handed out, and ends done. Only the current step can be completed. A step that fails moves to failed, and a failed step can be repaired and retried. Branch alternatives that are not taken are marked skipped automatically. The flow.yaml file declares the steps and the artifact rules for each one, with validators of the file and non-empty kinds, meaning the program checks that a named artifact exists and that it is not empty before it will accept the step. The second is the delivery gate. When the agent asks for the next step, the program pushes that step's complete guide to the agent and writes a receipt, called an admission record, at the same time. On completion, the program checks for that receipt, and a completion with no receipt is refused. This is the part that closes the loophole the project is aimed at. The agent cannot claim to have completed a step it was never handed the instructions for, because the receipt exists only if the guide was actually delivered, and delivery is something the program does rather than something the agent asserts. Combined with the artifact validators, a step has to satisfy two independent conditions before it is accepted: the guide for that step must have been delivered, and the artifacts the step was supposed to produce must exist and be non-empty. A skipped next or a modified contract results in an exit code of 1 and a block. ## Chaining skills and conditional branches The scope is wider than a single workflow. Chain governance lets several skills be strung into a chain through a chain.json file, and the ordering across skills is gated by the program in the same way as ordering within one skill. That matters for a real agent setup, where a task often spans a research skill, an implementation skill and a review skill, and the failure mode of one of them skipping its own steps undermines the whole sequence. The branch state machine is the other extension. flow.yaml supports conditional branches, decided by the program using file, non-empty or contains tests, with an else fallback. The point of putting the decision in code is that the condition is evaluated against the filesystem state that the previous step actually produced, not against the agent's description of what it produced. An if X then do A otherwise do B rule is thus a program decision, and the branch that was not taken is marked skipped automatically, so the record of what happened stays accurate rather than being whatever the agent says happened. The verification section describes how this was checked. The core guarantees passed 84 unit tests, plus four scenario tests in an empty DSH session covering a direct completion attempt being rejected, a skipped next being rejected, an old package migration gate, and the standard flow passing end to end. The branch state machine was exercised in three end-to-end scenarios, the else fallback, a when condition hit, and meta decision recording. One caveat on those numbers. They are the project's own claims, and the unit tests and the DSH session runs are not something a reader can check from the repository listing, which shows only a .gitignore, a LICENSE, a README.md and a skills/ directory. The tests live inside the package. ## Anti-bypass rules and the operator token The anti-bypass design has three parts, and the third is the one that decides whether the whole thing holds. The state file is only read and written by the program. The agent has no supported way to edit it, so it cannot promote itself to the next step by writing a file. The admin commands require an operator token. The commands named are reset, fail and init, and they are the operations that would let a human force the state machine into a different position, set a step to failed, or initialise a flow. Those are behind the operator token rather than available to the agent. The launcher whitelists commands for the agent. The run.cmd and run.sh scripts do not forward an arbitrary command line to the binary, they select the correct platform binary and expose only the commands an agent is allowed to call. This is the piece that stops the obvious workaround of invoking the gate binary directly with a different subcommand. The content placement rule is separate from the state machine but belongs to the same philosophy. When converting a skill, the original skill's prompts, examples, do and don't lists are copied verbatim into the step guide that uses them, and if several steps use them they are copied into several guides. There is deliberately no bucket for advanced content. The reasoning is that a step guide handed to the agent should contain everything that step needs, because the delivery gate guarantees only that the guide was delivered, and the guarantee is worthless if the actual content was left somewhere else. Taken together, the design is a coherent answer to one problem: an agent that is told to follow steps and does not. Whether that is your problem depends on how much your workflow depends on ordering. ## Apache 2.0, no releases, and a single authored package The licence is Apache-2.0, stated in the README with a pointer to the LICENSE file, and the package carries the same licence in skills/step-gate/LICENSE.txt. That is a permissive licence with an explicit patent grant and no copyleft obligation on anyone who incorporates the code, which is a reasonable position for tooling of this kind. The maintenance picture is thinner than the feature list suggests. The repository has no GitHub releases, and the last push was on 2026-09-05. The top-level listing is just a .gitignore, a LICENSE, a README.md and a skills/ directory, so the whole project is the one package, with no second implementation and no test suite visible at the top level. That shape has a consequence for anyone considering this. You are adopting a single authored artifact rather than a project with a wide contributor base, and the release channel is a copy of a directory rather than a versioned dependency. There is no version number to pin, no upgrade path and no changelog to read, which means the practical upgrade process is copying a new directory over the old one and hoping the state file format did not change underneath you. The README mentions an old package migration gate in its testing, which suggests at least one such format change has happened, and it is worth asking the author how existing installations are expected to migrate. The tool is also not a service. The state lives in a local file, the binaries are local, and the guarantee covers only the step ordering inside a workflow you have already converted. It says nothing about whether the work a step produced is any good. ## Conclusion Adopt step-gate if your agent workflows depend on steps actually being taken in order, and you can accept that the guarantee comes from a local binary and a state file rather than from a hosted service. Do not adopt it for a single-step task, for a workflow that needs genuine branching judgement rather than the file and non-empty conditions it supports, or if your environment is outside the five platforms with prebuilt binaries. Verify first that the launcher on your platform selects the right binary, that the admin commands reset, fail and init stay behind the operator token, and that your skill's prompts and examples are copied into the per-step guides rather than left behind, since the package treats that placement rule as the point of the whole exercise. ## FAQ ### How do I install the step-gate agent skill? Copy the whole skills/step-gate/ directory into your agent's skill directory, keeping the directory name step-gate. For Claude Code that is .claude/skills/step-gate/ under your home directory, and for DSH, Cursor, OpenCode or Gemini CLI it is .agents/skills/step-gate/ at project root or under your home directory. ### Does step-gate need any runtime dependencies? The README states that copying is all that is needed, because the package ships with binaries for five platforms built in, covering windows-x64, linux-x64, linux-arm64, macos-x64 and macos-arm64, with zero runtime dependencies. The Python tools in the tools/ directory are written with the standard library only. ### How does step-gate stop an agent from completing a step it never saw? The next command pushes that step's full guide to the agent and writes an admission receipt at the same time, and a completion without that receipt is rejected. On top of that, flow.yaml declares artifact rules with file and non-empty validators, so the artifacts a step was supposed to produce must exist and be non-empty. ### What do the admin commands in step-gate require? The admin commands reset, fail and init require an operator token, and the state file is only read and written by the program. The launchers run.cmd and run.sh select the right platform binary and whitelist the commands available to the agent. ### What licence is the step-gate package released under? Apache-2.0, with the licence stated in the README and a LICENSE file in the repository, and the same licence text included in the package as skills/step-gate/LICENSE.txt. The repository publishes no GitHub releases and the last push was on 2026-09-05. ## Sources - [daixudk96-max/agent-skill-gate on GitHub](https://github.com/daixudk96-max/agent-skill-gate) - [Issues](https://github.com/daixudk96-max/agent-skill-gate/issues) - [License: Apache-2.0](https://github.com/daixudk96-max/agent-skill-gate/blob/main/LICENSE) - [README](https://github.com/daixudk96-max/agent-skill-gate/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daixudk96-max-agent-skill-gate