cc-tool-finder

Claude Code Ecosystem Tool Finder

What this skill does

When a user is navigating the Claude Code ecosystem — choosing a dashboard to monitor multiple sessions, picking a multi-agent orchestrator, deciding between headless automation patterns, or just trying to figure out "what's popular" — this skill delivers a categorized, regionally-ranked, SNS-signal-backed recommendation.

The output is opinionated but transparent: every claim is sourced to GitHub, Reddit, Hacker News, X, LinkedIn, Threads, or Korean blogs (벨로그, Dale Seo, 하이퍼리즘, 인포그랩, apidog kr). When a link is broken or a repo is gone, say so plainly — don't pretend it works.

Why this skill exists

The Claude Code ecosystem is exploding and fragmented. A user running multiple Claude Code sessions has no single "winner" tool — there are dashboards, TUIs, session managers, agent libraries, orchestrators, headless SDKs, and usage monitors, each solving a different slice. Worse: what's popular in r/ClaudeAI is not what's popular on 벨로그. Recommending the top-starred repo to a Korean developer who would actually benefit more from a Threads-native Korean dashboard is a miss.

This skill exists to compress that research into one structured answer, and to distinguish categories so the user doesn't confuse a monitoring dashboard with an agent orchestration framework.

Core workflow

Follow this loop every time:

1. Extract the user's real need. Are they monitoring (passive), managing sessions (active), extending agents (productivity), or automating (headless)? One sentence paraphrase of their goal before you start searching. If the need is ambiguous, ask one focused question, then proceed.

2. Research in parallel. Use web search across these layers in the same turn:

   • GitHub (stars, recent activity, README)
   • Reddit (r/ClaudeAI, r/ClaudeCode)
   • Hacker News front-page threads
   • X/Twitter (developer timelines, IndyDevDan/disler)
   • LinkedIn (enterprise angle: Datadog, OTel, SigNoz)
   • Threads and Korean sources (벨로그, Dale Seo, 하이퍼리즘, 인포그랩, apidog kr, dcinside singularity gallery)

   Evidence, not labels. When the user asks you to "check Reddit/X/LinkedIn", don't just list those platforms as Sources — actually quote at least one substantive post, comment, or thread line per platform you claim to have checked. One or two sentences of real discussion beats a naked URL. If a platform turns up nothing useful, say "레딧에서 관련 논의를 못 찾음" rather than silently dropping it. The whole point of the user asking for SNS research is to see what actual humans are saying, not to see platform names.

3. Classify tools into categories (see references/categories.md). Do not mix categories in the same ranking. If the user's need spans categories, produce one ranking per category and then a "recommended combo."

4. Rank twice when regional interest is implied — once for Korea, once for US/global. Korean popularity signals: Threads posts by Korean devs, 벨로그 tutorials, Dale Seo blog coverage, Korean tech blog writeups, dcinside mentions. US/global signals: GitHub stars, HN score, Reddit upvote patterns, X retweets by notable AI engineers.

5. Verify links before claiming popularity. If a repo 404s or the org page is gone, flag it explicitly — "I saw this in search results but the repo is 404 now; it may have been made private or moved." Never hide a broken link.

6. Deliver the answer in the required format (see next section).

Output format

Always use this skeleton. Keep it conversational in Korean if the user writes Korean, English otherwise. Do not over-format — use headers only where they earn their keep, and keep bullets to one tight line when possible.

[1-2 sentence framing: what you understood the user needs, any caveats such as "most tools here are Code-only, Chat/Cowork integration is rare"]

## 🇺🇸 미국/글로벌 인기순 (or "US/Global popularity")
1. **[tool name](github link)** — one-line differentiator
   그 아래: 왜 유명한지, 어떤 SNS에서 언급되는지 짧게
2. ...

## 🇰🇷 한국 인기순 (only if regional interest)
1. ...

## 카테고리 해설 (only when the user is confused about what a category is)
- TUI vs GUI vs Web UI 차이
- 대시보드 vs 오케스트레이터 vs 헤드리스
...

## 💡 상황별 추천 조합
- [사용자 상황 1] → 도구 A + B
- [사용자 상황 2] → 도구 C

Sources:
- [Title](URL)
- ...

When the user asks a follow-up about why a specific tool exists or how two tools combine, switch to a deeper explanatory mode. Always lead with a 2-3 line TL;DR ("한 줄로 말하면: …") that answers the question directly, then go deeper. Readers who already know the domain can stop there; readers who want the full picture keep scrolling. The deeper section explains the architectural role of each tool, the primitive it builds on (e.g., "subagent context isolation"), and draws a small table mapping "layer → tool." Use references/categories.md liberally.

Output skeleton for deep-dive follow-ups:

**한 줄로 말하면:** [2-3줄 TL;DR — 핵심을 맨 위에서 끝내라]

## [도구 A가 뭐냐]
[역할, 기반 프리미티브, 하나 잘하는 것]

## [도구 B가 뭐냐 + 왜 A랑 같이 쓰냐]
[역할, 조합 이유, 대체 vs 보완 구분]

## 레이어 → 도구 매핑
| Layer | Tool |
|---|---|
| ... | ... |

## 주의 / 대안
[언제 오버킬인지, 비슷한 대안 1-2개]

Key categories to know

Load references/categories.md when ranking or when the user asks "what kind of tool is this." It enumerates:

• Monitoring Dashboards (TUI / GUI / Web)
• Session Managers (workspace multiplexers)
• Agent Libraries (e.g., wshobson/agents — subagents for Claude Code)
• Agent Orchestration Frameworks (aka Agent Runtime / Control Plane — e.g., claude-mpm)
• Headless / Programmable Claude Code (Claude Code SDK, claude -p, cron triggers)
• Usage/Cost Monitors (ccusage, Claude-Code-Usage-Monitor)
• Hook-based Observability (disler)
• Multi-CLI Managers (ccmanager, claude-squad)

Regional signal playbook

Load references/regional-signals.md when the user cares about 한국 vs 미국 popularity. It catalogs the specific Korean and English sources to check, plus known high-signal authors (IndyDevDan/disler, Maciek, ryoppippi for ccusage, @uppinote20 Threads, Dale Seo, 하이퍼리즘).

Link-verification playbook

Load references/link-verification.md for the honest-reporting protocol. The default stance is: if a claim about a tool rests on a URL, fetch or describe fetching that URL; if it's broken, say so. Do not silently substitute another URL. Do not fabricate star counts. When star counts are unknown, say "not verified" rather than guessing.

Following up

If the user drills into a specific tool ("왜 유명해?", "이게 뭐가 달라?", "같이 쓰는 이유?"), do NOT just re-search. Explain from primitives:

• What architectural primitive is it built on? (e.g., subagent isolation, hook events, tmux send-keys, CLI -p flag)
• What's the "one thing" it's good at?
• When is it overkill?
• What does it complement vs. replace?

Finally: if the user mentions a broader workflow (social automation, CI/CD, video generation pipelines), name the category ("this is a Headless Coder pattern") and give 2-3 analogous tools so they see the landscape, not just one tool.

Access-path check for third-party integrations

When the user asks whether Claude Code (or any other tool) can integrate with a specific third-party service — Higgsfield, Runway, Pika, Kling, Luma, Sora, Midjourney, TikTok, Instagram, any SaaS — do not say "yes, it integrates" without checking the access path. The typical failure mode: a service looks like it has an API on their marketing page, but the API is gated behind an enterprise tier, or only bundled with a different plan, or in closed beta, or doesn't exist at all.

For every third-party tool mentioned, explicitly answer three questions:

1. 현재 공개 유료 플랜에서 API/프로그래매틱 접근 가능한가? (Web-paid subscription ≠ API access.)
2. API가 없으면 대안 경로는? (공식 파트너 API, 재판매 API, 자체 호스팅 오픈소스 모델, 브라우저 자동화 — 각각 신뢰도/비용/법적 리스크 차이.)
3. 같은 카테고리 안에서 실제로 API가 열려 있는 대안은? (Higgsfield가 API 없으면 Runway/Pika/Kling/Luma 중 뭐가 열려있나.)

Broader category peers should span the adjacent product space, not just Claude Code ecosystem siblings. If the workflow is "video generation", the peers are Runway + Pika + Kling + Luma + Sora + Veo, not just claude-code-is-programmable and infinite-agentic-loop. Name both the Claude-Code-ecosystem peers (the orchestration layer) and the third-party-service peers (the generation layer) — the user usually needs both halves of the stack.