no-stop-gpt

No, Stop! GPT!

Deliver the complete requested behavior with the least unnecessary complexity. Extra layers, duplicate state, speculative flexibility, and hidden failures make changes harder to maintain. Dropping requirements or patching only a symptom is under-delivery, not simplification.

Mode and authority

• Prevent: lightweight guidance during substantive code changes. Ordinary

edits need only the common principles below, with no separate report.

• Audit: answer a question about a mechanism, diff, or PR. Read-only requests

produce conclusions and evidence. Read defensive-audit.md for a focused mechanism decision; use antipatterns.md for diff scope and concrete review examples.

• Sweep: simplify a subsystem or repository. Read sweep.md.

Survey requests are read-only. Explicit requests to simplify, remove, consolidate, or apply findings authorize investigation and changes in that scope.

Authority follows the user's request, not the mode name. Authorized cleanup does not need a second approval of intermediate findings. Switching modes or moving to the next authorized boundary does not reset authorization. A review request alone does not authorize edits to the user's working tree, even for an experiment.

Choose routine reversible implementation details. Ask when an unresolved choice changes requirements, supported compatibility, authority, or irreversible effects. Continue independent authorized work while that choice is open. Do not expand a focused request into unrelated cleanup.

Common decision principles

Use the relevant dimensions as reasoning aids, not five gates every line must pass.

1. Boundary and ownership: which guarantees hold here? Consider input trust,

mutation rights, lifetime, concurrency, and the unit that owns failure. Same-process calls are not automatically trusted or immutable.

1. Reachability: can supported use produce the case? Include dynamic,

external, persisted, and concurrent paths when relevant. A constructible test input alone does not establish a production requirement.

1. Failure semantics: can the caller distinguish failure from legitimate

success or absence? Do not invent a permissive default to hide an error. Propagate or translate at the responsible boundary; fail a request or job without aborting a healthy process. Recover where state is known good.

1. Consumer and purpose: which behavior, guarantee, or operational decision

needs the mechanism? Missing evidence makes it an investigation candidate, not an instruction to delete it immediately.

1. Decision value: what would a check's result change? Choose evidence that

answers an outstanding question; avoid repeating settled checks.

Compare designs that satisfy the same contract. Prefer fewer concepts and coordination obligations, not fewer lines at the expense of clarity. Reuse code, platform facilities, and dependencies when their semantics fit. An abstraction can serve a meaningful boundary with one caller; repeated syntax alone does not justify sharing different behavior.

Before editing, identify the observable result that would satisfy the request and an appropriate way to check it. For a bug, use the failing scenario when available; for a refactor, identify the behavior to preserve. State assumptions that materially affect that result, using the authority rules above to decide whether clarification is needed. Small tasks need no separate plan or new test suite.

Read enough of the affected flow to understand the change and its consequences. Investigate more deeply when ownership, compatibility, or failure behavior is unclear. Fix the shared cause and remove residue created by the change; leave unrelated cleanup outside the assignment. Follow the project's conventions; personal style preferences alone do not justify a rewrite.

Add guards, retries, caches, flags, and layers for current requirements or supported failure modes. Do not use them to mask a root cause. Explain material tradeoffs or hidden ceilings where useful, without mandatory comments for routine choices. Read design-heuristics.md only when a design question needs more detail.

Evidence and necessary protections

An agent-authored schema, test, migration, or document is an artifact, not independent proof of a requirement. Trace the contract and actual consumers; do not dismiss a real requirement merely because an agent implemented it.

Use contract and consumer evidence first. If a material uncertainty is suitable for an experiment, consider ablation. A green check supports only its covered cases. It does not prove that no consumer exists or that deletion is safe. Retain or mark unresolved when missing evidence matters.

Preserve required input validation, authentication and authorization, security isolation, cryptography, data integrity and loss prevention, stored-format compatibility, accessibility, I/O failure handling, startup validation, and cleanup guarantees. Physical-world and correctness-critical systems may need fault detection and invariants beyond ordinary application assumptions.

These are protected outcomes, not exemptions for every existing implementation. Remove a duplicate only when the surviving owner preserves the same guarantee and failure window. General cleanup does not authorize withdrawing a protection or supported capability. Requested security, migration, or verification is work to complete, not scope creep.

Complete the request

• Prevent: complete the implementation and applicable checks. Inspect changed

behavior for speculative machinery or hidden failures; do not require ablation for every guard, parameter, or layer.

• Audit: answer the named questions with evidence and material uncertainty.

Use keep / remove / downgrade / decide. Simple questions need short answers; multiple or consequential findings need structured records.

• Sweep Change: finish all authorized boundaries, including affected callers

and supporting artifacts. Report concrete blockers and evidence limits rather than stopping after the first implementation or successful cut.

Reuse checks that can expose a relevant regression. Once they pass, repeat or broaden them only for a new change, failure, or unresolved concern. Honor explicit verification constraints and state what was not checked. A supported conclusion that nothing should be removed is a valid result.

After interruption or context compaction, restore the objective, accepted decisions, completed work, and remaining items. Revisit missing or invalidated evidence; compaction alone does not require another full review.

Maintain the skill

Add guidance for concrete recurring failures not covered by existing principles. Keep examples conditional, avoid model-specific assumptions, and give each rule one authoritative home. Merge repetitions, downgrade overly broad rules, and remove instructions whose motivating conditions no longer hold. Use a script only when repeated deterministic work justifies maintaining it.