Claude Skills by annatchijova

Treat the CI/CD pipeline as a privileged execution environment that runs attacker-influenceable code with production credentials — not as configuration — because a build step is arbitrary code execution holding the keys to deploy, and the pipeline sits inside your trust boundary while rarely being modeled as an attack surface. Use whenever the subject is a build/deploy system: "is our CI secure", "GitHub Actions / GitLab CI / Jenkins pipeline", "a PR can run our workflow", "secrets in the run...

Run an AUTHORIZED, collaborative purple-team exercise — turn each attack technique into a detection hypothesis, detonate it minimally and marked, and measure whether the blue side prevented it, detected it, or missed it entirely. Use this whenever the user wants to validate detection coverage, test whether a control or alert actually fires, close the loop between offensive testing and defensive telemetry, map findings to MITRE ATT&CK, or plan/run/write up a purple exercise. Trigger even when ...

Treat a backup you have not proven restorable and untampered as a hope, not a recovery plan — because the backup is inside the blast radius (same domain credentials, same network, same admin), and ransomware operators delete or encrypt backups before they detonate, so "we have backups" answers a question you did not ask. Use whenever recovery or backups are the subject: "we have backups so we're fine", "ransomware recovery", "can we restore", "backup strategy", "how fast can we recover", "are...

Adversarial security auditing and red-teaming of your own systems with strict epistemic discipline. Use this skill whenever the user is red-teaming, doing a security audit, adversarial review, threat modeling, or "trying to break" their own code or system; whenever they ask you to find bugs, vulnerabilities, invariant violations, or architectural fractures; whenever they want to audit another agent's audit or check whether a finding is real; and whenever a report labels something "CONFIRMED /...

Write the report that actually gets the class fixed — survivable in a triage queue of forty, severity scored to the demonstrated impact instead of inflated, framed so that closing your instance does not close the underlying pattern, and followed through until the patch is verified against the class and not merely against your payload. Use whenever a confirmed finding goes to whoever can fix it: a vendor security team, a bug bounty program, an internal owning team, a maintainer, or several ven...

Find the places in your own code where a small input buys a large amount of work or memory, and bound them — input-controlled loops and allocations, super-linear algorithms, catastrophic regex backtracking, decompression and expansion ratios, unbounded fan-out and retries, and missing backpressure. Use whenever writing or reviewing code that sizes anything from an untrusted value, and whenever a system falls over under load rather than under attack. Trigger on "ReDoS", "zip bomb", "billion la...

Reconstructing how an undocumented, closed, or unfamiliar system works when you do NOT have its design — a binary, a network protocol, a file or wire format, an undocumented or third-party API, a firmware image, a memory dump, an opaque database, or a model whose behavior you can only infer from inputs and outputs. Use whenever the user asks to reverse engineer, decode, decompile, disassemble, sniff, or figure out an unknown format/protocol/binary/API; infer an undocumented schema or wire for...

Reason about integrity you cannot verify from inside the thing you are verifying — a compromise below your vantage point is invisible because it controls what you see, so a bootkit that owns UEFI or SPI flash shows a spotless OS to every OS-level scanner, and trust must be anchored to a root below the layer that could lie. Use whenever integrity, boot, or attestation is the question: "is this machine clean", "detect a bootkit / rootkit / UEFI implant", "Secure Boot", "measured boot", "TPM att...

Treat credentials as a lifecycle — issued, scoped, distributed, used, rotated, revoked — with redaction enforced at the boundary and rotation rehearsed before it is needed. Use whenever a secret is created, read, passed, logged, printed, committed, or exposed: API keys, tokens, passwords, private keys, connection strings, webhook signing secrets, service accounts. Trigger on "store this API key", "put it in the env", "we committed a secret", "rotate the credentials", ".env", "vault", "the tok...

Deliberate, security-first software construction that assumes a hostile user rather than an ideal one. Use this skill whenever code is being designed, written, extended, refactored, or reviewed before merge — features, endpoints, APIs, parsers, auth, file/DB/network/subprocess handling, schemas, architecture decisions — and whenever tests are being written, fixed, or reported. Threat model before file layout, trust boundaries before modules, fail closed by default, contract before diff, and t...

Reason about attacks that exploit human trust rather than a software flaw — where the target made a locally reasonable decision on deliberately crafted context, and no patch fixes it because the "vulnerability" is a person doing their job. Use whenever the vector is a human: "was this phishing", "how did they fall for it", "analyze this pretext", "why did the user click / wire the money / reset the password", "is this email a scam", "vishing / smishing / BEC", "social engineering assessment",...

Disciplined modification of existing, legacy, inherited, or unfamiliar code — change without breakage, deletion without regret. Use this skill whenever the user asks to modify, refactor, clean up, simplify, modernize, migrate, or delete existing code; fix a bug in code they (or you) did not write; upgrade a dependency or framework; remove "dead" code, "unnecessary" checks, or "old" workarounds; understand why a strange piece of code exists; or work inside any codebase that predates the curren...

Push counting, summing, and grouping into the database instead of loading rows to tally them in application code; replace per-item queries inside loops with one batched query; and cap any result set that can grow without bound. Use this whenever code reads from a database to compute a statistic, whenever a loop issues one query per element (the N+1 pattern), whenever an endpoint returns "all" of something, and whenever a function that runs on a hot path (every request, every tick, every recal...

Apply changes to existing source files by anchored, verified, reversible patches instead of rewriting whole files. Use this whenever you are about to edit, refactor, or modify an existing file programmatically; when applying a patch, diff, or change set proposed by an auditor or another model; when doing find-and-replace across a repo; or any time you would otherwise overwrite a file from memory or from a snapshot. This is especially important in AI-assisted coding, where the single largest s...

Build and verify append-only logs that prove no entry was altered, inserted, reordered, or dropped after the fact — a hash chain where each entry seals the previous one. Use this whenever you build or review an audit trail, ledger, chain of custody, provenance record, or any append-only log that could later be challenged; whenever you need to detect tampering rather than just record events; and whenever someone says "audit log", "tamper-evident", "tamper-proof", "hash chain", "ledger", "prove...

Resist the pull to name an actor — attribution is the most overinterpreted act in security, and every signal that points at APT-X (shared hash, reused C2, a Cyrillic string, a compile timezone) is evidence of contact between datasets, not identity of hands, and most of it is cheap to plant. Use whenever an investigation starts reaching for a name: "this looks like APT29 / Lazarus / a Russian group", "same actor as last time", "the TTPs match", "shared infrastructure", "attribute this campaign...

Read network traffic as evidence to be interpreted under two hard limits — you usually cannot see the payload (encryption) and rare is usually benign (base rates) — never as a verdict on its own; beaconing, JA3/JA4 fingerprints, timing, volume, and destination reputation are weak signals whose meaning lives in baseline and context. Use whenever a network observation is being read for intent: "this host is beaconing", "periodic connection to an unknown IP", "is this C2", "the JA3 matches a mal...

Get determinism in machine learning where it is actually achievable — the artifact, not the process — by pinning data version, materialized split, code, resolved config, environment and hardware into a sealed manifest, naming the irreducibly nondeterministic parts instead of pretending they are absent, and labeling the reproducibility claim at the level the evidence supports. Use whenever a model is trained, compared, registered, or deployed, whenever two runs disagree, and whenever a result ...

Hunt the gap between the features a model was trained on and the features it is actually served — two implementations of one computation, a value that is complete offline and partial online, preprocessing shipped separately from the model, and the silent default that fills in a failed feature so the model answers confidently on a vector it never saw. Use whenever a model is deployed, whenever a feature pipeline exists in more than one place, and whenever offline and online results disagree. T...

Examine a hostile artifact as what it is — a live adversary you invited onto your desk — with two invariants: never let it execute where it can reach anything real, and never confuse what it CAN do (capability) with what it DID or was aimed at (intent). Use whenever a suspicious binary, script, document, archive, APK, container image, or captured payload is in hand and someone wants to know what it is: "analyze this malware", "is this file malicious", "what does this sample do", "detonate thi...

Validate untrusted inputs at the edge of the system — with a clear error raised at the boundary — instead of letting bad shape, bad dtype, non-finite values, or hostile paths explode deep inside a library or propagate as silent corruption. Use this whenever code ingests data from outside its own control — deserialized tensors/arrays, file paths from a caller, parsed JSON, anything fed to numpy/pandas/a parser, anything that becomes a filesystem operation. Triggers — an opaque numpy broadcast ...

Turn one disclosed or found bug into a family: extract the violated invariant, hunt the same class across shared deps and sibling sinks, and check dedupe/fix-coverage before filing.

Stamp every serialized artifact with a schema version and evolve the format over time without breaking data that was already persisted — detect the version on load, migrate old shapes forward, and keep readers for old versions working. Use this whenever you design or change a serialization format (JSON, SQLite rows, pickle, .npy), whenever you load data that an older version of the code may have written, whenever you add or remove a field from something already on disk, and whenever a "load" ...

Treat "zero trust" as a per-request property to be verified, not a product you bought or a network you segmented — the honest question is always "trusted to do what, verified how, on every request", and the failure is the implicit trust that survives the architecture diagram: a flat network behind the VPN, a service mesh that authenticates identity but never authorizes the action, an internal API that trusts any caller who reached it. Use whenever "zero trust" is claimed, designed, or bought:...