Route a security task to the right skill among six specialists — defensive code review, offensive/bounty vulnerability hunting, agent-config (.claude) auditing, source-asset & embedded-dependency scanning, a pre-action fact-forcing gate, and destructive-operation safety locks. USE WHEN a user wants to secure, audit, harden, or attack a codebase or an agent setup but hasn't named the specific concern.
Route a security task to the right skill among six specialists — defensive code review, offensive/bounty vulnerability hunting, agent-config (.claude) auditing, source-asset & embedded-dependency scanning, a pre-action fact-forcing gate, and destructive-operation safety locks. USE WHEN a user wants to secure, audit, harden, or attack a codebase or an agent setup but hasn't named the specific concern.
cluster
security
version
1.0.0
Security Orchestrator
The single entry skill for security work. It locates the task on the posture ×
surface map — defend vs attack against code, agent-config, or live runtime — and
delegates to one of six specialist spokes. The cross-cutting idea every spoke shares — the
trust boundary: where untrusted, attacker-controlled input or action reaches a privileged
sink, and the default-deny posture that contains it — lives in security-core; read it
before triaging a finding or deciding whether something is exploitable.
Cluster map (spoke → role)
security-review — Defensive code review. The build-time checklist: secrets management, authn/authz, input handling, API endpoints, payments, transport, plus a cloud-infrastructure-security companion. Use when writing or reviewing code that touches a sensitive surface.
security-bounty-hunter — Offensive discovery. Hunts remotely reachable, user-controlled, vulnerabilities (SSRF, auth bypass, RCE, SQLi, path traversal) and discards noisy local-only findings. Use when the question is "does this actually pay / is this reportable?".
exploitable
security-scan — Agent-config audit. Scans a .claude/ setup (CLAUDE.md, settings.json, MCP servers, hooks, agent defs) for injection, over-permissive allowlists, and supply-chain risk via the ecc-agentshield tool. Use when securing the agent harness itself.
repo-scan — Source-asset audit. Classifies every file as project / third-party / artifact, detects embedded (vendored) libraries and their versions, and emits four-level verdicts. Use to find outdated bundled OpenSSL/FFmpeg/etc. and unowned attack surface across a polyglot repo.
gateguard — Pre-action fact-forcing gate. A PreToolUse hook that blocks the first Edit/Write/Bash and demands concrete investigation (importers, data schema, the user's instruction) before allowing it. Use to stop blind, guessed changes in an autonomous loop.
safety-guard — Destructive-operation lock. Intercepts rm -rf, force-push, DROP TABLE, etc., and freezes writes to a chosen directory. Use to contain blast radius when an agent runs full-auto or on production.
These spokes extend the cluster beyond the original six — they cover the offensive recon → web/LLM testing pipeline and the threat-intelligence feeds that inform it. Route to them the same way (load on demand; see "Loading spokes on demand"):
recon — Infrastructure & network reconnaissance. Passive-by-default WHOIS/DNS/cert-transparency/ASN mapping plus authorization-gated active port/service scanning. Use to map a target's attack surface (domains, IPs, netblocks, subdomains) before testing.
osint — Open-source intelligence on people, companies, and entities/domains. Public-sources-only, authorization-first. Use for due diligence, background checks, or entity/threat-actor research; commonly hands off to recon for the technical infrastructure.
webassessment — Web application security assessment. Builds an app narrative, threat-models it, then runs a 6-phase pentest (recon → mapping → vuln analysis → exploitation → reporting) with ffuf fuzzing. Use for "pentest / security-test this web app".
promptinjection — LLM/AI application security testing. Direct, indirect (RAG/document), and multi-stage injection + jailbreak testing with an attack taxonomy and defense/remediation guidance. Use to test a chatbot or LLM feature for prompt injection. Authorized use only.
secret-scanner — Leaked-secret detection. Scans files, .env, and git history for hardcoded API keys/credentials (AWS, Stripe, GitHub tokens, etc.). Use as a fast pre-push / CI credential-exposure check (complements security-review's secrets section).
secupdates — Security news aggregation. Pulls and ranks the latest breaches, CVEs/research, and industry analysis from tl;dr sec, Krebs, THN, Schneier, etc. Use for "what's new in security / sec updates".
annualreports — Annual security-report aggregation & analysis. Indexes 570+ industry threat/AppSec/cloud/ransomware reports and synthesizes cross-vendor trends. Use to pull or analyze the threat landscape from vendor annual reports.
Audit the agent/Claude Code config → security-scan
Audit the source tree (ownership, vendored deps, dead weight) → repo-scan
Contain — live agent runtime
Force investigation before edits (quality + safety) → gateguard
Block destructive commands / freeze the writable area → safety-guard
If the ask is broad ("make this secure"), default to security-review for the code path and
offer security-scan for the agent config — they cover the two most common surfaces.
Sibling clusters (framework-native security)
This cluster owns cross-cutting security — review, scan, bounty — across any stack. When the
concern is bound to a specific framework or domain, hand off to that cluster's own security spoke:
Use those for in-framework hardening; route back here for stack-agnostic code review, config/asset scanning, or exploitability triage.
Standard flow
Place the task on posture × surface: are we defending or attacking, and is the surface code, agent-config, or runtime?
If it involves judging a finding (reachable? user-controlled? meaningful sink?), pull the trust-boundary model from security-core first — exploitability is a property of the path, not the pattern.
Delegate to the spoke(s). Multi-surface asks fan out: e.g. "harden this agent project" → security-scan (config) + security-review (code) + safety-guard (runtime lock).
Return: chosen spoke(s), the surface/posture, the severity or verdict implied, and the next action.
Guardrails
See security-core. In short: default-deny — grant the narrowest permission/scope that
works and treat any widening as a security change. Exploitability over theory — rank by
"can attacker-controlled input reach a meaningful sink?", not by lint pattern count; drop
local-only and out-of-scope noise. Contain before you trust — in autonomous runs keep
safety-guard/gateguard on. Never weaken a control silently — disabling a gate, widening
an allowlist, or adding a host is a stated decision, never a quiet one.
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
