From 8daa9c8086a19bd53d56a305e63055fa20a0ad4c Mon Sep 17 00:00:00 2001 From: Mike Crowe Date: Wed, 12 Aug 2026 08:40:56 -0400 Subject: [PATCH] Offer the loop before starting it, and let a scheduled run answer for itself Two related gaps at the front door. Trigger. The description already says to load this skill when the change looks high-stakes even though the user did not ask. Nothing said what to do next, so the loop auto-fires: a spec, a setup plan, an approval request. There is no cheap exit, and a wrong guess costs a document nobody wanted. The auto path now opens with a one-sentence offer and stops. The explicit path is unchanged, and a yes to the offer authorizes the loop only -- the spec still needs its own approval. Autonomous runs. Once an offer gate exists, it needs an addressee. A skill woken by cron, a loop prompt, or another agent's task has no human to answer, and a strict reading of "did the human ask?" stalls the wake and delivers nothing. So: a configured invocation that names this skill IS the ask, made in advance by whoever set it up; and where no reply is possible, record the domain and run the loop under the autonomous rules already in step 1, rather than stopping into an empty room. This came out of running the skill on a schedule, where the gate is the difference between a run that produces evidence and a run that produces one sentence nobody reads. Co-Authored-By: Claude Opus 5 (1M context) --- skills/old-coder/SKILL.md | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/skills/old-coder/SKILL.md b/skills/old-coder/SKILL.md index 966fc6e..948a183 100644 --- a/skills/old-coder/SKILL.md +++ b/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.