## TL;DR
The agent re-runs the failed nuclei scan because the failure was never classified: a crash, a template error, and a dead target all look like "try again" to it. Capture the exit code and the last log lines, classify the failure, and only retry the classes that can actually succeed on a second attempt.

```text
(agent re-runs: nuclei -u YOUR_TARGET_HOST/ -t cves/ after exit code 1)
```

## Use this when
- The agent repeats the same nuclei command against the same authorized target after it already failed.
- The failure reason is visible in the log but the agent ignores it.

## Not for this skill when
- Nuclei itself errors on templates or config. Fix nuclei first with the nuclei error skills.
- Each retry uses different templates or flags. That is iteration, not a loop.

## Steps
1. Read the actual failure: pull the exit code and the last 20 log lines from the failed run. Verify: you can name the failure, template load error, target refused, or panic.
2. Classify it: retryable, like target timeout or rate limit, versus terminal, like bad template path, auth failure, or target gone. Verify: the classification is written into the run state.
3. Allow exactly one retry for retryable failures, with a backoff and a reduced template set. Verify: the retry differs from the original, fewer templates or a delay, so it is not a blind repeat.
4. For terminal failures, mark the scan failed with the reason and move the agent to the next target. Verify: no further nuclei processes launch for that target.
5. Escalate to the tester when the same target fails two different scan types in a row. Verify: the human sees the pattern, not just one tool's log.

## Variant phrasings
### agent retries failed nuclei scan endlessly
The loop phrasing.
### nuclei scan failed agent runs it again
The behavior phrasing.
### agent ignores nuclei error output
The log-blindness phrasing.

Compatibility: harness-level fix; nuclei 2.x/3.x underneath.

## Why it happens
Nuclei's exit codes are coarse and its logs are long, so agents that only check "did a result file appear" miss the failure entirely. No result file plus no failure record equals "not done yet" in the planner's world.

## Edge cases / pitfalls
- A retry with the identical full template set after a rate-limit failure just re-triggers the rate limit. The retry must be smaller or slower.
- Template auto-update failures look like scan failures; check whether the template update step is the thing actually breaking.
- Log the classification where the report builder can see it: "nuclei failed: target refused connections" is a finding about the target, not just an agent hiccup.
- One retry means one. If the retry fails the same way, the failure was terminal all along; update the classification.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_s6NeDuANa0s6JTS33Ttq0A