discover-remote-friendly

name	discover-remote-friendly
description	Enumerate companies in a domain that are genuinely remote-friendly to USER_LOCATION (not just "remote-OK" with US-only fine print). Writes to <WORKING_FOLDER>/domain-notes/remote-<domain-slug>.md. Honest negatives over hopeful positives.
disable-model-invocation	false
allowed-tools	Read, Write, WebSearch, WebFetch, Bash(mkdir *), Bash(test *)

Discover Remote-Friendly

Domain ∩ remote-friendly to USER_LOCATION. The bar: would this user, in their actual timezone clear the company's hiring filter today.

Inputs

$ARGUMENTS:

• Required: <domain> — the niche (free text).
• Optional: --location=<override> — defaults to USER_LOCATION from ${CAREER_DATA_DIR}/config.json.
• Optional: --n=<count> (default 20).
• Optional: --lens=<employer|client> — defaults employer. client mode looks for companies that buy remote services rather than employ remotely.
• Optional: --strict — only "global remote" / "anywhere"; exclude "remote within EMEA" unless EMEA covers the user.
• Optional: --refresh.

Examples

/career:discover remote-friendly "developer tools"
/career:discover remote-friendly "ai eval startups" --strict
/career:discover remote-friendly "policy research orgs" --lens=client

Procedure

1. Resolve config + paths

Read USER_LOCATION and WORKING_FOLDER from config. Output: ${WORKING_FOLDER}/domain-notes/remote-${domain-slug}.md.

2. Enumerate domain candidates

Same enumeration approach as discover-by-domain. Cap at ~2× target so the remote filter has headroom.

3. Test each candidate against USER_LOCATION

For each candidate, fetch:

• Live job postings (preferably engineering or comparable role) — look for explicit timezone language.
• Careers page "where we hire" / "remote policy".
• Public statements (LinkedIn, blog, YC profile).

Classify each as:

• friendly — explicit acceptance of the user's timezone/region in current postings.
• friendly-with-overlap — accepts globally but requires N hours overlap with US/EU. Note the overlap.
• region-locked — limited to a region that excludes the user.
• us-only — explicit US-only / US-payroll-only.
• unclear — no public signal.

--strict keeps only friendly.

4. Cross-reference outreach.md

Mark contact-status as in discover-by-domain.

5. Write the note

# Remote-friendly companies in {{domain}} (for {{location}})

> Domain: {{domain}}
> Location filter: {{location}}
> Strict: {{true|false}}
> Surveyed: {{date}}

## Companies — friendly

| name | website | evidence (live posting / page) | overlap req | contact-status | notes |
| --- | --- | --- | --- | --- | --- |

## Companies — friendly with overlap

(same columns)

## Region-locked / US-only — for the record

| name | reason |

## Honest unknowns

| name | what would resolve this |

## Sources

1. ...

6. Print summary

note: domain-notes/remote-<domain-slug>.md
friendly: <n>
friendly-with-overlap: <n>
unclear: <n>
ruled-out: <n>

next: /career:suggest companies --from=remote-<domain-slug>

Guardrails

• Bias toward honest negatives over hopeful positives. If a company says "remote-first" but every posting is "US only", classify as us-only, not friendly.
• Live postings beat marketing copy. If the careers page contradicts current job posts, trust the posts.
• Don't assume "remote" includes the user's timezone — verify or mark unclear.
• Mark inferred fields explicitly.

Failure modes

• No live postings + no public policy → mark unclear, do not classify as friendly.
• Postings contradict each other → note the contradiction; classify by the most recent posting.