Commit de00cb2
Harden skill-availability check: require two exact-form failures before noop (#133)
The openings sweep noop'd on its first real run on
elastic/docs-content despite the skill being available, because
the agent stochastically invoked the skill with a non-exact form
the first time:
11:33:22 ✗ skill(docs-page-opening-optimizer) Skill not found
11:33:27 ● noop "docs-page-opening-optimizer skill unavailable..."
11:33:33 ✓ skill(skill: docs-page-opening-optimizer) succeeded
The prompt's "abort with noop on skill failure" rule fired on the
first non-exact attempt, before the agent retried with the correct
`skill(skill: …)` form and got results. By the time the exact
invocation succeeded, the noop was already committed.
Frontmatter, applies-to, and style produced fix-issues fine in the
same orchestrator run. The difference: the frontmatter sweep
prompt explicitly tolerates partial skill failures ("if one fails,
report only the other"); applies-to and style happened to land on
the exact form first try. Openings was the unlucky one.
Lift the docs-review pattern (PRs #117/#118) where skill
availability is only declared after a confirmed exact-form
failure. Apply to the three sweeps that had the strict
abort-on-first-failure rule:
- openings (was hit by this in real run 25373751367)
- applies-to (would hit it next time the agent picks the wrong form)
- style (same)
Each now spells out the procedure: try the exact form, retry
once on failure, only noop after the second exact-form failure.
A single non-exact failure is not sufficient evidence.
The frontmatter prompt already had a softer fallback ("merge what
works, note any failure in Notes"); coherence and staleness use
different mechanisms (>50% MCP failure threshold and full-repo
deterministic respectively); typos doesn't import any skill.
None of those need this change.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent b45090a commit de00cb2
6 files changed
Lines changed: 75 additions & 39 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
205 | 205 | | |
206 | 206 | | |
207 | 207 | | |
208 | | - | |
| 208 | + | |
| 209 | + | |
| 210 | + | |
| 211 | + | |
| 212 | + | |
| 213 | + | |
| 214 | + | |
209 | 215 | | |
210 | 216 | | |
211 | 217 | | |
| |||
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
213 | 213 | | |
214 | 214 | | |
215 | 215 | | |
216 | | - | |
| 216 | + | |
| 217 | + | |
| 218 | + | |
| 219 | + | |
| 220 | + | |
| 221 | + | |
| 222 | + | |
217 | 223 | | |
218 | 224 | | |
219 | 225 | | |
| |||
0 commit comments