Stop That Shit vs AGENTS.md: Skill, Plugin, and Task Boundaries

When an agent does too much, the obvious fix is another rule.

Avoid overengineering.
Make the smallest change.
Ask before doing unrequested work.
Do not add unnecessary abstractions.

The next task still expands, so the rules grow: do not create hashes casually, do not add compatibility layers by default, do not run the full suite automatically, and do not turn internal caution into a wall of disclaimers.

Eventually, the AGENTS.md file that prevents overengineering begins to overengineer itself.

The reminders are not wrong. The problem is that “necessary,” “smallest,” and “casually” still require interpretation. If the agent can construct a plausible future, it can keep proving that the extra work is justified.

Replace vague constraints with checkable task modes

When I built Stop That Shit, I did not start with a longer list of permanent prohibitions. I separated task entrypoints into modes.

$stop-that-shit review -- Review this diff. Report findings; do not edit.
$stop-that-shit change -- Fix the failing configuration test.

review, answer, and monitor are non-mutating by default. change authorizes modification. The distinction looks simple, but it is much clearer than “try not to edit unnecessarily”: an action is either inside current authority or it is not.

Additional work with ambiguous semantics goes through the Stop Ladder:

Did the user request it?
Is it necessary to complete the current result?
What reachable code, data, deployment state, or acceptance proves that need?
Where would the current task fail if we omitted it?

The two parts solve different problems. The task mode defines authority. The Stop Ladder decides which consequences are necessary.

The Skill and Guard should not pretend to do the same job

The Stop That Shit Skill is the semantic layer.

It tells the agent that review does not imply mutation authority; a hypothetical future does not justify a dependency, migration, compatibility layer, or abstraction; and genuinely affected callers, fixtures, and tests still belong in the result.

The Skill is advisory guidance. It can influence model judgment, but it cannot guarantee model behavior.

The Guard is the action layer. When the Host supplies a supported before-action event, the Guard can inspect several boundaries with sufficiently explicit inputs:

file mutation under review, answer, or monitor;
an unapproved dependency addition;
a subagent count above the declared budget;
an identifiable new hash action;
a write outside an explicit file lock.

The Guard should not pretend to understand every semantic choice. Seeing cache, migration, or retry does not tell it whether the action has a real consumer. That decision still belongs to reachable code, data, and acceptance.

This boundary matters. If the Hook tries to infer every engineering intention, it becomes another complex, difficult-to-calibrate agent.

Pin the public release

The current public release is 0.1.0 and requires Node.js 18 or newer. Pin the Codex marketplace install to that version:

codex plugin marketplace add lennney/stop-that-shit --ref 0.1.0
codex plugin add stop-that-shit@stop-that-shit

The --ref 0.1.0 pin has one practical purpose: you inspect and trust a fixed release snapshot rather than a changing main branch.

Restart Codex after installation. In a fresh CLI TUI, enter /hooks and inspect two events:

UserPromptSubmit reads the $stop-that-shit ... task mode and boundaries.
PreToolUse checks authority before a covered action runs.

Codex records trust against the Hook definition. Review it again when an update changes that definition. Do not bypass Hook trust merely to save a step.

Use the 0.1.0 INSTALL.md for complete Host-specific setup. Claude Code, OpenCode, and Hermes Agent CLI share the task-boundary core but have different install, event, and restart lifecycles.

Run a small smoke before evaluating model behavior

The first post-install step should not be a large, paid comparison. Use a disposable repository to check contract switching.

Start with read-only review:

$stop-that-shit review -- Review this repository. Report findings; do not edit.

Attempt a covered write. The Guard should return a denial. Then switch explicitly:

$stop-that-shit change -- Create scratch/sts-smoke.txt containing pass.

The narrow write should proceed.

This smoke answers two questions: whether the plugin is connected and whether authority can switch from read-only to mutation. It does not prove that the model is generally more obedient or that every Host action is covered.

Add narrower boundaries only after they are known

Stop That Shit supports stricter authority, but every task does not need every option.

$stop-that-shit lock change files=src/config.cjs|test/config.test.cjs -- Fix this behavior.
$stop-that-shit change deps=allow -- Add the parser dependency I requested.
$stop-that-shit change hash=allow -- Generate the release checksum I requested.
$stop-that-shit change agents=1 -- Use one independent testing subagent.

Use files= only when the complete boundary is already known. If a shared interface change may reach unknown callers, inspect the call chain first. An invented file lock can produce a more incomplete result than no lock.

hash=allow is not a permanent bypass. It says the current task authorizes a hash because, for example, a release verifier consumes the checksum. The next task does not inherit that justification automatically.

Stop That Shit limitations: a denial is not the final Host effect

The default post-install state is OBSERVING / unconfirmed. The Guard can check and record covered actions, but it does not infer authority or return denial. Explicit review, answer, monitor, or change activates the ARMED state.

These read-only commands inspect state and events:

$stop-that-shit status
$stop-that-shit runtime
$stop-that-shit explain evt_...
$stop-that-shit label evt_... correct|incorrect|inconclusive

The Runtime stores metadata only. permission_deny_returned means that the Guard returned a denial response. It does not prove that the final Host action was never executed, so public records keep the Host effect as unobserved.

This is not generic defensive wording. It changes how the evidence must be interpreted: a Hook decision, final Host effect, and model behavior are three different observations.

A short rule should make the task easier to finish

Good agent guidance does not attempt to enumerate every bad outcome. It gives the task a way to stop.

Declare whether the task is review or change. Ask whether additional work has a current consumer, reachable evidence, and an acceptance consequence. Let the Guard block only the actions it can identify clearly; leave semantic judgment to the Skill and repository facts.

Then AGENTS.md no longer needs to become an encyclopedia of overengineering.