gungnir

name	gungnir
description	Attack your own system — under explicit authorization — to prove its defenses hold, before launch and continuously after: scope and authorize, recon, scan and enumerate, exploit and confirm real vulnerabilities (not scanner false positives), chain them into real impact, then report and re-test. The offensive half of the security pair (the spear) that proves what the `aegis` skill builds (the shield). Authorized, defensive penetration testing of systems you own or have written permission to test — never anything else. Use when the user wants to penetration-test their own application before launch, validate a fix actually closed a hole, stand up adversarial validation in CI or on a cadence, or learn to test for OWASP-class vulnerabilities on their own staging. Triggers on "pentest my app / attack my own system", "red-team my staging", "is this actually exploitable", "pre-launch security test".
argument-hint	[your own / authorized target to attack — a staging system or lab]
allowed-tools	Read Bash Edit Write

gungnir

!checklist init ${CLAUDE_SKILL_DIR} --force

The single most valuable security mindset is to think like an attacker and actively try to break your own system — because a defense is only ever proven by a real attack, never by a clean scan or a green test. This skill is the spear: authorized, adversarial penetration testing of a system to prove (or disprove) that the defenses the aegis skill built actually hold. It drives a real attack through its whole arc — scope, recon, scan, exploit, chain, report — across six gated stages, and it will not advance past a GATE until the checklist tool clears it.

The one hard boundary, gated first and never crossed: you attack only a system you own or have explicit, written authorization to test. Attacking anything else — a third-party service, a system you don't own, infrastructure outside the agreed scope — is out of bounds, full stop, regardless of intent. This skill is for authorized, defensive validation: your own staging environment, a system you've been contracted to test in writing, or a deliberately-vulnerable practice lab. STAGE 0 makes that authorization a hard gate, and it is the one gate that is never a judgment call.

Adversarial validation is where the agent era cuts both ways, and both edges matter:

• The agent can now actually run the attack — nmap, sqlmap, an intercepting proxy — which makes continuous self-attack cheap and real. That capability is exactly why the authorization gate must be absolute: a tool that can find a hole can point at the wrong target, and the agent feels no instinct about whose system it is.
• The agent shares the blind spots of whoever built the system. If the design, the code, and now the attack are all done by agents, they share a training distribution and an imagination — so an agent attacking a system it (or a sibling) built will miss the same things it missed building it. Agreement is not evidence. Real assurance needs independent angles, and on the highest-stakes systems, a genuinely independent (human) tester.
• The agent runs a scanner, sees an empty result, and declares "secure." A clean scan means known patterns weren't found — it is necessary and nowhere near sufficient. The creative work — chaining small flaws into a real exploit, abusing business logic no scanner understands — is exactly what the agent is weakest at and what this skill exists to force.

So the rule that governs this skill: a defense is proven only by a real, authorized attack — a clean scan is not proof — and you attack only what you are permitted to. The goal is not to "pass"; it is to find the holes while they are still cheap to fix.

Discipline: finish every GATE before the next stage. GATEs are hard — never skip, batch past, or self-certify a stage you have not done. The checklist tool enforces the order; let it. Commands address stages by name.

Read references/agent-era-shifts.md first — it is the heart: what adversarial testing becomes when the attacker is an agent that shares the defender's blind spots, can run the tools, and will mistake a clean scan for a secure system. If $ARGUMENTS is trivial and has nothing worth attacking, this machinery is overkill — say so.

Speak the user's language, and confirm the authorization out loud. This skill needs the user to set the scope, confirm ownership/authorization, and own the disposition of every finding. Read their fluency and gloss a term on first use (penetration test vs scan, recon, IDOR, injection, privilege escalation, scope, rules of engagement). A user who cannot confirm, plainly, that this target is theirs to attack has not authorized it — and STAGE 0 does not clear.

The reference library

The depth lives in references/. Open each when a stage sends you there — not all upfront. Eight references back the six stages:

• references/decision-tree.md — the engine. The authorization gate, the spectrum of adversarial validation (scan → self-test → independent pentest → bug bounty / red team), how deep to attack by risk, the scan-vs-exploit / confirm-vs-false-positive call, and the escalation ladder. Open it at the start.
• references/agent-era-shifts.md — the must-be-told reference: how adversarial testing changes when the attacker is an agent. Load at the start, re-check at every gate.
• references/scope-and-authorization.md — the absolute first gate: ownership/written authorization, in-scope vs out-of-scope targets, rules of engagement, a safe (staging, snapshotted) environment, and cloud-provider testing policy.
• references/recon-and-enumeration.md — the depth behind both STAGE 1 (Recon) and STAGE 2 (Scan): mapping the attack surface (passive recon, nmap port/service scanning, tech-stack fingerprinting, content/directory discovery with ffuf/gobuster to find what isn't linked), then the automated scan layer that turns the map into a candidate list (DAST vuln scanner, a Burp/ZAP proxy crawl of every parameter, version-based known-CVE checks) — framed as suspects, never a verdict.
• references/exploitation-by-class.md — testing the OWASP Top 10 hands-on: broken access control / IDOR, injection (sqlmap), auth/session, XSS, misconfiguration, sensitive-data exposure, SSRF/CSRF — and confirming a real finding vs a scanner false positive.
• references/chaining-and-impact.md — the creative core a scanner can't do: chaining small flaws into a real attack, business-logic abuse, and post-exploitation (lateral movement, privilege escalation, what data is reachable) to show true impact — plus why agent-shared blind spots demand independent angles.
• references/report-fix-retest.md — the only part that creates value: record, rank by severity, drive the fix (aegis / husbandry), and re-test to verify it's closed; plus making adversarial validation continuous, not a one-time gate.
• references/tools-and-practice.md — the standard toolkit (nmap, Burp Suite / OWASP ZAP, ffuf/gobuster, sqlmap, Metasploit, trivy), the standards (PTES, OWASP Testing Guide & ASVS), and legal practice labs (OWASP Juice Shop, DVWA, WebGoat) to build the skill safely.

---

STAGE 0 — Scope & authorize (the gate that is never a judgment call)

Open references/scope-and-authorization.md. Before any packet is sent, establish — and have the user confirm — that this is a system they own or are explicitly, in writing, authorized to test, and pin the boundaries:

• In scope vs out of scope — the exact domains/IPs/applications to test, and everything that is off-limits (above all, third-party services and dependencies you do not own — never attack a system you merely depend on).
• Rules of engagement — what techniques are allowed (e.g. exclude denial-of-service / stress testing unless explicitly agreed), the window, and who to contact.
• A safe environment — attack a staging/pre-production environment that mirrors prod, snapshotted/backed up first, never production with real user data; an attack can corrupt data or take a service down.
• Provider policy — if it runs on a cloud provider (AWS/GCP/Azure), confirm their penetration-testing policy; some test types require prior notice.

If ownership/authorization cannot be confirmed in writing, stop — this gate does not clear, and no later stage runs. This is the one non-negotiable gate in the whole suite.

GATE — clear before RECON

1. checklist check scope scope-and-authorization-locked
2. checklist verify scope

---

STAGE 1 — Recon (map the attack surface)

Open references/recon-and-enumeration.md. You cannot attack what you haven't mapped. Within the authorized scope, enumerate the surface: which endpoints, ports, and services are exposed; what technology stack and versions are in use; and — critically — the content that isn't linked from the UI but still exists (a forgotten /admin, a /backup, a stale API). Use nmap for ports/services and a content-discovery tool (ffuf/gobuster) for hidden paths. The aegis skill's threat model, if one exists, is your map of where to look hardest.

GATE — clear before SCAN

1. checklist check recon attack-surface-mapped
2. checklist verify recon

---

STAGE 2 — Scan & enumerate (cast the wide net)

Open references/recon-and-enumeration.md. Run the automated layer over the mapped surface: a vulnerability scanner, a web proxy crawl (Burp Suite / OWASP ZAP) of every page and API parameter, and version-based checks for known-CVE components. This produces the candidate list — the suspicious points to investigate. Hold the line internalized from the start: a scanner finds known patterns; it does not prove exploitability, and an empty scan is not a secure system. Scanning is the floor, not the verdict.

GATE — clear before EXPLOIT

1. checklist check scan scanned-and-enumerated
2. checklist verify scan

---

STAGE 3 — Exploit (confirm what's real, by class)

Open references/exploitation-by-class.md. Now actually try to exploit the candidates — because the value is in confirming a vulnerability is genuinely exploitable, not a scanner's guess. Work the OWASP Top 10 by class against your own system, always from the attacker's core assumption — the app will trust whatever input I give it — and feed each input point the unexpected:

• Broken access control / IDOR (highest-yield, easiest to self-test): log in as two ordinary users; change a resource ID in a URL or request to another user's and see if you get their data; hit an admin endpoint with a normal account.
• Injection: enter a single quote ' and watch for a database error; then use sqlmap against the parameters that react. Test command and NoSQL injection the same way.
• Auth & session: weak-password acceptance, brute-force protection, token expiry after logout, HttpOnly/Secure cookies, lingering default credentials.
• XSS: put a harmless probe script in a field that gets reflected and see if it executes rather than displays as text.
• Misconfiguration / sensitive data: exposed debug endpoints, verbose errors leaking internals, public buckets, plaintext transport, secrets in responses or logs.

Confirm each finding (a real exploitation or a clear, reproducible proof) and discard the false positives.

GATE — clear before CHAIN

1. checklist check exploit exploited-not-just-scanned
2. checklist check exploit owasp-classes-attacked
3. checklist verify exploit

---

STAGE 4 — Chain & show impact (the part a scanner can't do)

Open references/chaining-and-impact.md. A pentest's real worth — and the thing automation cannot replicate — is creatively chaining several small flaws into one real attack, abusing business logic no scanner understands, and doing post-exploitation to show true impact: if you got in, how far can you move laterally, can you escalate privilege, what data can you actually reach? A "low-severity" info leak plus a "low-severity" weak reset can chain into full account takeover. This is also where agent-shared blind spots bite hardest: an agent attacking a system agents built will overlook the same logic it overlooked building it — so deliberately take independent angles (and on a high-stakes system, get a genuinely independent human tester), because agreement is not evidence.

GATE — clear before REPORT

1. checklist check chain chained-and-impact-shown
2. checklist verify chain

---

STAGE 5 — Report, fix & re-test (the only part that creates value)

Open references/report-fix-retest.md. A penetration test report, by itself, is worth nothing — the value is the closed loop. For every confirmed finding: record it with a clear reproduction and rank it by severity (impact × exploitability). When you are attacking your own deployment of software you did not author, rank by a second axis too — would a correctly-hardened deployment still have it? A flaw that survives auth-on, least-exposure, strong-secrets, and a current version is the product's, not your config's, and ranks above anything correct deployment would have erased. Then drive the fix — a deployment-owned finding you close yourself (defense via the aegis skill, change via husbandry); a product-owned finding in code you do not maintain takes a different loop, coordinated disclosure to the maintainer, re-tested against their patched release. And re-test to verify the hole is actually closed — a fix you never re-attacked is a hope. A report that sits in a drawer with nothing fixed is the same as never having tested.

And make it continuous: a one-time pre-launch attack is stale within weeks, because new vulnerabilities are disclosed daily and every change can open a new hole. The pre-launch attack is the capstone, not the only event — layer it on automated scanning every commit (the aegis/flightline gates), re-attack after major changes, and on the highest-stakes systems, ongoing independent testing or a bug-bounty program.

FINAL GATE

1. checklist check report findings-fixed-and-retested
2. checklist check report validation-made-continuous
3. checklist verify report
4. checklist show — confirm all six stages passed.
5. checklist done — clear this run's state.

---

The thread through all of it

gungnir is the spear, and it exists to prove the shield: it attacks what the aegis skill builds, because a defense untested by a real attack is only an assumption — the same "an unrehearsed control is not a control" the stationkeeping skill insists on, pointed at security. The two are a matched pair: aegis weaves defense through the lifecycle; gungnir adversarially validates it. For an agent the lever cuts twice: it can finally run the attack itself (so make validation continuous), but it shares the defender's blind spots and mistakes a clean scan for safety (so demand independent angles and real exploitation, never just a green scanner) — and it can point a real weapon at the wrong target, which is why authorization is the one absolute gate. Find the holes while they are cheap; fix them; attack again.

Anti-patterns (use as a pre-flight checklist)

• Attacking anything unauthorized — the one unforgivable error; only your own or explicitly-permitted systems, never a third party.
• Testing in production with real data — use a snapshotted staging mirror; an attack can corrupt or take down.
• Scan = pentest — a clean scanner is necessary, never sufficient; the exploit chain and logic flaw are what it misses.
• Stopping at the first wall — real attackers are persistent and creative; assume the input is trusted and try the unexpected.
• Agent attacking what agents built, alone — shared blind spots; take independent angles, agreement is not evidence.
• A report nobody acts on — worthless; the value is fix-and-re-test, the closed loop.
• A fix never re-attacked — an unverified fix is a hope; re-test every closed finding.
• One-and-done — a single pre-launch pentest is stale fast; make adversarial validation continuous.
• Skipping a GATE — especially STAGE 0; the authorization gate is never a judgment call.