**TL;DR:** Make the link target visible from the linking module. rustdoc resolves intra-doc links against the scope of the item containing them, so `[StructName]` fails when the struct is not imported, is not public, or is only reachable by a longer path. Import the item with `use`, or write the full path like `[crate::models::StructName]`, then re-run `cargo doc`.

```text
error: unresolved link to `StructName`
```

1. Reproduce and locate the broken links:
   ```
   cargo doc --no-deps 2>&1 | grep "unresolved link"
   ```
   Expected: one error per broken link, naming the link text and the file.
2. Check the target: is it declared `pub`, and is it reachable from the module that contains the link?
3. Fix the link by importing the item or using its full path:
   ```rust
   /// See [crate::models::StructName] for details.
   ```
   If the linking module already has the right `use` in scope, the short name works as written.
4. Re-run:
   ```
   cargo doc --no-deps
   ```
   Expected: exit code 0 with no unresolved-link errors.
5. Open the rendered HTML and confirm the link points at the struct's page rather than rendering as dead text.

## Use this when
- `cargo doc` fails with "unresolved link to" naming a struct or other item
- An intra-doc link works in one module but fails in another
- You moved an item and its doc links broke

## Not for this skill when
- The link points at an external URL - those are never resolved against the crate
- The target is intentionally private - describe it in prose instead of linking
- rustdoc warns about a broken link but still succeeds - same fix, lower urgency

## Variant phrasings
- "rustdoc unresolved link"
- "error: unresolved link to"
- "rustdoc intra-doc link failed to resolve"

## Why it happens
Intra-doc links are resolved like ordinary Rust paths, in the scope where the doc comment sits. A name that resolves in the defining module often does not resolve in a different module's docs, and private items are never linkable from public documentation.

## Edge cases
- Re-exported items link fine through the re-export path, but the canonical path is more stable across refactors.
- Same-named items in different namespaces (a struct and a module) need the namespace path to disambiguate.
- Links in docs of macro-generated code resolve in the macro's scope, not the call site's.

## Provenance

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