Crab Catch — Research Skill Orchestration
Prerequisites
CLAWBOT must run these commands at session start (not just read them):
CODEBLOCK0
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: INLINECODE0
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 | INLINECODE10 , tweets, INLINECODE12 | 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 |
|---|
| INLINECODE39 | Contract audit (dual-source) |
| INLINECODE40 |
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 |
|---|
| INLINECODE50 | Token details |
| INLINECODE51 |
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 |
|---|
| INLINECODE58 | ETH, BSC | Contract ABI, source code, compiler info, proxy detection |
| INLINECODE59 |
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.
CODEBLOCK1
Cross-module Callback Summary
Each module feeds discoveries into other modules:
CODEBLOCK2
| Source | Discovers | Triggers |
|---|
| Website | Twitter handles, claims, contracts, repos | → teammembers[]/claims[]/2b/2c/2d |
| Twitter |
URLs, addresses, accusations, team members, statements | → 2a/2d/fundtrace[]/claims[]/team_members[] |
| GitHub | Contributors, hardcoded addrs, code contradictions, trojans | → team
members[]/2d/fundtrace[]/claims[] |
| On-chain | Proxy impl, deployer contracts, large holders, data contradictions | → 2d recursive/fund_trace[]/claims[] |
Depth control: 0 = user input → 1 = discovered → 2 = max, high-value only → beyond: note only
Failure Handling
| Failure type | Action |
|---|
| Timeout / 502-504 | Retry once after 3s |
| 429 (rate limit) |
Retry once after
Retry-After or 10s |
| 401 / 403 / 400 | Do not retry; skip |
| Other errors | Do not retry; skip |
On failure: skip source, continue. Include Data Coverage note in report.
Omit sections with no data; never halt for a single failure.
Entity Extraction Rules
| Entity Type | Identification |
|---|
| Twitter profile | INLINECODE64 or INLINECODE65 |
| Twitter post |
x.com/{username}/status/{id} |
| GitHub repo |
github.com/{owner}/{repo} |
| EVM contract |
0x + 40 hex chars |
| Solana address | base58 32–44 chars + contextual keywords (below) |
| Ticker |
$XXX or
ticker/symbol/token: XXX |
| Chain | URL domain / path keywords / page text |
Solana keywords (at least one must be present):
solana, sol, raydium, jupiter, orca, meteora, pump.fun,
moonshot, birdeye, solscan, solana.fm, spl token, program id
No keyword → flag as "unresolved address".
Aggregator URL Parsing
| Platform | Path | Parsed result |
|---|
| clawhub.ai | INLINECODE84 | → GitHub repo (use github-analysis, skip browser) |
| dexscreener.com |
/chain/address | → contract + chain |
| dextools.io |
/app/chain/pair/address | → contract + chain |
| pump.fun |
/address | → Solana contract |
| gmgn.ai |
/chain/address | → contract + chain |
| birdeye.so |
/token/address | → contract |
| defined.fi |
/chain/address | → contract + chain |
Data Display Rules
- - Skip any metric that returned an error or timed out — leave it out entirely.
- Do not display API latency unless it was actually measured successfully.
Local Memory & Report Storage
- 1. Save report as PDF to INLINECODE92
- Maintain index
~/.crab-catch/reports/index.json:
INLINECODE94
Report Output
Use REPORT_TEMPLATE.md as the report structure.
Report philosophy: curated intelligence, not data dump
The report should be concise and decision-oriented. The reader wants to know:
is this project trustworthy? What are the risks? Where do the claims fall apart?
Five pillars of the report (in order of importance):
- 1. Contradictions & anomalies — where different sources tell different stories.
This is the most valuable content. Twitter says X, website says Y, on-chain shows Z.
- 2. Claim verification — systematic test of every official statement.
What the project claims vs what the code/chain actually shows.
- 3. Fund flow analysis — where the money goes.
Deployer → holders → exchanges. Insider patterns, circular flows, cash-outs.
- 4. Proactive testing — DApp functionality, website integrity, code security.
Does the product work? Is the website legit? Are there backdoors in the code?
- 5. Security findings — contract risks, code trojans, permission hazards.
ABI dangerous functions, proxy patterns, obfuscated code.
What to omit: routine data that confirms nothing special. If a metric is normal,
don't list it. If a claim checks out cleanly, a single ✅ row is enough — no paragraph.
Only expand on findings that change the reader's decision.
Section constraints
Must keep — always present, fixed order:
- - Header (project name + timestamp)
- 📌 Basic Information (flexible rows — agent adds/removes based on data, no fixed schema)
- 🧠 Core Findings (with Executive Summary)
- 📝 Conclusion & Verdict
- 📂 References
Default keep — user can request to skip:
- - 🛡️ Verification & Cross-Reference (Claim / Contradictions / Disputes / Gaps)
- ⚠️ Risk Warning
Data-dependent — skip if no data:
- 👤 Team & Key Figures
- 💻 GitHub Analysis
- ⛓️ On-chain Security
- 📈 Social Signals
- 📅 Project Timeline
Formatting rules
Citation system (mandatory, like academic papers):
- - Every factual claim MUST have
[[N]](url) citation - No source = mark as ⚠️ Unverified, NOT stated as fact
- Sequential numbering, first appearance order
- Bidirectional: every
[[N]] ↔ References entry
Other:
- - Numbers: K / M / B; prices:
$ prefix - Highlight high-risk signals (honeypot, high tax, upgradable contracts)
- Data Coverage note when sources unavailable
- DYOR disclaimer
- Output language matches user input; default zh-CN
技能名称：Crab Catch
Crab Catch — 研究技能编排
前置条件
CLAWBOT 必须在会话开始时运行以下命令（不仅仅是阅读它们）：
bash
which agent-browser || npm install -g agent-browser
agent-browser install
数据源
CLAWBOT 是研究驱动者——负责分析、判断、迭代和报告生成。以下 API、脚本和工具仅作为数据获取方法。
API 基础 URL：https://crab-skill.opsat.io
签名认证
除 /api/health 外的所有 API 请求都需要 Crab 签名头。
- 1. 在会话开始时运行一次 node skills/scripts/crab-sign.js 以获取 JSON 格式的请求头。
（首次运行会自动生成凭据；若缓存的签名在 24 小时内仍有效，则重复使用。）
- 2. 存储输出结果，并将以下四个请求头附加到所有后续 API 请求中：
X-Crab-Timestamp、X-Crab-Signature、X-Crab-Key、X-Crab-Address。
- 3. 仅当 API 返回 auth_expired 时，使用 --refresh 重新运行。
Twitter 与社交数据（完整参数见 twitter-analysis/SKILL.md）
| 类别 | 关键端点 | 目的 |
|---|
| 资料 | /api/twitter/user、tweets、replies | 基本信息、内容、互动 |
| 风险信号 |
/api/twitter/deleted-tweets、follower-events | 已删除内容、关注/取消关注模式 |
| 回复线程 | /api/readx/tweet-detail-conversation-v2 | 主要评论来源（快速、原始数据） |
| 引用推文 | /api/readx/tweet-quotes | KOL 评论、带上下文的社区意见 |
| 互动数据 | /api/readx/tweet-detail-v2 | 浏览量/来源——检测机器人刷量 |
| 已删除内容 | /api/readx/tweet-results-by-ids | 批量获取已删除推文快照 |
| 长文 | /api/readx/tweet-article | 以文章形式发布的技术分析、路线图 |
| 关系 | /api/readx/following-light、friendships-show | 核心圈子、团队关系验证 |
| 可信度 | /api/twitter/kol-followers、/api/readx/user-verified-followers | 可信用户关注了谁（verified-followers 需要 user_id 而非用户名） |
| 搜索 | /api/twitter/search、/api/readx/search2 | 风险信号、争议、社区讨论 |
GitHub 代码（见 github-analysis/SKILL.md）
本地脚本 skills/scripts/github_analyze.js —— 无外部 API。
convertToMarkdown(url, options) 或 analyzeRepository(url, options)。
链上数据（见 onchain-audit/SKILL.md）
币安 API —— address + chainName（大写：BSC/ETHEREUM/BASE/SOLANA）：
| 端点 | 描述 |
|---|
| /api/onchain/audit | 合约审计（双源） |
| /api/onchain/token-info |
代币元数据与市场动态 |
| /api/onchain/wallet | 钱包持仓（仅限 BSC/BASE/SOLANA） |
| /api/onchain/token-search | 代币搜索（需要 keyword） |
Bitget API —— chain + contract（小写：bnb/eth/base/sol）：
| 端点 | 描述 |
|---|
| /api/onchain-2/token-info | 代币详情 |
| /api/onchain-2/token-price |
代币价格 |
| /api/onchain-2/tx-info | 交易统计 |
| /api/onchain-2/liquidity | 流动性池信息 |
| /api/onchain-2/security-audit | 安全审计 |
链上浏览器 API —— chain + address（完整参数见 API_EXPLORER.md）：
| 端点 | 链 | 描述 |
|---|
| /api/explorer/contract | ETH、BSC | 合约 ABI、源代码、编译器信息、代理检测 |
| /api/explorer/token-history |
ETH、BSC、SOL | 带分页的代币转账历史 |
| /api/explorer/sol-address | SOL | SOL/SPL 余额 + 近期转账记录 |
网站内容（见 agent-browser/SKILL.md）
CLAWBOT 使用 agent-browser CLI 打开和检查网站。
语言偏好
输出语言与用户输入语言一致；默认为中文（zh-CN）。
原始 API 数据（用户名、代码、地址、链标识）保持原样。
编排流程
回调驱动：每个模块的输出会触发其他模块的查询。
模块之间持续相互馈送，直到没有新的高价值线索为止。
用户提供 URL / 代码 / 合约地址 + 研究意图
│
▼
步骤 1 — 解析输入，初始化实体队列
提取：Twitter 链接、GitHub 仓库、合约地址、代码、链
聚合器 URL → 从路径中提取实体（见下方规则）
初始化：
entity_queue = [{ entity, type, depth: 0 }]
processed = set()
claims = [] # 待验证的官方声明
fund_trace = [] # 待追踪资金流的地址
team_members = [] # { handle, role, source }
MAX_DEPTH = 2
│
▼
步骤 2 — 多模块数据收集
While entity_queue 不为空：
pop → 跳过如果已处理或 depth > MAX_DEPTH → 按类型路由：
URL → 2a 网站
Twitter → 2b 社交
GitHub → 2c 代码
Contract → 2d 链
Ticker → 2d 先进行 token-search
每个模块完成后：提取新实体 → 以 depth+1 加入队列
（完整路由见下方跨模块回调总结）
── 2a. 网站探索 ──────────────────────────────────
使用 agent-browser CLI（命令见 agent-browser/SKILL.md）。
agent-browser 渲染 JS、捕获交互元素，并允许点击浏览页面——对于 DApp 测试和动态网站至关重要。
仅在 agent-browser 失败时（例如安装问题）回退到 WebFetch。
按顺序访问页面：
首页 → 文档/白皮书 → 团队/关于 → DApp → 代币经济学 → 页脚
从每个页面提取：
- 官方声明 → 追加到 claims[]（由 X 审计、供应量 1 亿、
去中心化、LP 锁定、合作伙伴关系等）
- 团队名称 + 社交链接 → team_members[] + 加入 2b 队列
- 合约地址 → 加入 2d 队列
- GitHub 仓库 → 加入 2c 队列
DApp 主动测试（关键调查步骤）：
- 通过 agent-browser 打开 DApp，等待加载
- UI 渲染的是真实数据还是仅模拟外壳？
- 核心功能是否可见且可交互？
- 检查网络请求：API 是否损坏？是否存在可疑的外部调用？
- 如果 DApp 显示链上值 → 与 2d 数据交叉验证
- 截图作为证据
安全检查：SSL、域名年龄、重定向、可疑弹窗。
回退：空白页面/Cloudflare → 使用 --headed 重试。无网站 → 标记为风险。
── 2b. 社交数据收集（Twitter） ─────────────────────
目的：收集项目声明、发现团队、寻找社区争议。
非调查核心——为 2a/2c/2d 提供验证输入。
对于项目官方账号：
1. /api/twitter/user + tweets + replies + deleted-tweets（并行）
2. 选择 1-2 条高价值推文 → conversation-v2 + quotes
3. /api/readx/following-light → 从关注列表中识别团队成员
（互相关注、简介提及项目、仅发布项目相关内容的较新账号）
→ 添加到 team_members[]，
