| name | crypto-recon-plans |
| description | Use BEFORE starting any crypto recon analysis. Creates a structured investigation plan — what to find, which endpoints matter, what success looks like. Extends superpowers writing-plans for crypto domain. |
Crypto Recon — Planning Agent
Purpose
Before running the full pipeline, understand what the user actually needs. A bad plan wastes hours of analysis. A good plan targets the right 20% of code that has 80% of the crypto.
This skill extends superpowers writing-plans. The plan output guides crypto-recon-orchestrator on where to focus.
Do NOT invoke crypto-recon-orchestrator until this plan is written and shown to the user.
Do NOT skip this skill to "save time" — undirected analysis produces noise, not signal.
When to Use
- User gives a URL for the first time
- User has a specific goal ("I want to call the bet API", "I want to register an account", "I want to understand login flow")
- Target is a large app with many JS files — need to focus first
Phase 1: Understand the Goal
Ask the user (one message, all questions):
Before I start analysis, I need to understand your goal:
1. What do you want to DO with this app? (register, login, place a bet, withdraw, etc.)
2. Do you already have any clues? (API endpoints you've seen, header names, error messages)
3. What's your preferred output? (just Python functions / full working script / just understand the algo)
4. Is there a specific endpoint URL you already know?
Do not start downloading anything yet.
Phase 2: Map the Target
Based on user's answer, determine:
Primary target — what's the most important thing to find?
- Request signing function (most common)
- Login/auth flow
- Token generation
- Specific API endpoint signing
Expected findings — based on app type, predict likely stack:
Lottery/gaming app → likely MD5/HMAC signing, UUID nonce, timestamp
Crypto/DeFi app → likely ECDSA/secp256k1, keccak256, Web3
E-commerce → likely RSA public key encryption, HMAC-SHA256
Social/chat → likely JWT, AES payload encryption
Chinese-origin app → likely SM2/SM4/SM3 (Chinese standards), custom signing
File priority — which JS files to focus on first:
High priority: common.*, utils.*, api.*, request.*, auth.*
Medium priority: page-login.*, page-register.*, index.*
Low priority: page-ui.*, page-activity.*, i18n.*, vendor.*
Endpoints to manually verify — list URLs the user should open in DevTools to capture actual requests.
Phase 3: Write the Plan
Save plan to: output/[domain]/plan.md
# Analysis Plan: [domain]
**Date:** [date]
**Goal:** [user's stated goal]
## Target Summary
- App type: [gaming/fintech/social/etc]
- Expected crypto: [MD5 signing / RSA / JWT / etc]
- Primary finding needed: [signing function / login flow / etc]
## Investigation Order
### Priority 1 — Request Signing (HIGH)
Look for: sort+stringify+md5 pattern in axios interceptor
Files first: common.modules-*.js, index-*.js
Tool: python tools/scan.py output/[domain]/ --category SIGNING
### Priority 2 — Authentication
Look for: JWT creation, RSA-encrypted login, basic HMAC auth
Files first: page-login-*.js, auth-*.js
Tool: python tools/scan.py output/[domain]/ --category JWT_OAUTH
### Priority 3 — Libraries
Identify which crypto library is used — shapes all other analysis
Tool: python tools/scan.py output/[domain]/ --category LIBRARIES
## Success Criteria
- [ ] Signing function fully traced (input → output → HTTP)
- [ ] Python reconstruction runs without error
- [ ] Test request returns 200 (not 401/403)
## Known Clues
[Any info user provided — endpoint URLs, header names, etc.]
## Out of Scope
[What we're NOT trying to do — e.g., "not analyzing game logic, only signing"]
Phase 4: Handoff to Orchestrator
After plan is written and user approves:
Plan saved to output/[domain]/plan.md
Starting analysis with this focus:
Priority 1: [X]
Priority 2: [Y]
Invoking crypto-recon-orchestrator...
Then invoke crypto-recon-orchestrator, passing the plan context so specialists know which files to prioritize.
Integration with Superpowers writing-plans
This skill follows the same discipline as superpowers writing-plans:
- Always write the plan before doing work
- Plan is a contract — don't change it mid-execution without noting why
- Plans are saved to disk, not just in memory
- If scope changes during analysis, update the plan file
Key difference from generic writing-plans:
- Plan always includes expected crypto stack (based on app type)
- Success criteria always includes "test request returns 200"
- Plan drives specialist priority order in orchestrator