diff --git a/shared/rules/general.md b/shared/rules/general.md
index 668d46b..5e34c51 100644
--- a/shared/rules/general.md
+++ b/shared/rules/general.md
@@ -21,14 +21,11 @@ Project instructions may specialize global defaults, but must not weaken securit
 
 ## Verification
 
-* Decide independently whether and how much verification the change needs. Use the smallest set of checks that provides sufficient confidence, based on changed behavior, affected callers, failure impact, reversibility, and remaining uncertainty.
-* A focused inspection can be sufficient for a small, low-risk change. Do not automatically run builds or tests, add tests, or request a separate review for every change.
-* When execution adds useful evidence, start with a targeted syntax/type check, affected project build, focused test, or manual check. Choose the check that can detect the likely failure; these are alternatives, not a mandatory sequence.
-* Expand to integration tests, a full application build, a wider test suite, or an independent review when cross-component effects, security or data-loss risks, failures, or unresolved uncertainty justify the cost. Change size alone does not determine risk.
-* Add or update tests when they protect meaningful changed behavior or a plausible regression. Avoid tests that only mirror implementation details or assert wording and formatting.
-* Stop once the relevant risks are covered. Repeat or broaden successful checks only after changes that affect their results, new failures, or new evidence of risk.
-* Explicit user requests and applicable project or CI requirements remain binding. Generic skill workflows requiring review, builds, tests, or test-first development for every change do not override this proportional approach; no permission is needed to skip unnecessary workflow steps.
-* Report the checks actually performed and material limitations concisely. Inspection is not a passing build or test run; do not claim evidence you did not obtain or hide unresolved failures.
+* Choose checks independently by behavior, callers, impact, reversibility, and uncertainty. Focused inspection can suffice; builds, tests, new tests, and separate reviews are not automatic.
+* Execute the cheapest check that detects the likely failure. Broaden for cross-component effects, security/data-loss risks, failures, or unresolved uncertainty. Small changes can still be risky.
+* Add tests for meaningful behavior or plausible regressions, not implementation details or wording. Stop when risks are covered; repeat only when changed evidence warrants it.
+* Explicit user/project/CI requirements remain binding. Generic skill mandates for review, builds, tests, or test-first work do not override proportional verification; skipping needless steps needs no permission.
+* Report checks and material gaps concisely. Distinguish inspection from execution; never claim unrun checks passed or hide failures.
 
 ## Documentation
 
diff --git a/shared/rules/refactoring.md b/shared/rules/refactoring.md
index fbec635..d9ec5e3 100644
--- a/shared/rules/refactoring.md
+++ b/shared/rules/refactoring.md
@@ -84,6 +84,7 @@
 
 ## Tests
 
+* Decide whether tests are needed using `general.md`'s Verification rules; this section governs tests that are selected, not a mandatory test run.
 * Existing relevant tests must continue to pass.
 * Update tests when internal structure changes make it necessary.
 * Do not delete valid tests merely because they fail after a refactoring.