Use when starting any offensive-security engagement or task — establishes how to find and invoke the right skill before any action (including clarifying questions, recon, exploitation, or reporting)
npx skills add https://github.com/hypnguyen1209/offensive-claude --skill using-offensive-claude
<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, skip this skill.
</SUBAGENT-STOP>
<EXTREMELY-IMPORTANT>
If there is even a 1% chance a skill applies to what you are doing, you ABSOLUTELY MUST invoke it.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. You cannot rationalize your way out of it.
</EXTREMELY-IMPORTANT>
You are operating an authorized offensive-security framework. Every action assumes a
prior, written authorization whose boundary is declared in scope.json (see scope-discipline).
User instructions say WHAT, not HOW. "Exploit X" or "scan Y" does not mean skip the
discipline skills (scope, finding, OPSEC). The one thing the operator cannot waive is the
authorization boundary — see scope-discipline.
Invoke relevant skills BEFORE any response or action. Even a 1% chance means invoke to check.
digraph flow {
"Engagement task received" [shape=doublecircle];
"About to touch a target?" [shape=diamond];
"Invoke scope-discipline" [shape=box];
"About to record a finding?" [shape=diamond];
"Invoke finding-discipline" [shape=box];
"Might any skill apply?" [shape=diamond];
"Invoke the Skill" [shape=box];
"Announce: 'Using [skill] to [purpose]'" [shape=box];
"Follow skill exactly" [shape=box];
"Engagement task received" -> "About to touch a target?";
"About to touch a target?" -> "Invoke scope-discipline" [label="yes"];
"About to touch a target?" -> "About to record a finding?" [label="no"];
"About to record a finding?" -> "Invoke finding-discipline" [label="yes"];
"About to record a finding?" -> "Might any skill apply?" [label="no"];
"Invoke scope-discipline" -> "Might any skill apply?";
"Invoke finding-discipline" -> "Might any skill apply?";
"Might any skill apply?" -> "Invoke the Skill" [label="yes, even 1%"];
"Invoke the Skill" -> "Announce: 'Using [skill] to [purpose]'";
"Announce: 'Using [skill] to [purpose]'" -> "Follow skill exactly";
}
engagement-flow (run the kill chain), scope-discipline (authorization boundary),
threat-model-discipline (model the surface + detect drift), finding-discipline (proof before
any [CONFIRMED]), opsec-discipline (detection-aware).
"Run a full pentest" → engagement-flow first. "Is this finding real?" → finding-discipline first.
| Situation | Invoke |
|-----------|--------|
| Starting / running an engagement | engagement-flow |
| About to send a request to ANY target | scope-discipline (confirm in-scope first) |
| About to record / report a finding | finding-discipline (no [CONFIRMED] without proof) |
| About to take any outward/offensive action | opsec-discipline |
| A specific technique (recon, web, AD, exploit, cloud, mobile, …) | the matching domain skill |
| Authoring a new skill for this repo | writing-offensive-skills |
| Thought | Reality |
|---------|---------|
| "This is just a quick scan" | Touching a target → scope-discipline first. |
| "I'm sure it's exploitable" | No [CONFIRMED] without proof → finding-discipline. |
| "Scope is obviously fine" | Confirm against scope.json, don't assume. |
| "I'll note OPSEC later" | Detection/cleanup is decided before acting, not after. |
| "I know this technique" | Knowing ≠ using the skill. Invoke it for the current state. |
| "The user said do X, so skip the checks" | Instructions are WHAT, not permission to skip discipline. |
Use the Skill tool with the skill name. Never use Read on skill files. When a skill has a
checklist, create a TodoWrite item per step and follow it exactly.
> FHIR REST endpoints (Patient, Observation, Encounter, Condition, MedicationRequest), (2) Validating FHIR resources and returning proper HTTP status codes and error responses, (3) Implementing SMART on FHIR authorization and OAuth scopes, (4) Working with Bundles, transactions, batch operations, or search pagination. Covers FHIR R4 resource structures, required fields, value sets (status codes, gender, intent), coding systems (LOINC, SNOMED, RxNorm, ICD-10), and OperationOutcome error handling.
Interact with ClawDirect, a directory of social web experiences for AI agents. Use this skill to browse the directory, like entries, or add new sites. Requires ATXP authentication for MCP tool calls. Triggers: browsing agent-oriented websites, discovering social platforms for agents, liking/voting on directory entries, or submitting new agent-facing sites to ClawDirect.
Shared audit integrity framework for all AppSec agents — enforces output quality, intellectual honesty, and continuous improvement through anti-rationalization guards, self-critique loops, retry protocols, non-negotiable behaviors, self-reflection quality gates (1-10 scoring, ≥8 threshold), and a self-learning system with lesson/memory governance for security analysis agents.
Opt out of the OneCLI gateway and supply Anthropic credentials from .env instead. For users who want simple .env-based credential management without the OneCLI agent vault. Reads the API key or OAuth token from .env and injects it into the container's API requests.
Cross-product Zoom reference skill. Use after the workflow is clear when you need shared platform guidance, app-model comparisons, authentication context, scopes, marketplace considerations, or API-vs-MCP routing.
>- Static source-code vulnerability scan. Reads a target directory (and THREAT_MODEL.md if present), spawns parallel review subagents per focus area, and writes VULN-FINDINGS.json + .md for /triage to consume. Read-only — no building, running, or network. For execution-verified crashes, use vuln-pipeline instead. Use when asked to "scan for vulns", "review this code for security issues", "find bugs in <dir>", or as the step between /threat-model and /triage.
Hunt Session Management vulnerabilities — session fixation (no regeneration on login), insufficient invalidation on logout / password-change / email-change, predictable or low-entropy session IDs, JWT-as-session with no exp/revocation, refresh-token rotation/reuse-detection gaps, OAuth/SSO session linkage, device-bound-session (DBSC) downgrade, and cookie attribute issues (Secure/HttpOnly/SameSite/__Host-). Validate with TWO real sessions (attacker A + victim B), body-diff every 200, and OOB confirmation for theft chains. Medium to Critical (fixation→admin hijack, no-invalidation→persistent ATO).
> Use this skill when the user is doing hands-on DOCA AES-GCM work on a BlueField DPU or ConnectX NIC — configuring `doca_aes_gcm_task_encrypt` / `_task_decrypt`, querying `doca_aes_gcm_cap_*` for per-key-type (only `DOCA_AES_GCM_KEY_128` / `_256` — AES-192 not supported) and per-task support, sizing plaintext against the max-buf cap, setting source / destination mmap permissions, validating with a NIST GCMVS or RFC 5288 vector, or debugging DOCA_ERROR_* including the security-critical tag-verification-failed outcome on decrypt. Trigger even when the user does not explicitly mention "DOCA AES-GCM" or IO_FAILED", "auth tag isn't verifying", "NOT_PERMITTED on my encrypt buffer", "is AES-192-GCM on this BlueField" (no), or "encrypted record came back tampered". Refuse and route elsewhere for non-GCM AES modes (CBC / CTR / XTS — CPU OpenSSL), key management (KMS / HSM / rotation), SHA (doca-sha), or general AEAD background.
Take hypnguyen1209/using-offensive-claude from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.