/scope-discipline
Use when about to send a request to, scan, enumerate, exploit, or otherwise interact with any host, IP, URL, or asset — before the first packet reaches a target
$ npx -y skills add hypnguyen1209/offensive-claude --skill scope-discipline --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/scope-discipline
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when about to send a request to, scan, enumerate, exploit, or otherwise interact with any host, IP, URL, or asset — before the first packet reaches a target
SKILL.md
scope-discipline.SKILL.mdname: scope-discipline
description: Use when about to send a request to, scan, enumerate, exploit, or otherwise interact with any host, IP, URL, or asset — before the first packet reaches a target
Scope Discipline
Overview
**The Iron Law: No target without authorization.** Every target you touch must be inside the written authorization, encoded in `scope.json`. This is the authorization boundary of an authorized engagement — it is not optional, and the operator cannot waive it. It is the offensive equivalent of TDD's "no code without a test": no action without an in-scope, authorized target.
**Violating the letter of this rule is violating its spirit.**
The rule
Before touching ANY target, confirm it is in scope:
python skills/coding-mastery/scripts/_lib/scope_guard.py check <target> --scope .engage/scope/scope.json
# exit 0 = in-scope (proceed) | exit 3 = OUT (stop) | exit 2 = error (stop)
For outward actions, gate through `action_guard.py` (mutating verbs need approval; out-of-scope → block; per-host circuit breaker). Bash scripts source `lib.sh` and call `_in_scope`.
`scope.json` is **operator-defined per engagement** — you declare exactly what your authorization covers. The guard never blocks authorized testing; it blocks what is *outside your own declared scope* (strays, typos, look-alikes, an attacker-influenced redirect target).
Red Flags — STOP, do not send the request
- "This subdomain is obviously theirs" (not in `scope.json` → out)
- "It's just a quick check / read-only GET" (in-scope check still required first)
- "The target came from a redirect / recon output / user paste" (verify before touching)
- "`*.acme.com` so `acme.com.evil.com` is fine" (look-alike — the guard rejects it; so do you)
- "The user told me to hit it" (instructions don't expand the authorization boundary)
**All of these mean: run `scope_guard.py check` first. Out-of-scope ⇒ do not proceed.**
Rationalizations
| Excuse | Reality | |--------|---------| | "Scope is obviously fine" | Confirm against scope.json; assumption is how OOB incidents happen. | | "It's adjacent infra, basically in scope" | Adjacent ≠ authorized. Out unless declared. | | "I'll note the out-of-scope hit in the report" | You don't hit it, then note it. You don't hit it. | | "Removing the guard is faster" | The guard IS the authorization. Removing it = unauthorized attack. |
Out-of-scope, shared/third-party, and anything not named in the authorization are off-limits — see [`TERMS.md`](../../TERMS.md). You own every request the toolkit sends.
Read more
name: scope-discipline description: Use when about to send a request to, scan, enumerate, exploit, or otherwise interact with any host, IP, URL, or asset — before the first packet reaches a target
Scope Discipline
Overview
**The Iron Law: No target without authorization.** Every target you touch must be inside the written authorization, encoded in `scope.json`. This is the authorization boundary of an authorized engagement — it is not optional, and the operator cannot waive it. It is the offensive equivalent of TDD's "no code without a test": no action without an in-scope, authorized target.
**Violating the letter of this rule is violating its spirit.**
The rule
Before touching ANY target, confirm it is in scope:
python skills/coding-mastery/scripts/_lib/scope_guard.py check <target> --scope .engage/scope/scope.json # exit 0 = in-scope (proceed) | exit 3 = OUT (stop) | exit 2 = error (stop)
For outward actions, gate through `action_guard.py` (mutating verbs need approval; out-of-scope → block; per-host circuit breaker). Bash scripts source `lib.sh` and call `_in_scope`.
`scope.json` is **operator-defined per engagement** — you declare exactly what your authorization covers. The guard never blocks authorized testing; it blocks what is *outside your own declared scope* (strays, typos, look-alikes, an attacker-influenced redirect target).
Red Flags — STOP, do not send the request
- "This subdomain is obviously theirs" (not in `scope.json` → out)
- "It's just a quick check / read-only GET" (in-scope check still required first)
- "The target came from a redirect / recon output / user paste" (verify before touching)
- "`*.acme.com` so `acme.com.evil.com` is fine" (look-alike — the guard rejects it; so do you)
- "The user told me to hit it" (instructions don't expand the authorization boundary)
**All of these mean: run `scope_guard.py check` first. Out-of-scope ⇒ do not proceed.**
Rationalizations
| Excuse | Reality | |--------|---------| | "Scope is obviously fine" | Confirm against scope.json; assumption is how OOB incidents happen. | | "It's adjacent infra, basically in scope" | Adjacent ≠ authorized. Out unless declared. | | "I'll note the out-of-scope hit in the report" | You don't hit it, then note it. You don't hit it. | | "Removing the guard is faster" | The guard IS the authorization. Removing it = unauthorized attack. |
Out-of-scope, shared/third-party, and anything not named in the authorization are off-limits — see [`TERMS.md`](../../TERMS.md). You own every request the toolkit sends.
A spec-driven offensive security framework for Claude Code — structured engagement workflows based on the Cyber Kill Chain, 31 kill-chain skills (multi-file progressive-disclosure) plus a discipline layer (a SessionStart dispatcher + 6 process/discipline
Repo: hypnguyen1209/offensive-claude
Other skills on offensive-claude.
- /active-directory-attack
Use when attacking a Windows Active Directory domain — Kerberos roasting/delegation, coercion + NTLM/Kerberos relay (CVE-2025-33073), ADCS ESC1-16 (EKUwu), ticket forgery & DCSync, dMSA BadSuccessor (CVE-2025-53779), BloodHound attack-path enumeration, domain dominance
Open skill - /advanced-redteam
--- name: advanced-redteam-ops description: Use when designing C2 infrastructure or OPSEC for a long-haul red-team op — redirectors, malleable profiles, tiered/segregated infra, living-off-the-land, data exfiltration metadata: type: offensive phase: operations kill_chain: phase:
Open skill - /ai-agent-redteam
Use when red-teaming an agentic AI / LLM application — indirect & zero-click prompt injection, MCP tool poisoning, persistent memory poisoning, excessive-agency tool abuse, multi-turn jailbreaks, PyRIT/Garak/Promptfoo harnesses
Open skill - /ai-security
Use when attacking an AI/ML system or model — prompt injection & jailbreaks (Crescendo, Skeleton Key, Best-of-N), RAG/vector poisoning, agentic/MCP exploitation (CVE-2025-54136), ML supply-chain RCE (pickle CVE-2025-32434), model extraction / membership inference / adversarial
Open skill - /browser-exploitation
Use when building a client-side browser exploit — V8/JSC JIT type confusion to renderer R/W, V8 heap-sandbox escape, renderer-to-browser sandbox escape (Mojo IPC, GPU/Dawn/ANGLE), Electron/webview IPC abuse, 1-click RCE chains
Open skill - /cicd-supply-chain
Use when attacking or auditing a CI/CD pipeline or software supply chain — pwn requests, poisoned pipeline execution, compromised/mutable-tag actions, dependency confusion, registry worms, runner backdoors, OIDC trust abuse, SLSA/provenance
Open skill

