/force-multiplier

Finding Targets

The engine stays generic; this is where it learns to find things. Discovery is keyed by signal type — the shape of evidence that marks a target as relevant — not by any specific change. Pick the technique that matches the signal, fill in the specifics, and you have an applicability filter.

The engine is target-system-agnostic — a target is any software system in the Bitwarden ecosystem that Claude can reach. The connection point available today is GitHub, so the enumeration and signal techniques below are grounded in gh ... --owner bitwarden; authentication is the already-configured gh session — never inject tokens. As other connection points become available to Claude, the same signal-type approach extends to them; discovery for other target systems (e.g. Atlassian) is not yet implemented.

Enumerate first

List the full candidate set before filtering.

• Multi-repo — every repo in the org:

  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:

gh search code --owner bitwarden --filename <name> --json repository --limit 1000

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

gh api repos/bitwarden/<repo>/contents/<path> --jq .sha

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

2. Content match — "targets whose file contains string Y"

gh search code --owner bitwarden '<query>' --json repository,path --limit 1000

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:

gh api repos/bitwarden/<repo>/contents/<manifest> \
  -H 'Accept: application/vnd.github.raw' | jq -e '<path-to-the-declaration>'

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

gh search repos --owner bitwarden --language <lang> --json name --limit 1000
gh search repos --owner bitwarden --topic <topic> --json name --limit 1000

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.