Here is a scenario almost every developer reading this has lived through over the past year.
It is 11:30 PM. You are working on a feature, like ad...
For further actions, you may consider blocking this person and/or reporting abuse
The mandatory pause rule is the part I would steal, because it maps exactly onto what broke my first serious attempt at agent-driven development: I let an agent loose on a billing service refactor with a long prompt and came back to a diff that had renamed half the domain types, migrated two tables nobody asked about, and passed its own tests by rewriting the assertions. What actually fixed it for me was cruder than Pólya — I started forcing the agent to write the plan to a PLAN.md file and would not let it touch src/ until I had read it. That manual gate caught a wrong turn on roughly every second task, which tells me the pause is not overhead, it is the whole mechanism. One thing I wonder about: the pause here is human-in-the-loop by design, but have you tried automating the review side — say, a second agent pass that scores the plan against the stated constraints before it ever reaches you?
"Passed its own tests by rewriting the assertions" made me wince because I have been burned by that exact move. Watching an agent calmly delete a failing
expect()or slap an@ts-ignoreon a broken type just to report "All tests green!" is infuriating. That exact trauma is why we added the Floor-Guard Anti-Cheat rules in/to-codeto explicitly forbid weakening assertions, using.skip(), or lowering coverage thresholds.Also, I love how you phrased that: "the pause is not overhead, it is the whole mechanism." I might have to frame that quote.
On your question about automating the review pass with a second agent before it reaches the human: yes! That is the exact role of
/to-clarifyin our pipeline.Before you ever spend human brainpower reviewing a spec or plan at the Pause Rule, you can run
/to-clarify @docs/plan/my-plan.md(or on the spec). It spins up a separate adversarial auditor persona that didn't author the document, checks it againstdocs/ARCHITECTURE.mdand five sanity axes (sad paths, scope boundaries, hidden assumptions), and forces a fix pass if the score is below 80. It catches the obvious blind spots automatically so your manual review at the Pause Rule can focus purely on high-level design calls.adversarial auditor before the human review, that ordering makes sense.
Your pause rule matches what I see daily, and I'd add one wrinkle. A single gate is not enough. The agent stops, I approve the plan, then it runs every tracer bullet straight through even when the first bullet invalidates an assumption the third depends on. I get better results gating at each bullet boundary, or whenever an assumption breaks mid-flight. On the readiness score, numbers gave me false precision. My agent would happily self-score 85 to proceed. Forcing it to list every unresolved unknown, then either resolve it or explicitly accept the risk, worked better. For your closing question, a short rules file beats re-pasting constraints per chat. Re-pasted prompts drift, the file does not.
You hit on three things we learned the hard way while dogfooding this workflow.
First, on gating per tracer bullet: I completely agree that a single upfront gate isn't enough when Bullet 1 uncovers something gnarly in the existing codebase that invalidates Bullet 3. That's actually why
/to-codedefaults to Slice-Gated Mode. By default, it only executes one vertical tracer bullet, runs the task tests (check:task), creates an atomic commit, and stops for review before moving to the next slice. Even if someone explicitly runs/to-code autofor end-to-end execution, we baked in four circuit breakers that force the agent to halt and emit aCONFUSION:orMISSING REQUIREMENT:block the moment actual code contradicts an assumption in the spec.Second, on the Readiness Score: left to its own devices, an LLM will happily grade its own homework at 85/100 just to keep moving. To prevent that false precision in
/to-clarify, we force the agent to extract and list every unresolved[ASSUMPTION-XXX]tag first, paired with a hard Critical Flaw Veto: if even a single blocking ambiguity or architectural contradiction remains open, the score is capped at 79/100 regardless of how well the rest of the spec is written.And 100% with you on keeping rules in a versioned file rather than re-pasting prompts. Prompt drift across long chats is real.
The "Mandatory Pause Rule" is the MVP of this entire framework. Most AI agent workflows fail because they treat the LLM's context window like a command line; you type, it executes. Forcing the agent to generate a plan and then halting execution until a specific human approval string is typed is exactly the kind of metacognitive friction we need.
I'm curious how you enforce that pause technically. Is it just a strong system prompt instruction, or do you have a hard external gate (like a pre-commit hook or a required file check) that physically blocks the /to-code command if the plan file hasn't been updated? Because LLMs have a bad habit of ignoring "do not write code yet" instructions if they think the user already provided enough context.
I also really appreciate the /to-quick-fix escape hatch. Most "strict SDLC" toolkits fail because they force a 5-step PRD process for a one-line CSS fix, causing developers to abandon the tool entirely. Giving the agent the judgment to know when to be pedantic (infrastructure) versus pragmatic (styling) is a great design choice.
Looking forward to trying this out in Cursor. As for the wildest mess, I had an agent once try to fix a memory leak by instantiating a new Redis connection on every single HTTP request. Reminded me of your example!
Fixing a memory leak by instantiating
new Redis()inside every HTTP request is proof that all LLMs were trained on the exact same cursed Stack Overflow threads! 😄To answer your question on how the pause is enforced technically: if you put "plan first, wait for approval, then code" inside a single monolithic system prompt, LLMs will eventually ignore the stop sign whenever they feel confident enough.
We solved that by splitting the workflow into isolated phase skills combined with a pre-flight artifact check:
/to-plan, the agent is loaded strictly with the Tactical Planner persona. Its file-writing scope is restricted exclusively todocs/plan/{slug}-plan.md, it has zero code-implementation instructions in context, and its final step is a hard turn termination./to-code: Writing production code lives in a separate skill (/to-code). When invoked, its first step verifies that an approveddocs/plan/{slug}-plan.mdexists and explicitly rejects hedged answers (like "looks okay" or "I guess") as unapproved.That said, pairing this with a physical
PreToolUsehook (like in Claude Code or Cursor hooks) that blocks file writes tosrc/unless the plan file carries an approved status header is a great idea for an extra hardware-level lock. Hope you enjoy testing it out in Cursor!This is an incredibly solid architecture. The opening joke about "cursed Stack Overflow threads" is painfully accurate—it feels like every model has an inexplicable urge to instantiate a new Redis or MongoDB client inside a route handler if you don't stop it.
Your solution is basically a masterclass in defensive agent design:
Skill-Level Separation (Context Isolation): This is the key. By stripping the coding instructions out of the /to-plan context, you're preventing the model from getting "eager." If it doesn't have the tools or the prompt to write code, it can't write code.
Pre-Flight Artifact Check (State Validation): Rejecting hedged answers like "looks okay" is brilliant. Agents are naturally sycophantic and will try to bypass gates if they think it'll please the user. Forcing a strict approval state is exactly how you build deterministic pipelines.
The PreToolUse Hook (Hardware Lock): This is the ultimate fail-safe. As you said, an LLM can eventually rationalize its way out of a system prompt, but it cannot rationalize its way past a system-level hook that physically intercepts the file write.
Combining the prompt-level isolation with the system-level hook is the exact blueprint for moving agents from "fun demos" to "production software."
Hope the Cursor testing goes well! Let me know how the hardware-level lock performs when the agent gets extra "creative."
The Mandatory Pause Rule is the part I'd watch if you ever wire this to anything external that reacts on "the agent stopped." I build CatCode (a desktop pet that reacts on Claude Code's Stop hook), and from outside, your deliberate pause-for-approval looks identical to a genuine finish — Stop just means control came back, not that the task is actually done. Not an argument against the gate, just a reminder that any tooling layered on Stop (celebrations, notifications, chained hooks) needs its own way to tell "paused for you" from "done" — the same ambiguity your "hesitation before calculating" step creates for anything watching from the hook side.
Disclosure: I'm the author of CatCode.
That is a fascinating edge case I hadn't considered from the external hook side, especially for something like CatCode!
You're completely right: at the runner level, a
Stopevent just signals that the turn ended and control returned to the user, regardless of whether the agent finished the whole job or halted at a human gate.In Pólya SDLC, there are two deterministic signals on disk and stdout that an external hook script can inspect to tell the two states apart:
/to-planhalts at the gate, it explicitly emits the🛑 MANDATORY GATE: THE PAUSE RULEbanner at the end of its output.docs/plan/: While a feature is paused or mid-flight,docs/plan/{slug}-plan.mdstill contains unchecked tracer bullets (- [ ]). Once all slices are genuinely done and verified, every task checkbox is marked- [x].If you ever want CatCode to distinguish between "waiting for your sign-off" (maybe the cat looks expectant?) versus "all tasks shipped" (celebration mode), grepping the active plan file for remaining
- [ ]items onStopwould be a super clean way to do it.the SSE versus WebSockets question in your list is the one i see agents skip every time. they pick the heavier option because it is the more common pattern in training data, then you inherit the reconnect logic and the sticky sessions. we started forcing a plan step where the agent has to list existing entities and name one alternative it rejected, and diffs got a lot smaller. how are you enforcing the pause, a prompt rule or a hard gate before any file write?
You nailed why agents always reach for WebSockets over SSE. Because WebSockets dominate tutorial repositories in the training data, the model defaults to the most statistically popular pattern rather than the simplest fit for unidirectional data flow, and suddenly you're maintaining sticky sessions and custom ping-pong timers for no reason.
I really like your team's rule of forcing the agent to list existing entities and explicitly name one rejected alternative. Making an LLM articulate why an option was rejected forces comparative reasoning instead of greedy first-choice selection (which is the exact mechanic we tried to capture in
/to-grill-me).On how we enforce the pause: we do it by decoupling planning and coding into separate slash-command skills rather than relying on a single prompt rule.
/to-planis only permitted to write todocs/plan/and must terminate its turn immediately after staging the markdown file./to-codeis a separate invocation that runs a pre-flight check for the plan artifact and requires explicit human sign-off before touching application files, while the rootAGENTS.mdrouter prevents raw feature prompts from jumping straight into/to-code.