if err != nil {
          return nil, err
  }

    if err != nil {
        return nil, fmt.Errorf("could not parse file %s: %v", path, err)
    }

I've just created a live template for that in Go, which just puts my cursor in the wrap message to pass along.

Aw, hell no! That's a very easily detectable (anti)pattern! You can scan even a very large code base for that! As noted in other comments, you should be adding some contextual information at this point.

Contrast this with having too-much magic, where you might have absolutely no trace in code left. You can't usefully search a large code base for all such relevant blanks.

Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment.

I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced.

This is really insightful, thank you.

That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.