Do not parse a body on 204 No Content. Check the status code first: on a 204, treat the delete as successful with nothing to read, and only parse JSON when the status says a body is present. The crash is especially confusing because it throws after the delete already succeeded.

```text
docs listed a DELETE endpoint returning 200  -  the live API returns 204 with no body and the generated client crashed on .json()
```

## Steps

1. Find the delete handler in the generated client and confirm it parses the response body unconditionally - the equivalent of calling .json() on every response regardless of status.
   Expected: You can point at the unconditional parse call in the delete path.

2. Guard the parse on the status code: when the status is 204, return success immediately without reading the body. Parse JSON only for statuses that carry one.
   Expected: The delete path returns success on 204 with no body parse attempted.

3. Centralize response parsing so every endpoint gets the status-first treatment, not just DELETE. One shared parse function beats scattered guards.
   Expected: All response parsing flows through one place that checks status before touching the body.

4. Re-run the delete flow and confirm no crash, the delete reports success, and a follow-up read confirms the resource is gone.
   Expected: DELETE returns success on 204 with no crash, and other endpoints still parse their bodies normally.

## Use this when

- the client crashes after DELETE or any request that returns 204
- the docs say 200 with a body but the live API sends 204
- any endpoint where the response body may legitimately be absent

## Not for this skill when

- a 200 response carries malformed JSON - the body exists but is broken, a different bug
- DELETE returns 404 for a missing resource - handle not-found separately from no-content
- the request fails with 401 - that is auth, not response parsing

## Variant phrasings

### 204 no content json parse error
### DELETE returns 204 crash
### parse error on empty response
### no body response crash

## Why it happens

The agent generated the parse step from the docs' 200 example, where a body exists. But 204 means no content by definition, so any parse call throws - and it throws after the delete already succeeded on the server. The operation worked and the client reports failure, which sends debugging after the wrong half of the problem.

## Edge cases

- Some APIs return 200 with an empty body too - guard on body presence as well as status, not status alone
- HEAD requests never carry bodies, and 304 responses do not either - the shared parse function should know that
- Log the status code with every parse failure so the next bodiless response is obvious in one line
- After fixing DELETE, audit POST and PATCH paths: some APIs return 204 for updates as well

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7HV-FuWujZ4s4-d2EUoPEw