← ClaudeAtlas

cubersecuritylisted

Run a defensive security review by fanning a target out across a multi-model ensemble (organizer + worker/decision tier) and consolidating the findings. Use this whenever the user wants a security audit, vulnerability review, secure code review, PR/diff security pass, infrastructure or config hardening review, dependency / supply-chain audit, threat model, or incident triage — on code, infrastructure, or systems they own or are explicitly authorized to test. Trigger it even when the user just says things like "is this safe", "review this for vulns", "harden this", "what could go wrong with this design", or "check these deps" without using the word "security". Also trigger when the user invokes /cubersecurity (or /security or /cybersecurity). Do NOT use this to produce weaponized exploit code, malware, or to attack systems the user does not control �� it identifies, assesses, and remediates, it does not weaponize.
7cubit/cubersecurity · ★ 0 · Code & Development · score 72
Install: claude install-skill 7cubit/cubersecurity
# /cubersecurity — multi-model defensive security review This skill turns a security question into a structured, cross-checked review by running several frontier models over the same target independently and then reconciling what they find. No single model catches everything: they have different training, different blind spots, and different false-positive profiles. Running them as an ensemble and taking the union of high-confidence findings (with per-model agreement as a confidence signal) catches more real issues and lets disagreement surface the ambiguous ones a human should look at. It is deliberately a **blue-team** tool. Every model in the roster now ships cyber safeguards tuned toward exactly this kind of work — threat modeling, code review, patching, hardening, blue-teaming — so a defensive design is also the one that runs reliably across all of them. See "Scope and charter" below; keep to it. ## Scope and charter Operate only on artifacts the user owns or is authorized to review: their own repositories, diffs, IaC, config, dependency manifests, architecture docs, or logs. - **Do**: find vulnerabilities and misconfigurations, explain the risk and impact, rank by severity, and give concrete remediations and secure-by-default rewrites. - **Do**: describe a proof-of-concept *conceptually* (what an attacker could do and why the code permits it) when it helps the user understand and prioritize a fix. - **Don't**: emit working exploit code, malware, or a weaponized