RE-CUT: Offer the loop before starting it, and let a scheduled run answer for itself - #7
RE-CUT: Offer the loop before starting it, and let a scheduled run answer for itself#7drmikecrowe wants to merge 1 commit into
Conversation
|
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. |
8daa9c8 to
260ed1e
Compare
|
Re-cut per your review. The description at the top of this PR is the original and no longer matches the diff — this comment is what the PR now contains. Cut and moved. The opening section is 37 lines → 12, nine of them the rules themselves, and it now sits immediately after the thesis paragraph rather than above it, so the first thing an agent reads is still what the skill is for. All the supporting argument is gone; the five rules you named are the whole section. The five rules, in order:
What this does when it is broken. It is a routing rule with no checker, so an agent that ignores it starts the loop anyway and the original harm is unchanged — a document nobody wanted. What the rule can get wrong is the addressee test, and it fails asymmetrically, which is the part worth knowing:
Only the second leaves a trace. That asymmetry is the argument for writing the fallthrough as the default rather than the exception — the failure mode that reports nothing is the one to design away, and it is also why I would not want this rule to grow a mechanism that can silently decide "no reply is possible" without saying so. One addition beyond "keep the description as-is" — flagging it rather than slipping it in. You said to keep the frontmatter description as it stood, and I have, with one clause added:
Without it the description promises an offer-and-stop that the body then tells you not to perform on an autonomous run, and a description contradicting the body is the same defect class you flagged on #6. It is the one clause of the fork's later rewrite I think belongs here; the rest of that rewrite (isolation language, "never pushes", extra trigger domains) is deliberately not in this diff. Strike the clause if you would rather the description stay exactly as you accepted it — the body still carries the rule. Scope: one file, |
drmikecrowe
changed the title
|
@AmazingAng -- Review this reworked instruction please |
|
The body is right and I want it. One change first, in the frontmatter rather than the prose. The description is where this PR is expensive. It goes 557 → 817 characters, +47%. That is a different cost from the 13 lines in Two of the added clauses are argument rather than instruction, and both already exist in the body you wrote:
Cut those and the trigger contract is unchanged: load on the heuristic, offer, stop. Roughly 650 characters, no instruction lost. Keep the rest of the description change — it is clearer than what is there now, which was the original point. The body itself I would not touch. Bullet 4 restating step 1's autonomous rule is duplication I am happy to pay for: it makes the section answerable without scrolling to step 1, and it is the clause a scheduled run depends on. Two things worth telling you, since neither was true when I wrote the 08-14 review: This got more valuable while it sat. #9 is merged ( Push the trimmed description and I will merge. |
… itself The description says to load this skill on a high-stakes heuristic even when the user did not ask, and then says nothing about what to do next -- so the loop auto-fires and a wrong guess costs a spec, a setup plan and an approval request that nobody wanted. An offer costing one sentence is the right shape. Five rules, nine lines, placed after the thesis paragraph so the first thing an agent reads is still what the skill is for rather than a routing decision: offer and stop when nobody asked; create nothing before the answer; a configured invocation naming this skill is itself the ask; never stall when there is nobody to answer; and the offer is not spec approval. The fourth rule is the one that is easy to leave out. A gate that assumes a live human deadlocks every cron run, loop prompt and agent-to-agent task, and a gate that cannot be answered and proceeds anyway is another mechanism reporting success while doing nothing. So an unanswerable offer falls through to the autonomous rules already in step 1. The description gains the trigger contract and nothing else: load on the heuristic, offer, stop. It goes 557 to 661 characters. Two earlier candidate clauses are deliberately absent because both were argument rather than instruction, and both already exist in the body -- "a wrong guess costs a sentence and no files" is the justification for "create nothing before the answer", and the autonomous-run qualifier is bullet four nearly verbatim. The description is paid on every task, so it carries the contract and the body carries the reasoning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
260ed1e to
5a9df4e
Compare
|
Trimmed and pushed. Both clauses you named are gone; the body is untouched. Description: 817 → 661 characters. Against the 557 it started at, the trigger contract now costs +104 rather than +260. Removed exactly the two you identified, and for the reason you gave — each was argument, and each already exists in the body:
What is left is instruction only: load on the heuristic, offer in one sentence, stop. The framing you gave for why is the part I had wrong and want to record, since it generalises past this PR — the body is paid when the skill fires, the description on every task. A clause that repeats the body is cheap in one place and expensive in the other, and I was pricing both the same. Rebased onto On composition with On #9 and the hash divergence: |
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