\r \r

Crab Catch — Research Skill Orchestration\r

\r

Prerequisites\r

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

which agent-browser || npm install -g agent-browser\r
agent-browser install\r
```\r
\r
## Data Sources\r
\r
CLAWBOT is the research driver — responsible for analysis, judgment, iteration,\r
and report generation. The APIs, scripts, and tools below are **data-fetching\r
methods only**.\r
\r
**API Base URL**: `https://crab-skill.opsat.io`\r
\r
### Signature Authentication\r
\r
All API requests except `/api/health` require Crab signature headers.\r
\r
1. Run `node skills/scripts/crab-sign.js` **once** at session start to get headers JSON.\r
   (First run auto-generates credentials; cached signature reused if still valid within 24h.)\r
2. Store the output and attach these four headers to **all** subsequent API requests:\r
   `X-Crab-Timestamp`, `X-Crab-Signature`, `X-Crab-Key`, `X-Crab-Address`.\r
3. Only re-run with `--refresh` if API returns `auth_expired`.\r
\r
### Twitter & Social Data (see `twitter-analysis/SKILL.md` for full params)\r
\r
| Category | Key endpoints | Purpose |\r
|----------|---------------|---------|\r
| Profile | `/api/twitter/user`, `tweets`, `replies` | Basic info, content, interactions |\r
| Risk signals | `/api/twitter/deleted-tweets`, `follower-events` | Removed content, follow/unfollow patterns |\r
| Reply threads | `/api/readx/tweet-detail-conversation-v2` | Primary comment source (fast, raw data) |\r
| Quote tweets | `/api/readx/tweet-quotes` | KOL commentary, community opinions with context |\r
| Engagement data | `/api/readx/tweet-detail-v2` | Views/source — detect bot-inflation |\r
| Deleted content | `/api/readx/tweet-results-by-ids` | Batch fetch deleted tweet snapshots |\r
| Long-form | `/api/readx/tweet-article` | Technical analyses, roadmaps published as articles |\r
| Relationships | `/api/readx/following-light`, `friendships-show` | Inner circle, team relationship verification |\r
| Credibility | `/api/twitter/kol-followers`, `/api/readx/user-verified-followers` | Who credible follows them (`verified-followers` needs `user_id` not username) |\r
| Search | `/api/twitter/search`, `/api/readx/search2` | Risk signals, disputes, community discussions |\r
\r
### GitHub Code (see `github-analysis/SKILL.md`)\r
\r
Local script `skills/scripts/github_analyze.js` — no external API.\r
`convertToMarkdown(url, options)` or `analyzeRepository(url, options)`.\r
\r
### On-chain Data (see `onchain-audit/SKILL.md`)\r
\r
**Binance API** — `address` + `chainName` (uppercase: `BSC`/`ETHEREUM`/`BASE`/`SOLANA`):\r
\r
| Endpoint | Description |\r
|----------|-------------|\r
| `/api/onchain/audit` | Contract audit (dual-source) |\r
| `/api/onchain/token-info` | Token metadata and market dynamics |\r
| `/api/onchain/wallet` | Wallet positions (BSC/BASE/SOLANA only) |\r
| `/api/onchain/token-search` | Token search (requires `keyword`) |\r
\r
**Bitget API** — `chain` + `contract` (lowercase: `bnb`/`eth`/`base`/`sol`):\r
\r
| Endpoint | Description |\r
|----------|-------------|\r
| `/api/onchain-2/token-info` | Token details |\r
| `/api/onchain-2/token-price` | Token price |\r
| `/api/onchain-2/tx-info` | Transaction statistics |\r
| `/api/onchain-2/liquidity` | Liquidity pool info |\r
| `/api/onchain-2/security-audit` | Security audit |\r
\r
**Onchain Explorer API** — `chain` + `address` (see `API_EXPLORER.md` for full params):\r
\r
| Endpoint | Chain | Description |\r
|----------|-------|-------------|\r
| `/api/explorer/contract` | ETH, BSC | Contract ABI, source code, compiler info, proxy detection |\r
| `/api/explorer/token-history` | ETH, BSC, SOL | Token transfer history with pagination |\r
| `/api/explorer/sol-address` | SOL | SOL/SPL balances + recent transfer records |\r
\r
### Website Content (see `agent-browser/SKILL.md`)\r
\r
CLAWBOT uses `agent-browser` CLI to open and inspect websites.\r
\r
## Language Preference\r
\r
Output language **matches the user's input language**; default **Chinese (zh-CN)**.\r
Raw API data (usernames, tickers, addresses, code) stays in original form.\r
\r
## Orchestration Flow\r
\r
**Callback-driven**: each module's output triggers queries in other modules.\r
Modules keep feeding each other until no new high-value leads remain.\r
\r
```\r
User provides URL / Ticker / contract address + research intent\r
  │\r
  ▼\r
Step 1 — Parse input, initialize entity queue\r
  Extract: Twitter links, GitHub repos, contract addresses, tickers, chain\r
  Aggregator URLs → extract entities from path (see rules below)\r
\r
  Initialize:\r
    entity_queue  = [{ entity, type, depth: 0 }]\r
    processed     = set()\r
    claims        = []    # official claims to verify later\r
    fund_trace    = []    # addresses to trace fund flow\r
    team_members  = []    # { handle, role, source }\r
    MAX_DEPTH     = 2\r
  │\r
  ▼\r
Step 2 — Multi-module collection\r
\r
  While entity_queue is not empty:\r
    pop → skip if processed or depth > MAX_DEPTH → route by type:\r
      URL      → 2a Website\r
      Twitter  → 2b Social\r
      GitHub   → 2c Code\r
      Contract → 2d Chain\r
      Ticker   → 2d token-search first\r
    After each module: extract new entities → queue at depth+1\r
    (see Cross-module Callback Summary below for full routing)\r
\r
  ── 2a. Website exploration ──────────────────────────────────\r
\r
  **Use `agent-browser` CLI** (see agent-browser/SKILL.md for commands).\r
  agent-browser renders JS, captures interactive elements, and allows\r
  clicking through pages — essential for DApp testing and dynamic sites.\r
  Fallback to WebFetch only when agent-browser fails (e.g. install issue).\r
\r
  Visit pages in order:\r
    Landing → Docs/Whitepaper → Team/About → DApp → Tokenomics → Footer\r
\r
  Extract from each page:\r
    - Official claims → append to claims[] ("audited by X", "100M supply",\r
      "decentralized", "LP locked", partnerships, etc.)\r
    - Team names + social links → team_members[] + queue 2b\r
    - Contract addresses → queue 2d\r
    - GitHub repos → queue 2c\r
\r
  DApp proactive testing (key investigation step):\r
    - Open DApp via agent-browser, wait for load\r
    - Does the UI render real data or just a mock shell?\r
    - Are core functions visible and interactive?\r
    - Check network requests: broken APIs? Suspicious external calls?\r
    - If DApp shows on-chain values → cross-check against 2d data\r
    - Screenshot as evidence\r
\r
  Security check: SSL, domain age, redirects, suspicious popups.\r
  Fallback: blank/Cloudflare → retry with `--headed`. No website → flag as risk.\r
\r
  ── 2b. Social data collection (Twitter) ─────────────────────\r
\r
  Purpose: collect project claims, discover team, find community disputes.\r
  NOT the investigation core — feeds into 2a/2c/2d for verification.\r
\r
  For project official account:\r
    1. /api/twitter/user + tweets + replies + deleted-tweets (parallel)\r
    2. Pick 1-2 high-value tweets → conversation-v2 + quotes\r
    3. /api/readx/following-light → identify team members from following list\r
       (mutual follows, bio mentions project, new account only posts about project)\r
       → add to team_members[], queue 2b at depth+1\r
    4. Risk search: search2 "{project} scam OR rug OR hack OR exploit"\r
\r
  For team member accounts (depth 1+):\r
    1. /api/twitter/user + tweets (parallel)\r
    2. Only retain project-related tweets → append to claims[]\r
       (team member statements carry same weight as official claims)\r
    3. friendships-show with other known team members\r
       (all isolated = fake team red flag)\r
\r
  ── 2c. Code analysis (GitHub) ───────────────────────────────\r
\r
  github-analysis → analyzeRepository / convertToMarkdown\r
\r
  Focus: claim verification + security scan\r
    - "Open source" → repo public? Code complete or stub?\r
    - "Audited" → audit report in repo? Code matches?\r
    - Hardcoded addresses (admin, treasury) → queue 2d + fund_trace[]\r
    - Suspicious patterns: obfuscation, eval(), wallet-draining code,\r
      backdoors, malicious dependencies, clipboard hijacking\r
    - Contributor identities → try resolve to Twitter → team_members[]\r
    - Freshness: last commit, bus factor, fork-of-fork detection\r
\r
  ── 2d. On-chain analysis (investigation core) ───────────────\r
\r
  Phase 1 — Token & contract basics (parallel):\r
    Binance: audit, token-info, wallet\r
    Bitget:  token-info, token-price, tx-info, liquidity, security-audit\r
    Cross-verify between sources.\r
\r
  Phase 2 — Contract deep inspection (ETH/BSC):\r
    /api/explorer/contract → ABI + source code\r
    - Read ABI: identify owner-only functions (pause, mint, blacklist,\r
      upgrade, setFee, transferOwnership)\r
    - If proxy contract: queue implementation address (recursive 2d)\r
    - If source verified: scan for backdoor patterns in code\r
    - If NOT verified: flag as risk (cannot audit)\r
\r
  Phase 3 — Fund flow tracing:\r
    Triggered by: fund_trace[], deployer discovery, large holder detection\r
    /api/explorer/token-history → trace address transaction history\r
\r
    Tracing logic (recursive within depth limit):\r
      1. Fetch token-history for the address\r
      2. Identify significant transfers:\r
         - Large outflows to unknown wallets → trace recipient\r
         - Inflows from deployer → insider?\r
         - Flows to/from known exchanges → cash-out pattern?\r
         - Circular flows (A→B→C→A) → wash trading?\r
      3. For each significant counterparty:\r
         - New address → add to fund_trace[] at depth+1\r
         - Known exchange → note cash-out\r
         - Mixer/bridge → flag as risk signal\r
      4. Stop when: depth limit / no significant new flows\r
\r
    SOL specific:\r
    - /api/explorer/sol-address → balance snapshot + SPL tokens\r
    - /api/explorer/token-history (SOL) → filter by type/source\r
      SWAP on Jupiter/Raydium = trading; TRANSFER = fund movement\r
\r
  │\r
  ▼\r
Step 3 — Verify claims & resolve contradictions\r
  Goal: every official claim gets a verdict. Contradictions are the story.\r
  If verification needs data not yet collected → callback to Step 2.\r
\r
  Process claims[] collected during Step 2:\r
\r
    | Claim | Verify with | How |\r
    |-------|-------------|-----|\r
    | "Decentralized" | Explorer ABI + on-chain | pause/mint/blacklist? EOA or multisig? |\r
    | "Audited by X" | Website + GitHub + firm | Link valid? Code matches audited version? |\r
    | "Max supply N" | Explorer source code | Uncapped mint()? Owner can mint? |\r
    | "Locked liquidity" | On-chain LP lock | Lock verified? Duration? Amount? |\r
    | "Open source" | GitHub + Explorer | Public? Verified? ABI matches? |\r
    | "Partnerships" | Partner channels (browser) | Partner acknowledges? One-sided? |\r
\r
    Priority: verify claims affecting user funds first.\r
    Mark each: ✅ Verified / ⚠️ Unverified / ❌ Contradicted\r
\r
  For each ❌ or anomaly → dispute analysis:\r
    1. Project claim vs actual data (on-chain, code) → cite both\r
    2. Community analysis → search2 + conversation threads\r
    3. On-chain evidence → tx hashes, fund flow from fund_trace[]\r
    4. Synthesize: claim → reality → community → verdict\r
       🔴 → full analysis / 🟡 → summary only\r
  │\r
  ▼\r
Step 4 — Hypothesis-driven deep dig\r
  Follow high-value leads from Steps 2-3. May callback to any module.\r
\r
  Key hypotheses:\r
    - Contract upgradable → who holds proxy admin?\r
    - Large holder → tokens from deployer? Insider?\r
    - Deleted tweets → timing vs on-chain events?\r
    - Deployer has other contracts → same pattern? Previous rugs?\r
\r
  Team verification:\r
    - Identity: Twitter vs website claims vs GitHub commits\r
    - History: search2 "{name} founder OR CEO", wallet history\r
    - Red flags: account age = project age? No pre-project history?\r
\r
  Any new lead → callback to Step 2 (respecting MAX_DEPTH).\r
  Stop when: no new leads or sufficient for judgment.\r
\r
  ─── END OF DATA COLLECTION ───\r
  │\r
  ▼\r
Step 5 — Distill (no fetching)\r
  Rank by impact. Discard noise. Connect dots. Reconstruct timeline.\r
  │\r
  ▼\r
Step 6 — Produce report (see REPORT_TEMPLATE.md)\r
  Curated intelligence, NOT a data dump. Focus on:\r
    1. Contradictions & anomalies\r
    2. Claim verification results\r
    3. Fund flow analysis\r
    4. Proactive test results (DApp, website)\r
    5. Security findings\r
  Omit routine confirmations. [[N]](url) citations required.\r
  Language follows user input; default zh-CN.\r
```\r
\r
### Cross-module Callback Summary\r
\r
Each module feeds discoveries into other modules:\r
\r
```\r
  ┌──────────┐     handles, claims      ┌──────────┐\r
  │  Website  │ ──────────────────────→  │  Twitter  │\r
  │   (2a)    │ ◀────────────────────── │   (2b)    │\r
  └─────┬─────┘   URLs from tweets      └─────┬─────┘\r
        │ contracts, repos                     │ addresses, accusations\r
        ▼                                      ▼\r
  ┌──────────┐     hardcoded addrs      ┌──────────┐\r
  │  GitHub   │ ──────────────────────→  │ On-chain  │\r
  │   (2c)    │ ◀── code vs claims ──── │   (2d)    │\r
  └──────────┘                          └─────┬─────┘\r
                                               │ recursive\r
                                               ▼\r
                                          (2d again)\r
```\r
\r
| Source | Discovers | Triggers |\r
|--------|-----------|----------|\r
| Website | Twitter handles, claims, contracts, repos | → team_members[]/claims[]/2b/2c/2d |\r
| Twitter | URLs, addresses, accusations, team members, statements | → 2a/2d/fund_trace[]/claims[]/team_members[] |\r
| GitHub | Contributors, hardcoded addrs, code contradictions, trojans | → team_members[]/2d/fund_trace[]/claims[] |\r
| On-chain | Proxy impl, deployer contracts, large holders, data contradictions | → 2d recursive/fund_trace[]/claims[] |\r
\r
**Depth control:** 0 = user input → 1 = discovered → 2 = max, high-value only → beyond: note only\r
\r
## Failure Handling\r
\r
| Failure type | Action |\r
|-------------|--------|\r
| Timeout / 502-504 | Retry once after 3s |\r
| 429 (rate limit) | Retry once after `Retry-After` or 10s |\r
| 401 / 403 / 400 | Do not retry; skip |\r
| Other errors | Do not retry; skip |\r
\r
On failure: skip source, continue. Include **Data Coverage** note in report.\r
Omit sections with no data; never halt for a single failure.\r
\r
## Entity Extraction Rules\r
\r
| Entity Type | Identification |\r
|----------|---------|\r
| Twitter profile | `x.com/{username}` or `twitter.com/{username}` |\r
| Twitter post | `x.com/{username}/status/{id}` |\r
| GitHub repo | `github.com/{owner}/{repo}` |\r
| EVM contract | `0x` + 40 hex chars |\r
| Solana address | base58 32–44 chars + contextual keywords (below) |\r
| Ticker | `$XXX` or `ticker/symbol/token: XXX` |\r
| Chain | URL domain / path keywords / page text |\r
\r
**Solana keywords** (at least one must be present):\r
`solana`, `sol`, `raydium`, `jupiter`, `orca`, `meteora`, `pump.fun`,\r
`moonshot`, `birdeye`, `solscan`, `solana.fm`, `spl token`, `program id`\r
No keyword → flag as "unresolved address".\r
\r
## Aggregator URL Parsing\r
\r
| Platform | Path | Parsed result |\r
|------|---------|---------|\r
| clawhub.ai | `/owner/repo` | → GitHub repo (use `github-analysis`, skip browser) |\r
| dexscreener.com | `/chain/address` | → contract + chain |\r
| dextools.io | `/app/chain/pair/address` | → contract + chain |\r
| pump.fun | `/address` | → Solana contract |\r
| gmgn.ai | `/chain/address` | → contract + chain |\r
| birdeye.so | `/token/address` | → contract |\r
| defined.fi | `/chain/address` | → contract + chain |\r
\r
## Data Display Rules\r
\r
- Skip any metric that returned an error or timed out — leave it out entirely.\r
- Do not display API latency unless it was actually measured successfully.\r
\r
## Local Memory & Report Storage\r
\r
1. Save report as PDF to `~/.crab-catch/reports/{project_name}_{YYYY-MM-DD}.pdf`\r
2. Maintain index `~/.crab-catch/reports/index.json`:\r
   `{ "project": "name", "date": "YYYY-MM-DD", "file": "filename.pdf", "entry": "original input" }`\r
\r
## Report Output\r
\r
Use `REPORT_TEMPLATE.md` as the report structure.\r
\r
### Report philosophy: curated intelligence, not data dump\r
\r
The report should be **concise and decision-oriented**. The reader wants to know:\r
is this project trustworthy? What are the risks? Where do the claims fall apart?\r
\r
**Five pillars of the report** (in order of importance):\r
\r
1. **Contradictions & anomalies** — where different sources tell different stories.\r
   This is the most valuable content. Twitter says X, website says Y, on-chain shows Z.\r
2. **Claim verification** — systematic test of every official statement.\r
   What the project claims vs what the code/chain actually shows.\r
3. **Fund flow analysis** — where the money goes.\r
   Deployer → holders → exchanges. Insider patterns, circular flows, cash-outs.\r
4. **Proactive testing** — DApp functionality, website integrity, code security.\r
   Does the product work? Is the website legit? Are there backdoors in the code?\r
5. **Security findings** — contract risks, code trojans, permission hazards.\r
   ABI dangerous functions, proxy patterns, obfuscated code.\r
\r
**What to omit:** routine data that confirms nothing special. If a metric is normal,\r
don't list it. If a claim checks out cleanly, a single ✅ row is enough — no paragraph.\r
Only expand on findings that change the reader's decision.\r
\r
### Section constraints\r
\r
**Must keep** — always present, fixed order:\r
- Header (project name + timestamp)\r
- 📌 Basic Information (flexible rows — agent adds/removes based on data, no fixed schema)\r
- 🧠 Core Findings (with Executive Summary)\r
- 📝 Conclusion & Verdict\r
- 📂 References\r
\r
**Default keep** — user can request to skip:\r
- 🛡️ Verification & Cross-Reference (Claim / Contradictions / Disputes / Gaps)\r
- ⚠️ Risk Warning\r
\r
**Data-dependent** — skip if no data:\r
- 📊 Deep Dive\r
  - 👤 Team & Key Figures\r
  - 💻 GitHub Analysis\r
  - ⛓️ On-chain Security\r
  - 📈 Social Signals\r
  - 📅 Project Timeline\r
\r
### Formatting rules\r
\r
**Citation system (mandatory, like academic papers):**\r
- Every factual claim MUST have `[[N]](url)` citation\r
- No source = mark as ⚠️ Unverified, NOT stated as fact\r
- Sequential numbering, first appearance order\r
- Bidirectional: every `[[N]]` ↔ References entry\r
\r
**Other:**\r
- Numbers: K / M / B; prices: `$` prefix\r
- Highlight high-risk signals (honeypot, high tax, upgradable contracts)\r
- **Data Coverage** note when sources unavailable\r
- DYOR disclaimer\r
- **Output language matches user input; default zh-CN**\r