code-recon
Skill12 starsChanged 9 months agoMITView on GitHub
Build comprehensive architectural understanding through ultra-granular code analysis. Designed for security auditors, code reviewers, and developers who need to rapidly understand unfamiliar codebases before diving deep. CodeRecon is a systematic approach to codebase reconnaissance that builds layered understanding from high-level architecture down to implementation details. Inspired by Trail of Bits' audit-context-building methodology. Before you can find vulnerabilities, you need to understand: - How the system is architected - Where data flows - What the trust boundaries are - Where security-critical…
- Reads credentials
1 other project uses a version of this.
Adopted by
Most recently taken up by
- HexBen123/skillstheir own version, first seen Jun 22, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- HexBen123/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository81 other files it gives its agents.
- ab-test-setupSkill
- agent-browserSkill
- analytics-trackingSkill
- brainstormingSkill
- browser-useSkill
- c4-architectureSkill
- competitor-alternativesSkill
- copy-editingSkill
- copywritingSkill
- crafting-effective-readmesSkill
- dflowSkill
- drift-protocolSkill
- email-sequenceSkill
- enterprise-readinessSkill
- epub-translateSkill
- example-skillSkill
- form-croSkill
- free-tool-strategySkill
- git-workflowSkill
- heliusSkill
- hugging-face-cliSkill
- hugging-face-tool-builderSkill
- hugging-face-evaluationSkill
- hugging-face-paper-publisherSkill
- kaminoSkill
- launch-strategySkill
- magicblockSkill
- marketing-ideasSkill
- marketing-psychologySkill
- mermaid-diagramsSkill
- meteoraSkill
- hugging-face-model-trainerSkill
- n8n-code-javascriptSkill
- n8n-code-pythonSkill
- n8n-expression-syntaxSkill
- n8n-mcp-tools-expertSkill
- n8n-node-configurationSkill
- n8n-validation-expertSkill
- n8n-workflow-patternsSkill
- obsidian-vault-managerSkill
- onboarding-croSkill
- openai-knowledgeSkill
- page-croSkill
- paid-adsSkill
- paywall-upgrade-croSkill
- pinocchio-developmentSkill
- popup-croSkill
- pricing-strategySkill
- programmatic-seoSkill
- raydiumSkill
- referral-programSkill
- remotion-best-practicesSkill
- schema-markupSkill
- seo-auditSkill
- signup-flow-croSkill
- skill-boilerplateSkill
- social-contentSkill
- solana-agent-kitSkill
- solana-kit-migrationSkill
- solana-kitSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Before you can find vulnerabilities, you need to understand:
- Distinctive: line 35
Start broad, go deep systematically.
- Distinctive: line 133
Look for common patterns:
- Distinctive: line 288
Search for security-sensitive operations:
- Distinctive: line 477
Top-down approach: - Start broad, go narrow
- Distinctive: line 479
Question assumptions: - Verify what docs say vs.
- Distinctive: line 481
Time-box phases: - Don't get stuck in the weeds early
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CodeRecon - Deep Architectural Context Building
Build comprehensive architectural understanding through ultra-granular code analysis. Designed for security auditors, code reviewers, and developers who need to rapidly understand unfamiliar codebases before diving deep.
Overview
CodeRecon is a systematic approach to codebase reconnaissance that builds layered understanding from high-level architecture down to implementation details. Inspired by Trail of Bits' audit-context-building methodology.
Why CodeRecon?
Before you can find vulnerabilities, you need to understand:
- How the system is architected
- Where data flows
- What the trust boundaries are
- Where security-critical logic lives
This skill provides a structured methodology for building that context efficiently.
The Recon Pyramid
┌─────────────┐
│ DETAILS │ ← Implementation specifics
─┼─────────────┼─
/ │ FUNCTIONS │ ← Key function analysis
/ ─┼─────────────┼─
/ │ MODULES │ ← Component relationships
/ ─┼─────────────┼─
/ │ ARCHITECTURE│ ← System structure
/ ─┼─────────────┼─
/ │ OVERVIEW │ ← High-level understanding
─────────┴─────────────┴─────────Start broad, go deep systematically.
Phase 1: Overview Reconnaissance
1.1 Project Identification
Gather basic project information:
# Check for documentation
ls -la README* ARCHITECTURE* SECURITY* CHANGELOG* docs/
# Identify build system
ls package.json Cargo.toml go.mod pyproject.toml Makefile
# Check for tests
ls -la test* spec* *_test* __tests__/
# Identify CI/CD
ls -la .github/workflows/ .gitlab-ci.yml Jenkinsfile .circleci/1.2 Technology Stack Detection
# Language distribution
find . -type f -name "*.py" | wc -l
find . -type f -name "*.js" -o -name "*.ts" | wc -l
find . -type f -name "*.go" | wc -l
find . -type f -name "*.rs" | wc -l
find . -type f -name "*.sol" | wc -l
# Framework indicators
grep -r "from flask" --include="*.py" | head -1
grep -r "from django" --include="*.py" | head -1
grep -r "express\|fastify" --include="*.js" | head -1
grep -r "anchor_lang" --include="*.rs" | head -11.3 Dependency Analysis
# Python dependencies
cat requirements.txt pyproject.toml setup.py 2>/dev/null | grep -E "^\s*[a-zA-Z]"
# Node.js dependencies
cat package.json | jq '.dependencies, .devDependencies'
# Rust dependencies
cat Cargo.toml | grep -A 100 "\[dependencies\]"
# Go dependencies
cat go.mod | grep -E "^\s+[a-z]"1.4 Create Technology Map
## Technology Map: [PROJECT NAME]
### Languages
| Language | Files | Lines | Primary Use |
|----------|-------|-------|-------------|
| Python | 150 | 25K | Backend API |
| TypeScript | 80 | 12K | Frontend |
| Solidity | 12 | 2K | Smart Contracts |
### Key Dependencies
| Package | Version | Purpose | Security Notes |
|---------|---------|---------|----------------|
| fastapi | 0.100.0 | Web framework | Recent CVEs: None |
| web3.py | 6.0.0 | Blockchain client | Check signing |
| pyjwt | 2.8.0 | JWT handling | Verify alg checks |
### Infrastructure
- Database: PostgreSQL 15
- Cache: Redis 7
- Message Queue: RabbitMQ
- Container: Docker + K8sPhase 2: Architecture Mapping
2.1 Directory Structure Analysis
# Top-level structure
tree -L 2 -d
# Identify entry points
find . -name "main.py" -o -name "app.py" -o -name "index.ts" -o -name "main.go"
# Identify config
find . -name "config*" -o -name "settings*" -o -name ".env*"2.2 Component Identification
Look for common patterns:
project/
├── api/ # HTTP endpoints
├── auth/ # Authentication
├── core/ # Business logic
├── db/ # Database layer
├── models/ # Data models
├── services/ # External services
├── utils/ # Utilities
├── workers/ # Background jobs
└── tests/ # Test suite2.3 Create Architecture Diagram
┌─────────────────────────────────────────────────────────────┐
│ CLIENTS │
│ (Web, Mobile, API Consumers) │
└─────────────────────────┬───────────────────────────────────┘
│ HTTPS
▼
┌─────────────────────────────────────────────────────────────┐
│ API GATEWAY │
│ (Rate Limiting, Auth) │
└─────────────────────────┬───────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Auth │ │ Core │ │ Admin │
│ Service │ │ API │ │ API │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────────────┼──────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Database │ │ Cache │ │ External │
│ (Postgres)│ │ (Redis) │ │ APIs │
└──────────┘ └──────────┘ └──────────┘2.4 Trust Boundary Identification
Map where trust levels change:
## Trust Boundaries
### Boundary 1: Internet → API Gateway
- **Type:** Network boundary
- **Controls:** TLS, Rate limiting, WAF
- **Risks:** DDoS, Injection, Auth bypass
### Boundary 2: API Gateway → Services
- **Type:** Authentication boundary
- **Controls:** JWT validation, Role checks
- **Risks:** Token forgery, Privilege escalation
### Boundary 3: Services → Database
- **Type:** Data access boundary
- **Controls:** Query parameterization, Connection pooling
- **Risks:** SQL injection, Data leakage
### Boundary 4: Services → External APIs
- **Type:** Third-party integration
- **Controls:** API keys, Request signing
- **Risks:** SSRF, Secret exposurePhase 3: Module Deep Dive
3.1 Entry Point Analysis
For each entry point type:
# HTTP Routes - map all endpoints
grep -rn "@app.route\|@router\|@api_view" --include="*.py"
grep -rn "app.(get|post|put|delete)\|router.(get|post)" --include="*.ts"
# CLI Commands
grep -rn "@click.command\|argparse\|clap" --include="*.py" --include="*.rs"
# Event Handlers
grep -rn "@consumer\|@handler\|on_message" --include="*.py"3.2 Create Entry Point Map
## Entry Points
### HTTP API
| Method | Path | Handler | Auth | Input |
|--------|------|---------|------|-------|
| POST | /api/login | auth.login | None | JSON body |
| GET | /api/users | users.list | JWT | Query params |
| POST | /api/transfer | tx.transfer | JWT + 2FA | JSON body |
| GET | /admin/logs | admin.logs | Admin JWT | Query params |
### WebSocket
| Event | Handler | Auth | Data |
|-------|---------|------|------|
| connect | ws.connect | JWT | None |
| message | ws.message | Session | JSON |
### Background Jobs
| Queue | Handler | Trigger | Data Source |
|-------|---------|---------|-------------|
| emails | email.send | API call | Database |
| reports | report.gen | Cron | Database |3.3 Data Flow Tracing
For each critical endpoint, trace data flow:
POST /api/transfer
│
▼
┌──────────────────┐
│ Request Parser │ ← Validate JSON schema
│ (validation.py) │
└────────┬─────────┘
│ TransferRequest
▼
┌──────────────────┐
│ Auth Middleware │ ← Verify JWT, extract user
│ (middleware.py) │
└────────┬─────────┘
│ User context
▼
┌──────────────────┐
│ Transfer Service │ ← Business logic
│ (transfer.py) │
└────────┬─────────┘
│
┌────┴────┐
▼ ▼
┌────────┐ ┌────────┐
│ DB │ │External│
│ Write │ │ API │
└────────┘ └────────┘Phase 4: Function-Level Analysis
4.1 Security-Critical Function Identification
Search for security-sensitive operations:
# Authentication
grep -rn "def login\|def authenticate\|def verify_token" --include="*.py"
grep -rn "function login\|authenticate\|verifyToken" --include="*.ts"
# Authorization
grep -rn "def is_authorized\|def check_permission\|@requires_role" --include="*.py"
# Cryptography
grep -rn "encrypt\|decrypt\|hash\|sign\|verify" --include="*.py"
grep -rn "crypto\.\|bcrypt\|argon2" --include="*.py"
# Database
grep -rn "execute\|query\|cursor" --include="*.py"
grep -rn "\.query\|\.execute\|\.raw" --include="*.ts"
# File Operations
grep -rn "open\(.*\)\|read\|write\|unlink" --include="*.py"4.2 Function Documentation Template
For each critical function:
### Function: `transfer_funds()`
**Location:** `services/transfer.py:45`
**Purpose:** Execute fund transfer between accounts
**Parameters:**
| Name | Type | Source | Validation |
|------|------|--------|------------|
| from_account | str | JWT claim | UUID format |
| to_account | str | Request body | UUID format, exists check |
| amount | Decimal | Request body | > 0, <= balance |
**Returns:** TransferResult
**Side Effects:**
- Writes to `transactions` table
- Calls external payment API
- Emits `transfer_completed` event
**Security Considerations:**
- Requires authenticated user
- Rate limited to 10/minute
- Amount validated against balance
- Audit logged
**Potential Risks:**
- Race condition if concurrent transfers?
- What if external API fails mid-transfer?4.3 Call Graph Analysis
transfer_funds()
├── validate_request()
│ └── check_uuid_format()
├── get_user_balance()
│ └── db.query()
├── check_rate_limit()
│ └── redis.get()
├── execute_transfer() ← CRITICAL
│ ├── db.begin_transaction()
│ ├── update_balance() ← State change
│ ├── external_api.send() ← External call
│ └── db.commit()
└── emit_event()Phase 5: Detail Reconnaissance
5.1 Configuration Analysis
# Find all config loading
grep -rn "os.environ\|getenv\|config\." --include="*.py"
grep -rn "process.env\|config\." --include="*.ts"
# Check for hardcoded secrets
grep -rn "password\s*=\|secret\s*=\|api_key\s*=" --include="*.py"
grep -rn "-----BEGIN\|sk-\|pk_live_" .5.2 Error Handling Review
# Find exception handling
grep -rn "except.*:" --include="*.py" -A 2
grep -rn "catch\s*(" --include="*.ts" -A 2
# Find error responses
grep -rn "return.*error\|raise.*Error" --include="*.py"5.3 Logging Analysis
# Find logging statements
grep -rn "logger\.\|logging\.\|console\.log" --include="*.py" --include="*.ts"
# Check what's being logged
grep -rn "log.*password\|log.*token\|log.*secret" --include="*.py"Output: Context Document
Template
# [PROJECT NAME] - Security Context Document
## Executive Summary
[2-3 sentences on what this system does]
## Technology Stack
[From Phase 1]
## Architecture
[Diagram from Phase 2]
## Trust Boundaries
[From Phase 2.4]
## Entry Points
[Table from Phase 3.2]
## Critical Functions
[Analysis from Phase 4]
## Data Flows
[Diagrams from Phase 3.3]
## Security Controls
| Control | Implementation | Location | Notes |
|---------|----------------|----------|-------|
| Authentication | JWT | middleware/auth.py | RS256 signing |
| Authorization | RBAC | decorators/auth.py | Role-based |
| Input Validation | Pydantic | schemas/*.py | Type checking |
| Encryption | AES-256-GCM | utils/crypto.py | At-rest |
## Areas Requiring Focus
1. [High-risk area 1]
2. [High-risk area 2]
3. [High-risk area 3]
## Open Questions
- [ ] How is X handled when Y?
- [ ] What happens if Z fails?Quick Start Commands
# Full recon script
./scripts/recon.sh /path/to/project
# Generate entry point map
./scripts/map-endpoints.sh /path/to/project
# Create call graph
./scripts/callgraph.sh /path/to/projectSkill Files
code-recon/
├── SKILL.md # This file
├── resources/
│ ├── recon-checklist.md # Comprehensive checklist
│ └── question-bank.md # Questions to answer
├── examples/
│ ├── web-app-recon/ # Web application example
│ └── smart-contract-recon/ # Smart contract example
├── templates/
│ └── context-document.md # Output template
└── docs/
└── advanced-techniques.md # Deep dive techniquesGuidelines
- Top-down approach - Start broad, go narrow
- Document everything - Your notes are the deliverable
- Question assumptions - Verify what docs say vs. what code does
- Focus on trust boundaries - That's where bugs live
- Time-box phases - Don't get stuck in the weeds early
- Iterate - Revisit earlier phases as you learn more
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

