TL;DR: Invoke the repo subcommand explicitly with a full git URL so trivy scans code instead of looking up an image. The error means trivy parsed your argument as an image reference and asked a registry about it. Pass the repository as an https git URL with the `trivy repo` subcommand, and authenticate if the repo is private.

```text
repository name not known to registry
```

1. Check the exact command you ran: confirm whether you used the `repo` subcommand or just `trivy` with the repo path. Expected: you find the subcommand missing or the argument in image form.
2. Re-run with the explicit subcommand and a full git URL, for example `trivy repo https://github.com/[org]/[repo]`. Expected: trivy clones the repo instead of querying a registry.
3. For private repos, authenticate first using your git host's documented method (credential helper or token-based clone URL). Expected: the clone succeeds without a 404.
4. Confirm the scan target in the output header. Expected: trivy reports scanning a repository and lists the lockfiles it found.
5. If you actually wanted an image scan, use the image subcommand with the full registry path instead. Expected: no more ambiguity about the target type.

## Use this when
- a trivy repo scan errors with a registry message
- trivy treats a repo path as an image reference
- you are scanning source code, not images
- an agent built the trivy command programmatically

## Not for this skill when
- the repo URL itself is wrong or unreachable
- authentication to the git host fails
- the scan runs but finds nothing (a scope problem)
- you genuinely want to scan a container image

## Variant phrasings
- trivy repository name not known
- trivy repo scan registry error
- trivy scanning git repo fails
- trivy repo unknown to registry

## Why it happens
Trivy's default target type is a container image. Without the `repo` subcommand, a repository argument gets parsed as an image reference and trivy asks the registry for a repository by that name, which does not exist - hence the registry-flavored error for a code-scanning intent.

## Edge cases
- monorepos with nested lockfiles scan fine but slowly - narrow the scope with scan options if needed
- the git URL must be cloneable from the scanner's network - SSH URLs need keys the CI runner may not have, so prefer https in automation
- `trivy repo` on a local path works too and avoids the clone entirely
- some wrappers pass the target positionally and drop the subcommand - check the constructed command, not just the intent

## Provenance

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