Gungnir
Agent-era skill suites for Claude Code: engineering lifecycle + distributed systems, gated by the checklist CLI
npx -y skills add IamK77/Skill --skill gungnirAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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".
SKILL.md
16.8 KB, as published. Nobody here has run it
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,
nmapport/service scanning, tech-stack fingerprinting, content/directory discovery withffuf/gobusterto 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
checklist check scope scope-and-authorization-lockedchecklist 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
checklist check recon attack-surface-mappedchecklist 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
checklist check scan scanned-and-enumeratedchecklist 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 usesqlmapagainst 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/Securecookies, 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
checklist check exploit exploited-not-just-scannedchecklist check exploit owasp-classes-attackedchecklist 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
checklist check chain chained-and-impact-shownchecklist 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
checklist check report findings-fixed-and-retestedchecklist check report validation-made-continuouschecklist verify reportchecklist show— confirm all six stages passed.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.