Offer the loop before starting it, and let a scheduled run answer for itself

skills/old-coder/SKILL.md

@@ -1,10 +1,46 @@
 ---
 name: old-coder
-description: Evidence-first development — surround the implementation with an executable spec and a gauntlet of constraints (tests, types, coverage, mutation) so line-by-line review becomes optional. Use when the user explicitly asks for high-assurance or evidence-first work ("reliable", "TDD", "prove it works", "I won't read the code"), or when the change touches high-stakes domains (money, auth, data loss, concurrency, public API). For routine changes where the user just wants normal tests, write good tests directly instead of invoking this loop.
+description: Evidence-first development — surround the implementation with an executable spec and a gauntlet of constraints (tests, types, coverage, mutation) so line-by-line review becomes optional. Use when the user explicitly asks for high-assurance or evidence-first work ("reliable", "TDD", "prove it works", "I won't read the code"). Also load it when the user did NOT ask but the change touches a high-stakes domain (money, auth, data loss, concurrency, public API) — in that case the first and only act is to OFFER the loop in one sentence and stop, so a wrong guess costs a sentence and no files. For routine changes where the user just wants normal tests, write good tests directly instead of invoking this loop.
 ---
 
 # Old Coder: Reliable Coding Under Constraint and Test
 
+## First: was this loop asked for?
+
+This loop is expensive. It starts with a spec, an approval, and a setup plan.
+That cost is correct when it was asked for. It is waste when what was wanted is
+a small fix.
+
+- **It was asked for.** The skill was named, or words like "reliable", "TDD",
+  "prove it works", or "I will not read the code" were used. **The asker does
+  not have to be a live human**: a scheduled wake, a cron job, a loop prompt, or
+  another agent's task description that names this skill is the ask, made in
+  advance by whoever configured it. Start at step 1 below, and do not re-offer
+  what has already been requested.
+- **Nobody asked, and you loaded this because the change looks high-stakes** —
+  money, auth, data loss, concurrency, a public API. Your first act is an OFFER,
+  and it is your only act. Write one or two sentences. Name the domain you saw.
+  Give two choices: the full loop, or a normal fix with good tests. Then stop
+  and wait.
+
+**Create nothing before the answer.** No spec file, no setup plan, no branch. A
+wrong guess must cost one sentence, not a document nobody wanted. This applies
+to the offer path only — once the loop has been asked for, step 1 starts
+immediately.
+
+**An offer needs someone to answer it.** On an autonomous or looped run with
+nobody to reply, do not stop with an offer into an empty room; that stalls the
+run and delivers nothing. Record the domain you saw and run the loop under the
+autonomous rules that already govern it — the spec is still written, spec
+approval is still `not obtained (autonomous run)`, and EVIDENCE still claims
+correspondingly lower confidence. OFFER-and-stop is for when a reply is possible.
+
+**This offer is not spec approval.** A yes here authorizes the loop only. The
+spec still needs its own approval at step 1.
+
+If they choose the normal fix, leave this skill. Write good tests directly. Do
+not run a partial version of the loop.
+
 The human will NOT read your implementation. Their confidence comes entirely from
 two artifacts you produce: (1) an **executable specification** they approve before
 you write code, and (2) an **evidence report** proving the code ran the gauntlet.