## TL;DR
The agent treats a template error like no result, so its planner schedules the same broken template again for every remaining target. Record a per-template failure keyed by the template file hash, stop scheduling that template after the first hard error, surface the template error as its own work item, and only retry it after the file changes.

```text
agent looped re-running the same nuclei template after it errored
```

## Use this when
- The run log shows the identical nuclei template failing with the same error for target after target.
- Overall scan progress stalls while the error count climbs.

## Not for this skill when
- The template errors on one unusual target only. That is target-specific behaviour to investigate, not a loop.
- The template was fixed mid-run. A hash-keyed guard already allows the changed file to run again.

## Steps
1. Confirm the loop from the log: count executions of the one template id and confirm the error text is identical each time. Verify: Verify: the count is greater than two with one repeated error.
2. Classify the error: a load or compile error can never succeed on later targets, while a timeout might; only hard errors earn an automatic stop. Verify: Verify: the error in the log is a hard template error, not a network symptom.
3. Add the failure record: key template failures by template id plus file hash, and have the scheduler check it before queueing that template. Verify: Verify: a new scheduling attempt for the unchanged template is refused with the recorded reason.
4. Raise the template fault as a separate fix item in the run, with the error and the template path, instead of burying it in scan logs. Verify: Verify: the run summary lists the broken template as a blocker for its check, not as a target result.
5. After the template is repaired, confirm its hash changed, clear nothing by hand, and let the scheduler run it once against one authorized target as a smoke test. Verify: Verify: the repaired template executes once cleanly before the full run resumes.

## Variant phrasings
### agent retries broken nuclei template every target
The per-target phrasing.
### template error treated as no result agent loop
The planner-logic phrasing.
### hash keyed template failure circuit breaker pentest agent
The guard-design phrasing.

Compatibility: Compatibility: any agent harness driving nuclei with per-template scheduling; hash keying needs only a file hash of the template.

## Why it happens
Schedulers retry what looks unfinished. A template error produces no findings file, which reads as unfinished, but unlike a network failure it is deterministic: the same file will error identically forever. Without a failure memory keyed to the file's content, the planner has no way to learn this, and the loop burns the engagement window while looking busy.

## Edge cases / pitfalls
- Rate-limit and target-side errors must not trip this breaker, or one throttled target silently removes a check from the whole engagement.
- The report must disclose that the check never ran; a stopped template is a coverage gap, not a pass.
- Cap total template executions per run as a backstop even for errors you failed to classify.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_syaDwY9RVMP-xVH8tY81Ig