One 7,091-byte policy separates output from bookkeeping
The 7,091-byte SKILL.md asks an agent to classify each proposed action as semantic implementation, focused validation, or administrative bookkeeping. The agent should do the first two. It should skip the third unless the user requested it or the artifact belongs to the product. That is a narrow answer to a real failure mode: a coding agent sees stale metadata, treats it as broken output, and spends the session repairing its own records.
The rule becomes concrete around staged work. A missing receipt should not force a full pipeline replay. A changed producer should trigger only its dependency cone. File presence cannot prove that a capability works, so the agent must run the affected path and inspect behavior, counts, samples, conservation, and resource use. The four examples in examples/failure-modes.md are useful because each pairs a plausible agent excuse with the smaller action that would move the product forward.
The 7,091-byte policy keeps evidence and product integrity in scope
The 7,091-byte policy does not give agents permission to wave work through. It preserves checksums that users verify, signatures required by a format, revision identity, asserted tests, reproductions, and execution records that connect a command to an expected result. That distinction saves the idea. Without it, “skip bookkeeping” would excuse weak validation. Here, the agent still has to show that the output is sound; it simply cannot use a dashboard row as a substitute.
Some hard constraints deserve review before adoption. The skill says not to create or wait on filesystem locks and tells the agent to remove administrative-only gates from execution paths. Those instructions may fit one stalled batch pipeline and be wrong in a shared publisher where a lock prevents two writers. The single-writer invariant helps, but Markdown cannot inspect your concurrency model. Treat the file as source code: review each command-shaped instruction against local controls before installing it.
What happened when we ran it
Our 3-CPU, 8 GB Debian sandbox did not run commit 2d4dd7e. The repository is classified as Shell, but the lab found no supported ecosystem and no Dockerfile, leaving no declared install, build, or test path for the harness to execute. That is the complete result. There was no failed command or log tail to interpret, and we will not turn the absence of a runnable check into a claim that the skill works.
The 2026-09-16 sandbox was an unprivileged container with no secrets. That environment can measure a declared package workflow or Docker build, but this project is mostly Markdown plus a copy script. Its central claim concerns agent behavior, which would need a repeatable behavioral evaluation across controlled tasks and models. The repository does not provide one, so buyers have prose examples rather than measured evidence of fewer stalls or replays.
The 1,169-byte installer copies broadly and enforces nothing
The 1,169-byte install.sh looks for Claude Code, Codex, and shared Agent Skills roots under the current home directory. If a root's parent exists, it creates a forward-implementation-first directory and copies the policy plus both example files. Re-running the script overwrites those copies. There is no credential setup, daemon, or remote service, and a project-scoped copy is available for teams that do not want a user-wide rule.
Ease of copying is separate from reliable activation. The README states that a skill is a suggestion and the model decides whether to load it. It recommends putting the decision rule in an always-on rule or hook when the agent supports one, but this repository does not supply that integration. A team evaluating the skill should define a few stalled-pipeline scenarios, record the agent's decisions with and without the file, and keep it only if behavior changes without weakening safety checks.
Two commits and no release history make this an early policy
GitHub showed 169 stars, 4 forks, and 0 combined open issues and pull requests when we fetched the repository. The last push was 2026-08-31, two days after the repository was created, and there is no GitHub release. The 2d4dd7e commit did respond to feedback by moving scheduling policy out of the loaded skill and into an optional example. That edit shows judgment, though two commits are too little history to establish maintenance habits.
The best user is someone who can name a recurring failure before installation: perhaps an agent replayed a wide stage range because one receipt changed, or refused a valid manual stage because the orchestrator could not certify it. In that setting, this small policy gives the team plain language for separating evidence from ceremony. If you cannot point to such a failure, adding another instruction file gives the agent more text to reconcile without solving a measured problem.