# Shipped agent skill still points at `basecamp/omarchy`, so agent duplicate searches silently return nothing

## What is wrong

The skill Omarchy ships at `default/agents/skills/omarchy/` (symlinked by `omarchy-provision-user` into `~/.claude/skills/omarchy`, `~/.agents/skills/omarchy`, and the codex/pi equivalents) still names the old repository in `contributing.md`:

```
Omarchy lives at https://github.com/basecamp/omarchy.
...
gh issue create --repo basecamp/omarchy --title "..." --body "..."
gh repo fork basecamp/omarchy --clone
```

The repository is now `omacom/omarchy`:

```console
$ gh api repos/basecamp/omarchy --jq .full_name
omacom/omarchy
```

## Why this is worse than a stale link

Most operations follow the rename, so the staleness is invisible in normal use. `gh issue view`, `gh issue list` and `gh api repos/...` all redirect correctly, and `gh issue create --repo basecamp/omarchy` works too. **Search does not follow renames**, and it fails in two different ways depending on how it is called:

```console
$ gh api -X GET search/issues -f q='repo:basecamp/omarchy is:issue quickshell'
{"message":"Validation Failed","errors":[{"message":"The listed users and repositories cannot be
searched either because the resources do not exist or you do not have permission to view them.",
"resource":"Search","field":"q","code":"invalid"}],"status":"422"}

$ gh api -X GET search/issues -f q='repo:omacom/omarchy is:issue quickshell'
342
```

The raw API at least errors. But the form an agent is most likely to reach for returns success with an empty list:

```console
$ gh issue list --repo basecamp/omarchy --state all --search "quickshell" --limit 5
                     # exit 0, no output, no error

$ gh issue view 7390 --repo basecamp/omarchy --json title
{"title":"omarchy update aborts after the Quattro upgrade: ..."}   # works fine
```

So an agent following `contributing.md` does its duplicate check before filing, is told there are zero matches, and reasonably concludes the bug is new. Direct issue access keeps working throughout, which removes the obvious signal that anything is misconfigured.

I hit exactly this while preparing #10117. Four duplicate searches came back empty and I only caught it because a control search on a term I knew existed came back empty too. There are in fact several related open issues, which that report now cross-references.

Given `contributing.md` explicitly instructs agents to file verified bugs, this makes the shipped skill a duplicate-issue generator on a repo that already carries ~2,900 open issues.

## Suggested fix

Replace `basecamp/omarchy` with `omacom/omarchy` throughout `default/agents/skills/omarchy/contributing.md` (four occurrences: the intro URL, the discussions URL, the `gh issue create` example, and the `gh repo fork` example).

Worth considering as well:

- A line in `contributing.md` telling the agent to sanity-check its duplicate search with a control query before trusting an empty result. That failure mode is not specific to this rename.
- A grep in CI for the old owner name across `default/agents/skills/` and the docs, so the next rename cannot leave this behind quietly.

## Version

Omarchy 4.0.2-1. `~/.claude/skills/omarchy` is a symlink to `/usr/share/omarchy/default/agents/skills/omarchy` and is byte-identical to the packaged copy, so this is not local drift.