Crab Catch

What this skill does

# Crab Catch — Research Skill Orchestration

## Prerequisites

CLAWBOT **must run** these commands at session start (not just read them):

```bash
which agent-browser || npm install -g agent-browser
agent-browser install
```

## Data Sources

CLAWBOT is the research driver — responsible for analysis, judgment, iteration,
and report generation. The APIs, scripts, and tools below are **data-fetching
methods only**.

**API Base URL**: `https://crab-skill.opsat.io`

### Signature Authentication

All API requests except `/api/health` require Crab signature headers.

1. Run `node skills/scripts/crab-sign.js` **once** at session start to get headers JSON.
   (First run auto-generates credentials; cached signature reused if still valid within 24h.)
2. Store the output and attach these four headers to **all** subsequent API requests:
   `X-Crab-Timestamp`, `X-Crab-Signature`, `X-Crab-Key`, `X-Crab-Address`.
3. Only re-run with `--refresh` if API returns `auth_expired`.

### Twitter & Social Data (see `twitter-analysis/SKILL.md` for full params)

| Category | Key endpoints | Purpose |
|----------|---------------|---------|
| Profile | `/api/twitter/user`, `tweets`, `replies` | Basic info, content, interactions |
| Risk signals | `/api/twitter/deleted-tweets`, `follower-events` | Removed content, follow/unfollow patterns |
| Reply threads | `/api/readx/tweet-detail-conversation-v2` | Primary comment source (fast, raw data) |
| Quote tweets | `/api/readx/tweet-quotes` | KOL commentary, community opinions with context |
| Engagement data | `/api/readx/tweet-detail-v2` | Views/source — detect bot-inflation |
| Deleted content | `/api/readx/tweet-results-by-ids` | Batch fetch deleted tweet snapshots |
| Long-form | `/api/readx/tweet-article` | Technical analyses, roadmaps published as articles |
| Relationships | `/api/readx/following-light`, `friendships-show` | Inner circle, team relationship verification |
| Credibility | `/api/twitter/kol-followers`, `/api/readx/user-verified-followers` | Who credible follows them (`verified-followers` needs `user_id` not username) |
| Search | `/api/twitter/search`, `/api/readx/search2` | Risk signals, disputes, community discussions |

### GitHub Code (see `github-analysis/SKILL.md`)

Local script `skills/scripts/github_analyze.js` — no external API.
`convertToMarkdown(url, options)` or `analyzeRepository(url, options)`.

### On-chain Data (see `onchain-audit/SKILL.md`)

**Binance API** — `address` + `chainName` (uppercase: `BSC`/`ETHEREUM`/`BASE`/`SOLANA`):

| Endpoint | Description |
|----------|-------------|
| `/api/onchain/audit` | Contract audit (dual-source) |
| `/api/onchain/token-info` | Token metadata and market dynamics |
| `/api/onchain/wallet` | Wallet positions (BSC/BASE/SOLANA only) |
| `/api/onchain/token-search` | Token search (requires `keyword`) |

**Bitget API** — `chain` + `contract` (lowercase: `bnb`/`eth`/`base`/`sol`):

| Endpoint | Description |
|----------|-------------|
| `/api/onchain-2/token-info` | Token details |
| `/api/onchain-2/token-price` | Token price |
| `/api/onchain-2/tx-info` | Transaction statistics |
| `/api/onchain-2/liquidity` | Liquidity pool info |
| `/api/onchain-2/security-audit` | Security audit |

**Onchain Explorer API** — `chain` + `address` (see `API_EXPLORER.md` for full params):

| Endpoint | Chain | Description |
|----------|-------|-------------|
| `/api/explorer/contract` | ETH, BSC | Contract ABI, source code, compiler info, proxy detection |
| `/api/explorer/token-history` | ETH, BSC, SOL | Token transfer history with pagination |
| `/api/explorer/sol-address` | SOL | SOL/SPL balances + recent transfer records |

### Website Content (see `agent-browser/SKILL.md`)

CLAWBOT uses `agent-browser` CLI to open and inspect websites.

## Language Preference

Output language **matches the user's input language**; default **Chinese (zh-CN)**.
Raw API data (usernames, tickers, addresses, code) stays in original form.

## Orchestration Flow

**Callback-driven**: each module's output triggers queries in other modules.
Modules keep feeding each other until no new high-value leads remain.

```
User provides URL / Ticker / contract address + research intent
  │
  ▼
Step 1 — Parse input, initialize entity queue
  Extract: Twitter links, GitHub repos, contract addresses, tickers, chain
  Aggregator URLs → extract entities from path (see rules below)

  Initialize:
    entity_queue  = [{ entity, type, depth: 0 }]
    processed     = set()
    claims        = []    # official claims to verify later
    fund_trace    = []    # addresses to trace fund flow
    team_members  = []    # { handle, role, source }
    MAX_DEPTH     = 2
  │
  ▼
Step 2 — Multi-module collection

  While entity_queue is not empty:
    pop → skip if processed or depth > MAX_DEPTH → route by type:
      URL      → 2a Website
      Twitter  → 2b Social
      GitHub   → 2c Code
      Contract → 2d Chain
      Ticker   → 2d token-search first
    After each module: extract new entities → queue at depth+1
    (see Cross-module Callback Summary below for full routing)

  ── 2a. Website exploration ──────────────────────────────────

  **Use `agent-browser` CLI** (see agent-browser/SKILL.md for commands).
  agent-browser renders JS, captures interactive elements, and allows
  clicking through pages — essential for DApp testing and dynamic sites.
  Fallback to WebFetch only when agent-browser fails (e.g. install issue).

  Visit pages in order:
    Landing → Docs/Whitepaper → Team/About → DApp → Tokenomics → Footer

  Extract from each page:
    - Official claims → append to claims[] ("audited by X", "100M supply",
      "decentralized", "LP locked", partnerships, etc.)
    - Team names + social links → team_members[] + queue 2b
    - Contract addresses → queue 2d
    - GitHub repos → queue 2c

  DApp proactive testing (key investigation step):
    - Open DApp via agent-browser, wait for load
    - Does the UI render real data or just a mock shell?
    - Are core functions visible and interactive?
    - Check network requests: broken APIs? Suspicious external calls?
    - If DApp shows on-chain values → cross-check against 2d data
    - Screenshot as evidence

  Security check: SSL, domain age, redirects, suspicious popups.
  Fallback: blank/Cloudflare → retry with `--headed`. No website → flag as risk.

  ── 2b. Social data collection (Twitter) ─────────────────────

  Purpose: collect project claims, discover team, find community disputes.
  NOT the investigation core — feeds into 2a/2c/2d for verification.

  For project official account:
    1. /api/twitter/user + tweets + replies + deleted-tweets (parallel)
    2. Pick 1-2 high-value tweets → conversation-v2 + quotes
    3. /api/readx/following-light → identify team members from following list
       (mutual follows, bio mentions project, new account only posts about project)
       → add to team_members[], queue 2b at depth+1
    4. Risk search: search2 "{project} scam OR rug OR hack OR exploit"

  For team member accounts (depth 1+):
    1. /api/twitter/user + tweets (parallel)
    2. Only retain project-related tweets → append to claims[]
       (team member statements carry same weight as official claims)
    3. friendships-show with other known team members
       (all isolated = fake team red flag)

  ── 2c. Code analysis (GitHub) ───────────────────────────────

  github-analysis → analyzeRepository / convertToMarkdown

  Focus: claim verification + security scan
    - "Open source" → repo public? Code complete or stub?
    - "Audited" → audit report in repo? Code matches?
    - Hardcoded addresses (admin, treasury) → queue 2d + fund_trace[]
    - Suspicious patterns: obfuscation, eval(), wallet-draining code,
      backdoors, malicious dependencies, clipboard hijacking
    - Cont