Finding Targets

List the full candidate set before filtering.

• Multi-repo — every repo in the org:

  bashCopy

  gh repo list bitwarden --no-archived --limit 1000 \
    --json name,defaultBranchRef,primaryLanguage,repositoryTopics

  Exclude archived repos unless the intent is explicitly about them. Treat the default branch from this listing as authoritative — never assume main.

• Monorepo — every project inside one clone. Enumerate by the marker that defines a project (the manifest or config file each project must have), e.g. git ls-files '**/<project-marker>', then derive each project’s directory from the match.

Signal types (the generic techniques)

1. File-existence probe — “targets that contain file X”

Fast first pass across the org, no clone:

Per-repo definitive check (200 = present, 404 = absent):

In a monorepo, the same signal is a glob: git ls-files '<glob>'.

2. Content match — “targets whose file contains string Y”

Use --filename / --extension / --language to narrow. Locally (monorepo, or after clone): grep -rl '<pattern>' <path>.

3. Dependency / manifest inspection — “targets that declare dependency Z”

Read the dependency manifest and test for the declaration rather than a loose text match — a substring can hit a comment or an unrelated field. Fetch the manifest, parse it, assert the key:

4. Topic / language filter — “targets in language L or tagged topic T”

Or filter the primaryLanguage / repositoryTopics fields from the enumeration listing.

Named cases map onto the signal types

These are one-line illustrations, not a menu — each is just a signal plugged into a technique above. Full narration of any of them lives in ../examples/.

• “repos that use npm” → signal: a package-lock.json is present → file-existence probe.
• “repos that run a given workflow” → signal: .github/workflows/<name>.yml is present → file-existence probe.
• “repos that carry a Claude config” → signal: .claude/settings.json is present → file-existence probe.
• “repos that depend on a given library” → signal: the dependency is declared in the manifest → manifest inspection.
• “projects in a monorepo of a given framework” → signal: the framework’s config marker exists in the project dir → file-existence probe (glob).

Trust, but re-verify

gh search code is the fast first pass, but it is not authoritative: it indexes only default branches, skips some repos, lags behind recent pushes, and is rate-limited. Treat its output as a candidate list. The same caution applies to gh search repos (signal-type 4): it is a rate-limited search endpoint that can miss repos relative to the authoritative gh repo list — prefer filtering the primaryLanguage / repositoryTopics fields of the enumeration listing, and treat any gh search repos result as a candidate to re-verify. The applicability filter is only confirmed when the recipe re-checks the signal in the freshly cloned target at execution time. A candidate whose signal is absent on clone is skipped-not-applicable — this is expected, not an error. This re-verification is the same instinct as the “spot-check the target list both ways” step in the SKILL.md self-check.