agentleFS
Sign inStart free
hypnguyen1209hypnguyen1209/offensive-claude/skills/scope-discipline/SKILL.md

scope-discipline

Skill401 starsChanged 54 days agoMITView on GitHub

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

7 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use control-flow-clarity, hal-and-abstractions and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • uxjuliaSkill

    control-flow-clarity

    Branching and state-modeling clarity in C/C++. Use when writing or refactoring logic that branches on discrete values: if/else-if ladders, status flags, mode or state ints, or anything that should be an enum plus an exhaustive switch. Covers enum class over magic ints, exhaustive switch over nested if, early-return guard clauses, table dispatch, and when each is the right call.

    Also in 3 projects that use this

  • uxjuliaSkill

    hal-and-abstractions

    Layering and abstraction discipline for the firmware. Use when touching storage, input, display, settings, i18n, or rendering, or any code that could reach into the SDK. Covers routing through the HAL (HalStorage / HalGPIO / HalDisplay) instead of raw SDK classes, MappedInputManager logical buttons instead of raw GPIO indices, UITheme/GUI for all rendering, the singleton macros, tr() for user-facing text, and where a new abstraction boundary belongs.

    Also in 3 projects that use this

  • +2 more from uxjulia

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    The Iron Law: No target without authorization: Every target you touch must be inside the written authorization, encoded in scope.json.

    line 10
  2. Distinctive:

    Before touching ANY target, confirm it is in scope:

    line 19

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

ExcuseReality
"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. You own every request the toolkit sends.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free