Architecture & Design Philosophy
April 27, 2026 · View on GitHub
The two-skill split
The skills are deliberately split into methodology ("how to think") and arsenal ("what to reach for"). This reflects two different mental modes practitioners use:
- Methodology mode — "I have a target. How do I approach this?" → strategic + procedural.
- Arsenal mode — "I need a Swagger probe path / secret regex / curl one-liner." → tactical + reference.
A single mega-skill of ~5,500 lines would have noisier triggering and worse retrieval. The split lets each skill have a tight, distinct trigger vocabulary.
flowchart TD
U["USER ASKS:<br/><i>'How do I find an origin behind Cloudflare?'</i>"]
M["📘 methodology §27<br/>technique catalog + confidence rules"]
A["🛠️ arsenal §16.15<br/>actual curl commands"]
O["✅ Composed answer"]
U --> M
U --> A
M --> O
A --> O
style U fill:#3b82f6,color:#fff
style M fill:#1e293b,color:#f1f5f9
style A fill:#7c2d12,color:#fef3c7
style O fill:#14532d,color:#dcfce7
Most prompts pull both. They're complementary, not overlapping.
Confidence model
Every assertion carries a graded confidence level:
flowchart LR
T["🟡 TENTATIVE<br/>1 source · inferred pattern"]
F["🟠 FIRM<br/>2+ sources OR direct observation"]
C["🟢 CONFIRMED<br/>verified + multiple independent corroborations"]
T -->|+ corroborating evidence| F
F -->|+ verification| C
style T fill:#ca8a04,color:#fff
style F fill:#ea580c,color:#fff
style C fill:#16a34a,color:#fff
Per-asset-type upgrade workflows in methodology §2.1 specify exactly what evidence moves an asset between levels.
Severity model
Severity is operational, anchored on examples. The methodology rubric (§9) defines tiers:
flowchart TD
CRIT["🔴 CRITICAL<br/>Pre-auth RCE · valid creds · listable prod data · trust violations"]
HIGH["🟠 HIGH<br/>Sourcemap · open GraphQL introspection · takeover · reflected CORS+creds · exposed admin UI"]
MED["🟡 MEDIUM<br/>Missing headers · info disclosure · hardening gaps · brute-force exposure"]
LOW["🟢 LOW<br/>Cosmetic · marginal hardening"]
INFO["⚪ INFO<br/>Recordable · no immediate action"]
CRIT --> HIGH --> MED --> LOW --> INFO
style CRIT fill:#7f1d1d,color:#fff
style HIGH fill:#9a3412,color:#fff
style MED fill:#a16207,color:#fff
style LOW fill:#15803d,color:#fff
style INFO fill:#475569,color:#fff
The arsenal severity matrix (§40) provides 80+ worked examples for triage. Escalation rules cover special cases (HSTS missing on /login → MED→HIGH, etc.).
Detectability model
Every probe carries a detectability tag:
flowchart LR
L["🟢 LOW<br/>Passive sources<br/>CT logs · Wayback · Shodan InternetDB · Hunter.io"]
M["🟡 MEDIUM<br/>Targeted probes<br/>user-enum · validator queries · GraphQL probes · screenshots"]
H["🔴 HIGH<br/>Active scans<br/>port scans · Nuclei full templates · web fuzzing · brute-force"]
L --> M --> H
style L fill:#15803d,color:#fff
style M fill:#a16207,color:#fff
style H fill:#7f1d1d,color:#fff
The detection-aware probing section (methodology §6.4) provides the back-off ladder for when you start hitting active defenses.
Asset graph model
flowchart TD
Domain["🌐 Domain"]
Subdomain["🔗 Subdomain"]
IP["📡 IP"]
ASN["🏢 ASN"]
WebApp["💻 WebApp"]
ApiSpec["📜 ApiSpec"]
Secret["🔑 Secret"]
Email["📧 Email"]
Person["👤 Person"]
Breach["💥 Breach"]
Domain -->|ALIAS_OF / RESOLVES_TO| Subdomain
Subdomain -->|RESOLVES_TO| IP
IP -->|IN_NETBLOCK| ASN
Subdomain -->|HOSTED_ON| ASN
Subdomain -->|EXPOSES| WebApp
WebApp -->|DOCUMENTED_BY| ApiSpec
WebApp -->|CONTAINS_SECRET| Secret
Secret -->|BREACHED_FROM| Breach
Breach -->|CONTAINS| Email
Email -->|EMPLOYED_BY| Person
style Domain fill:#1e40af,color:#fff
style Subdomain fill:#1e40af,color:#fff
style IP fill:#0891b2,color:#fff
style ASN fill:#0891b2,color:#fff
style WebApp fill:#7c3aed,color:#fff
style ApiSpec fill:#7c3aed,color:#fff
style Secret fill:#dc2626,color:#fff
style Breach fill:#dc2626,color:#fff
style Email fill:#ea580c,color:#fff
style Person fill:#ea580c,color:#fff
29 asset types organized in 9 categories. 23 typed edges. Discipline: every discovery is a typed asset (never a free-floating string), with provenance tracked.
Output schema
Findings are structured for ingestion by asset-management tools:
Finding:
id: <stable hash or UUID>
module: <which technique discovered it>
asset_key: <typed asset key, e.g., sub:api.example.com>
category: <e.g., SECRET_LEAK, OPEN_GRAPHQL_API, SSO_EXPOSURE>
severity: critical | high | medium | low | info
confidence: confirmed | firm | tentative
title: <one-line summary>
description: <2-5 sentences>
evidence:
url: <where it was found>
timestamp: <UTC ISO8601>
sha256: <hash of any artifact>
raw: <truncated to 2 KiB>
references:
- <CVE-ID, advisory URL, vendor doc>
remediation: <action the asset owner can take>
This shape is portable to any asset / findings store (ASM platforms, ticketing systems, custom DBs).
Cross-module sidecar coordination
When techniques produce outputs that feed other techniques, sidecar JSON files enable late binding:
flowchart LR
M["📱 mobile_attack_surface"] -->|writes| J["📄 mobile_endpoints.json"]
J -->|reads| A["🔌 api_discovery"]
style M fill:#7c3aed,color:#fff
style J fill:#475569,color:#f1f5f9
style A fill:#7c3aed,color:#fff
Patterns documented in methodology §24.2.
Validator discipline
Credential validators are read-only by design. Never destructive.
flowchart LR
D["🔍 Discovery<br/><i>catalog regex</i>"]
V["✅ Validation<br/><i>read-only<br/>/me · /user · auth.test</i>"]
S["🗺️ Scope-enum<br/><i>read-only<br/>IAM · repo · workspace</i>"]
A["🎯 Attack-path-hint<br/><i>operator pivots from here</i>"]
D --> V --> S --> A
style D fill:#1e40af,color:#fff
style V fill:#15803d,color:#fff
style S fill:#7c3aed,color:#fff
style A fill:#9a3412,color:#fff
9 providers covered (Postman, AWS, GitHub, Slack, Anthropic, OpenAI, npm, Atlassian, DataDog). Hard rule: never create / delete / send. Tag every validation with detectability + checked_at.
Trigger frontmatter discipline
Each skill declares ~50–110 trigger phrases in YAML frontmatter. Triggers are:
- The exact wording a user would type (
kubelet exposed, notKubernetes Kubelet API exposure on port 10250). - Inclusive of common synonyms (
SSO discovery,IdP fingerprinting,tenant fingerprintingall map to identity-fabric work). - Domain-specific jargon (
JARM,mmh3,BGP,KEV). - Operator slang (
grease the rails,pop the recon).
Versioning
Semantic versioning. The version: field in YAML frontmatter is authoritative.
- MAJOR — section renumbering, breaking trigger changes, schema changes to Finding output.
- MINOR — new sections, new techniques, expanded catalogs.
- PATCH — typo fixes, link updates, severity-tier corrections.
Current: 2.1.
Renumbering policy
When new top-level sections are added in a minor release, existing sections may renumber. The CHANGELOG records mappings (e.g., "v2.0 §27 Self-Test → v2.1 §32 Self-Test").
Subsection numbering is generally additive (§7.6 added without renumbering §7.5).
What's deliberately excluded
By design, the skills do NOT cover:
- Active exploitation (PoC code, exploit chains)
- Post-exploitation (lateral movement, privesc, persistence)
- Active Directory (BloodHound, Kerberoasting, SMB relay)
- Malware development (payload crafting, AV/EDR evasion)
- C2 frameworks (Cobalt Strike, Sliver, Mythic, Havoc)
- Real PII / credentials / breach corpus content in examples
- Defensive / blue-team detection content (different domain)
- Pricing / NDA / SOW templates (business operations, not technical)
These exclusions are intentional. A "comprehensive offensive security" skill would be a textbook, not a focused tool. We'd rather do one thing well than many things adequately.
Engagement-platform agnostic
These skills are extracted from operational tradecraft accumulated across external attack-surface engagements. The 90+ modules generalize to any OSINT engagement and slot into any ASM / ticketing / asset-graph platform you already use — or none.
Use the skills standalone (paste a SKILL.md into a Claude Project) or wired into your own pipeline.