/dev-scan

name: dev-scan
description: Collect diverse opinions on technical topics from developer communities. Use for "developer reactions", "community opinions" requests. Aggregates Reddit, HN, Dev.to, Lobsters, ProductHunt, etc.
version: 3.1.0

Dev Opinions Scan

Collect and synthesize diverse opinions on specific topics from multiple developer communities.

Purpose

Quickly understand **diverse perspectives** on technical topics:

• Distribution of pros/cons
• Practitioner experiences
• Hidden concerns or advantages
• Unique or notable perspectives

Runtime Surface

Claude Code

• Use the vendor scripts, `WebSearch` fallback, and hook-provided session ID as

described below.

• Claude Code may use multiple Bash calls, but shell-level parallelism must

happen inside one Bash invocation with `&` and `wait`.

Codex

• Use Bash-first vendor scripts. Do not add Hoyeon MCP for v1.
• If no hook-provided session ID exists, generate one with

`date +%Y%m%d-%H%M%S` and store run artifacts under `$HOME/.hoyeon/codex-$RUN_ID/tmp/`.

• Prefer `node skills/dev-scan/vendor/chromux-search/web-search.mjs` and the

bundled Python API scripts before using generic web search fallback.

• Treat ProductHunt as optional when `PRODUCT_HUNT_TOKEN` is missing.
• If dispatching internal research helpers, use Codex adapters when installed:

`hoyeon-external-researcher`, `hoyeon-docs-researcher`, or `hoyeon-browser-explorer`.

Data Sources

| Platform | Method | |----------|--------| | Reddit | Vendored web-search.mjs (`chromux`) — Google `site:reddit.com` + enrichment (post body, comments, score) | | X (Twitter) | Vendored web-search.mjs (`chromux`) — Google `site:x.com` + enrichment (tweets, likes, replies) | | Hacker News | Vendored hn-search.py (`python3`) — Algolia API, no key needed | | Dev.to | Vendored web-search.mjs (`chromux`) — Google `site:dev.to` + enrichment (article, comments) | | Lobsters | Vendored web-search.mjs (`chromux`) — Google `site:lobste.rs` + enrichment (article, comments) | | Threads | Vendored web-search.mjs (`chromux`) — Google `site:threads.net` + enrichment (posts, replies, likes) | | ProductHunt | Vendored ph-search.py (`python3`) — GraphQL API, requires `PRODUCT_HUNT_TOKEN` env var |

Execution

Step 0: Dependency Check

Run all checks in a **single Bash call** using shell backgrounding (`&` + `wait`). Claude Code executes Bash calls sequentially — multiple Bash tool calls do NOT run in parallel. The only way to parallelize is within one shell invocation.

mkdir -p /tmp/dev-scan-$$

# Kill existing chromux instance (may be non-headless) and relaunch in headless mode
chromux kill 2>/dev/null || true
chromux launch default --headless 2>/dev/null || true

node skills/dev-scan/vendor/chromux-search/web-search.mjs --check > /tmp/dev-scan-$$/web.txt 2>&1 &
python3 skills/dev-scan/vendor/hn-search/hn-search.py --check > /tmp/dev-scan-$$/hn.txt 2>&1 &
python3 skills/dev-scan/vendor/ph-search/ph-search.py --check > /tmp/dev-scan-$$/ph.txt 2>&1 &
wait
echo "=== Web (chromux) ===" && cat /tmp/dev-scan-$$/web.txt
echo "=== HN ===" && cat /tmp/dev-scan-$$/hn.txt
echo "=== ProductHunt ===" && cat /tmp/dev-scan-$$/ph.txt
rm -rf /tmp/dev-scan-$$

| Result | Action | |--------|--------| | `web-search --check` → `available: true` | chromux available — Reddit, X, Dev.to, Lobsters all use Google `site:` + enrichment | | `web-search --check` → `available: false` | Fall back to WebSearch tool for all Google-based sources | | `hn-search --check` → `available: true` | Hacker News source available | | `hn-search --check` → `available: false` | Fall back to WebSearch for HN | | `ph-search --check` → `available: true` | ProductHunt source available | | `ph-search --check` → `available: false` | Skip ProductHunt (token not set or invalid) |

Report available sources before proceeding. Minimum 1 source required.

Step 1: Query Planning

> **Note**: Step 0 (dependency check) and Step 1 (query planning) are independent — run Step 0 bash commands and perform Step 1 reasoning in the same message to save a round-trip.

1-1. Parse Request

Extract structured components from user request:

• **topic**: Main subject
• **entities**: Key product/technology names
• **type**: `comparison` | `opinion` | `technology` | `event`

Examples:

• "Developer reactions to React 19" → topic: `React 19`, entities: [`React 19`], type: `opinion`
• "Community opinions on Bun vs Deno" → topic: `Bun vs Deno`, entities: [`Bun`, `Deno`], type: `comparison`
• "What happened with Redis license" → topic: `Redis license`, entities: [`Redis`], type: `event`

1-2. Query Decomposition

User requests are often complex or conversational. Before generating platform-specific queries, decompose the request into **atomic search concepts** that search engines can match effectively.

**Why this matters**: Search engines match keywords, not intent. A verbose question like "Is React 19's use() hook a viable replacement for useEffect patterns in production apps?" will miss threads titled "use() vs useEffect" or "React 19 hooks review". Decomposition bridges this gap.

**Process**:

1. **Extract core entities**: Product/technology names exactly as communities write them 2. **Generate query variants** by search intent:

• `core`: The most concise keyword combination (2-4 words)
• `versus`: Direct comparison form if applicable ("A vs B")
• `opinion`: How people ask about it ("A worth it", "A review", "A experience")
• `technical`: Specific feature/aspect if the question targets one ("A feature X")

3. **Select best variant per platform** (see mapping below)

**Example**: "Can React 19's use() hook replace the existing useEffect pattern?"

| Variant | Query | |---------|-------| | `core` | `React 19 use hook` | | `versus` | `use() vs useEffect` | | `opinion` | `React 19 use hook worth it` | | `technical` | `React 19 use hook replace useEffect` |

**Example**: "Is Cursor worth paying for compared