Offer the loop before starting it, and let a scheduled run answer for itself - #7
Offer the loop before starting it, and let a scheduled run answer for itself#7drmikecrowe wants to merge 1 commit into
Conversation
… 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) <noreply@anthropic.com>
|
The problem is real and both halves of the answer are right — I want this, but not at this size or in this position. The gap you found is genuine. The description says to load on a high-stakes heuristic even when nobody asked, and then says nothing about what to do next, so the loop auto-fires and a wrong guess costs a document nobody wanted. An offer that costs one sentence is the right shape. The second half is the part I would not have thought of. A gate that assumes a live human deadlocks every cron run, loop prompt and agent-to-agent task — and "a configured invocation naming this skill IS the ask, made in advance by whoever set it up" is exactly right. So is falling through to the autonomous rules already in step 1 rather than stopping with an offer into an empty room. Please keep both clauses. What I would like changedLength and position. As it stands this is 37 lines placed above the thesis paragraph, so the first thing any agent reads is a routing decision rather than what the skill is for. SKILL.md also just came through a compression pass (the verification protocol was moved to a reference precisely to keep the main file readable), and this would put a sixth of the file in front of the opening argument. Could you cut it to roughly 8-10 lines and place it immediately after the thesis paragraph? Concretely, what I think has to survive:
The supporting argument for each can go; the rules carry themselves. Keep the description change as-is. The trigger contract belongs in frontmatter and yours is clearer than what is there now. One flag rather than a request: this is the only PR in the series that changes when the skill fires, which makes it a positioning decision rather than a correctness fix. It is going to the repo owner as that, not as a nit. I expect it to land — I want to be explicit that it is being decided rather than waved through. Related: this belongs to the same family as #6 and the isolation half of #9 — see my note on #6. A gate that cannot be answered and silently proceeds anyway is another mechanism reporting success while doing nothing, which is why the autonomous fallthrough clause matters as much as the offer itself. |
2 participants
Two related gaps at the front door of the skill.
The trigger has no cheap exit
The description already says to load this skill when the change touches a high-stakes domain even though the user did not ask. Nothing says what to do next — so the loop auto-fires: a spec, a setup plan, an approval request.
In practice that means a wrong guess costs a document nobody wanted. The auto path now opens with a one-sentence offer and stops: name the domain you saw, give two choices (full loop, or a normal fix with good tests), wait. The explicit path is unchanged, and a yes to the offer authorizes the loop only — the spec still needs its own approval.
An offer needs an addressee
Once an offer gate exists, a skill woken by cron, a loop prompt, or another agent's task has nobody to answer it, and a strict reading of "did the human ask?" stalls the run and delivers nothing.
So, two clauses:
not obtained (autonomous run), EVIDENCE still claiming correspondingly lower confidence.OFFER-and-stop is for when a reply is actually possible.This second half 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.
+37/-1, all in
SKILL.md(new opening section, plus the description sentence that now says what the auto-trigger should do).Part of a series from a fork that has been running this skill daily (drmikecrowe/old-coder). Independent of the other PRs. Draft so you can take it in any order, or none.
🤖 Generated with Claude Code