Claude Skills by annatchijova

Software engineering best practices grounded in C.S. Peirce's abductive reasoning and his triadic framework (abduction–deduction–induction, sign–object–interpretant, Firstness–Secondness–Thirdness). Use this skill whenever the user is debugging a defect, investigating an incident or outage, doing root cause analysis, reviewing code, writing a postmortem, naming things (variables, APIs, services), making architectural or design decisions under uncertainty, or asks for a rigorous/scientific/hyp...

Collect digital evidence in order of volatility, or destroy the thing you came for — memory, network state, and running processes evaporate the moment you pull power or start "just looking," and the act of collecting alters the scene, so order and method are the evidence's admissibility, not a formality. Use whenever evidence is being captured from a live or suspect system: "acquire the disk", "grab a memory dump", "should we pull the plug or shut down gracefully", "image this machine", "coll...

Design LLM and agentic systems so that retrieved content is data and never instruction — instruction authority comes from the channel, tool authority is granted by deterministic policy before the model runs, and the untrusted-content + private-data + external-egress trifecta is never unmediated. Use whenever an LLM reads something it did not write: RAG over documents, web browsing, email/ticket/PR triage, tool or MCP output, file contents, another agent's output, or user-supplied text that re...

Triage a security alert queue by expected loss, not by the severity label the tool stamped — because analyst attention is a scarce, exhaustible resource and a SOC's real failure is not a missed rule but a queue that trains its analysts to dismiss. Use whenever there is a backlog of alerts to prioritize, a "we get 10,000 alerts a day" problem, a decision about which detections to keep, or a claim that a queue is "under control": "which alerts do we work first", "we're drowning in alerts", "ale...

Start from "this step already succeeded" and map what the attacker reaches next — the identity held at that position, everything that identity unlocks, and the choke point whose removal cuts the most paths at once. Use whenever a finding is confirmed and the question turns to impact, whenever a design assumes a component will not be compromised, and whenever containment is being planned or claimed. Trigger on "what's the actual impact", "assume this is compromised", "blast radius", "lateral m...

Make a logical operation that spans several writes to persistent state land all-or-nothing, isolated from concurrent writers, with dependents cleaned up in the same transaction. Use this whenever one conceptual operation involves multiple writes — insert-then-delete, merge, consolidate, migrate, move-across-tables, write-plus-cascade — and a crash or a concurrent writer between steps would leave the store inconsistent; and whenever you hit "database is locked", duplicated rows after a merge, ...

Enumerate the attack surface of an AUTHORIZED target and rank it into a reproducible, falsifiable candidate queue — reachability × asset value × technique plausibility — before anyone touches a payload. Use whenever the user asks "where should we start", "what's our attack surface", "what should we test first", "map the exposure", "prioritize these findings", "which endpoints matter", or hands over a recon dump, an asset inventory, a subdomain list, an OpenAPI spec, or a pile of scanner outpu...

Validate any audit finding, bug report, or proposed fix against the actual current file content before changing a single line. Use this whenever you act on a problem someone else reported — a human reviewer, another AI auditor, a linter, a security scan, a "the audit found X in file Y" message — and whenever you are about to apply a patch or change set you did not personally derive from reading the live file. Triggers — "the auditor flagged", "apply this fix", "the review said", "another mode...

Build the actor × resource × action matrix a system implicitly claims to enforce, then test the cells it never wrote a test for — because authorization bugs are absences, and you cannot grep for an absence. Use whenever a system has more than one kind of user, more than one tenant, or any object with an owner — multi-tenant SaaS, admin panels, org/team/workspace models, RBAC or ABAC policy, sharing and invitation flows, API keys with scopes, service accounts, feature flags that gate privilege...

Audit the bug fixes themselves — a patch proves that someone knew something was wrong there, never that it is now right. Hunt the eight ways a fix falls short: it covers the demonstrated input instead of the property, one path instead of every path, the wrong layer, the symptom instead of the cause, nothing enforcing it against the next caller, a new bug introduced by the rushed diff, siblings left unpatched, or a fix that has since decayed. Use whenever a fix, patch, advisory, CVE, changelog...

Look past the obvious layer of an investigation — past sink-grep keyword lists, past the exhausted question family, past the single implementation where a bug class was first found. Use whenever a hunt is anchored on dangerous-function greps (eval, subprocess, open), when the scanner's output is being treated as the map, when a confirmed bug could exist in sibling implementations or languages, when second opinions or other models hand over leads, or when the user says "no obvious vulns", "onl...

Tracking and preserving the origin of every assertion as it travels through drafts, handoffs, summaries, and documents — ensuring confidence levels, scope bounds, and evidence pointers are never stripped in transit. Use whenever findings move between people or phases: postmortems, incident briefs, audit handoffs, executive summaries, escalation chains, or review cycles. Trigger when a finding is paraphrased without citing its source, when a confidence level disappears in a rewrite, when "it w...

Treat any code or data that runs on a device the user controls as code and data the adversary controls — the mobile app, the single-page app, the desktop client, the game — because the user can root the phone, hook it with Frida, bypass the certificate pin, read the "encrypted" local database, and patch out any check you shipped, so a security decision made client-side is a suggestion, never a control. Use whenever the subject is a client that runs on hardware you do not own: "is it safe to s...

Reason about cloud compromise on the identity and control-plane graph, not the network diagram — because in cloud the control plane is an internet-reachable API authorized by credentials, it sits beside the data plane rather than above it behind a firewall, and a stolen key is one AssumeRole from the whole account. Use whenever the system is AWS/Azure/GCP/Kubernetes and the question is attack path, blast radius, privilege escalation, or "how bad is this": an SSRF that can reach the metadata e...

Systematic assessment of a codebase's living, dead, and fossil modules — scan, categorize, prioritize, act. Use when the user says "audit the codebase", "find dead code", "what can we delete", "clean up the repo", "module archaeology", "codebase health", "what's unused", "technical debt inventory", or when a project has accumulated enough history that nobody is sure which modules are live and which are orphaned. Also trigger when the user asks "is this module still used?", "why do we have two...

Reason about concurrent execution in terms of shared mutable state, invariants, and happens-before ordering — not in terms of "adding a lock" or "it works on my machine". Use whenever code can run more than once at a time: threads, async tasks, goroutines, workers, multiple processes or replicas, retries, webhooks, cron jobs, signal handlers, or a user who double-clicks. Trigger on "race condition", "thread-safe", "add a mutex", "deadlock", "it only fails under load", "it worked locally", "th...

Treat a container as isolation, not as a security boundary — because "it runs in a container" is not "it is contained": it shares the host kernel, and the real perimeter is the kernel attack surface it can reach, the provenance of the image it was built from, the orchestration identity it holds, and the escape surface it was granted. Use whenever the system is Docker/Kubernetes/containerd and the question is blast radius, isolation, or "is this safe to run": a compromised or untrusted contain...

Make containment decisions before scope is known, reasoning in reversible-versus-irreversible moves — because acting tips off the adversary (they burn down, accelerate, or pivot) while not acting lets the bleed continue, and "we don't fully understand it yet" must never quietly become "so we did nothing." Use in an active incident when the question is what to do now with incomplete information: "should we isolate the host", "pull it off the network", "rotate all credentials", "rebuild or watc...

Distinguish a control that exists from a control that works — because compliance attests existence ("MFA is enabled") while security requires effectiveness ("MFA that cannot be phished or bypassed on this path"), and the checkbox is passed by the presence of the control, not by its resistance to the threat it names. Use whenever a control is being claimed, audited, or trusted: "we're compliant", "we have MFA / EDR / a WAF / DLP", "we passed SOC2", "the control is in place", "is this control e...

Turn "we found a credential" into a finding by triaging what the material actually is, what it authenticates as, what it authorizes, for how long, and how to revoke it — because a Slack webhook and a long-lived cloud root key are both "a secret" and differ by orders of magnitude in blast radius. Use whenever secret material surfaces: a leaked key in a git commit or CI log, a password/hash dump, a captured Kerberos ticket, an OAuth access or refresh token, a session cookie, an SSH or signing k...

Judge a cryptographic system by how it is used, not by which primitive it names — because "we use AES-256" says nothing, and almost every real-world break is a misuse (reused nonce, ECB, unauthenticated ciphertext, a padding oracle, a homemade KDF, an accepted downgrade) sitting on top of a perfectly good algorithm. Use whenever crypto is being designed, reviewed, or trusted: "is this encryption secure", "we roll our own", "AES/RSA/we're fine", "how should I encrypt this", "sign then encrypt ...

Hunt the one bug class in machine learning whose symptom is a better score — information from the evaluation set reaching the model through preprocessing, time, groups, duplicates, features derived from the label, or a test set spent on tuning. Use whenever a dataset is split, a pipeline is fitted, a feature is engineered, a benchmark is reported, or a model performs suspiciously well. Trigger on "data leakage", "target leakage", "train/test contamination", "the accuracy is 99%", "too good to...

You cannot protect, delete, or report on data whose flow you have not mapped — a "delete my data" request, a breach-scope estimate, or a "we don't store PII" claim is only as true as your knowledge of where the data actually went, and it always went further than the schema says: into backups, logs, caches, analytics, data warehouses, search indexes, third-party processors, exports, and derived features. Use whenever the question is where sensitive data lives or goes: "handle this DSAR / right...

Writing reports, documentation, findings, and explanations that survive cross-examination — separating fact from inference, admitting uncertainty without weakening the conclusion, never overclaiming. Use this skill whenever the user is writing or reviewing a report, audit deliverable, postmortem, technical doc, executive summary, research writeup, forensic or expert-style analysis, README claims, or any prose that asserts findings; whenever they ask to "write up the results", "document this",...

Design deception so that a triggered decoy is a true positive by construction — a honeytoken, honeypot, or canary earns its keep only if nothing legitimate ever touches it, which turns "someone touched it" into signal with a near-zero false-positive rate, the inverse of every noisy detection you own. Use whenever deception is being built or evaluated: "let's plant a honeytoken", "set up a honeypot", "canary tokens", "decoy credentials / files / AWS keys", "tripwire", "we deployed a deception ...

Capture a technical decision while the context still exists — the forces at the time, the alternatives and why each was rejected, the assumption it rests on, its reversibility, and the condition that should reopen it. Use whenever a choice is being made that someone will later have to live with or undo: picking a library, a data model, a protocol, a boundary, a deployment topology; accepting a tradeoff or a known limitation; choosing NOT to build something; adding a workaround, a retry, a mag...

Know what you actually run, where it came from, and what changed — manifest vs lockfile vs installed vs shipped, identity before trust, pinning by digest, and vulnerability reports treated as candidates until reachability is shown. Use whenever a dependency enters, moves, or is questioned: "add this package", "npm/pip/cargo install", "upgrade this library", "bump the version", "dependabot opened 40 PRs", "we have a critical CVE", "is this package safe", "vendor this", "update the base image",...

Turn a detection requirement into a deployed, tested, versioned rule — with a benign twin that must NOT fire, an explicit false-positive budget, a volume estimate before deploy, and a tuning history that records every silently narrowed scope. Use whenever the user writes or reviews an alert, a Sigma/KQL/SPL/EQL/YARA rule, a SIEM correlation search, a WAF or EDR policy, an anomaly threshold, or a monitor that pages someone; whenever they say "write a rule for this", "alert when X", "we're gett...

Keep any consequential output path reproducible bit-for-bit and tamper-evident — no floats in the decision path, canonical typed serialization, SHA-256 sealing, and a determinism check. Use this whenever you build or review code that produces a verdict, score, decision, risk number, classification, or any result that will be audited, sealed, hashed, or relied on as evidence; whenever a hash changes between runs and shouldn't; whenever floating-point arithmetic sits anywhere near a result that...

Disciplined diagnosis loop for hard bugs and performance regressions — build a tight feedback loop FIRST, then hypothesize, never the reverse. Use when the user says "diagnose"/"debug this"/"why does this fail"/"it's broken"/"it's slow", or reports something throwing/failing/flaky/wrong. Complements abductive-engineering (which supplies the reasoning framework — A-D-I loop, semiotic triad) with the operational mechanics that turn that framework into a repeatable debugging process. Where abduc...

Turn a plausible hypothesis into an earned verdict with the cheapest experiment that can kill it — binary oracle with a canary value, a negative control inside the same run, prediction stated before execution, novelty gate before writing, and every link in the evidence chain labelled by epistemic level. Use whenever a security finding, bug hypothesis, or root-cause claim needs to be confirmed before reporting, when building a PoC, when the user says "prove it", "confirm the bug", "reproduce",...

Do not stop at a reproducible symptom — the gate that makes you earn the report before writing it. Name the broken invariant and its layer, sweep for variants, attack the fix you expect the maintainer to ship, map the real blast radius across shipped clients and versions, and calibrate severity against a named comparable advisory. Use whenever a finding is labeled CONFIRMED or EXPLOITABLE, a bounty report is being drafted or reviewed, or an obvious one-line fix is being assumed. Trigger on 'i...

Decide whether observed activity is malicious when the tool, command, or API call is itself legitimate — the living-off-the-land problem, where the artifact is identical for the admin and the intruder and the verdict lives entirely in context. Use whenever you must call a signal benign or malicious and the signal alone cannot settle it: PowerShell/WMI/PsExec/certutil/rundll32 execution, a valid credential used from a new location, an `AssumeRole` or `iam:PassRole` that is in-policy, RDP/SSH b...

Turn a scanner hit or a CVSS score into a real risk decision by proving, in this deployment, that the vulnerable code is reachable, reached by attacker-controlled input, and exploitable given the mitigations actually in place — because "could be exploited" is not "is exposed" and a version match is not a vulnerability. Use whenever a vulnerability needs prioritizing: "we have 4,000 criticals", "is this CVE exploitable here", "should we patch this now", "the scanner flagged", "dependabot opene...

Write tests that can actually fail, and prove it — see the test red before you trust it green, break the code deliberately as a negative control, and strengthen the oracle from "it ran" to "it is right". Use whenever tests are being written, reviewed, fixed, or relied on: "add tests for this", "write unit tests", "the tests pass", "improve coverage", "this test is flaky", "why didn't the tests catch this", "mock this out", "update the snapshot", or a PR whose diff adds test files. Also trigge...

Govern what happens to a confirmed finding once it is reported and you are not going to publish it — the difference between disclosing an instance, a mechanism, and a hunting method; the patch-diffing window that leaks the class whether or not you write a word; custody of the PoC and of any data you touched confirming it; and a written decision with a revisit trigger instead of an undocumented default. Use whenever a finding is confirmed and the question turns to who is told what, whenever a ...

Decide what to record today so that tomorrow's reconstruction is possible — derive fields from the questions someone will have to answer under pressure, log the inputs to decisions rather than only their outcomes, correlate across services, keep the event schema a versioned interface, and make silence distinguishable from outage. Use whenever logging, telemetry, or an audit trail is designed, changed, trimmed, or found wanting: "add logging", "what should we log", "observability", "structured...

Keep an investigation alive and productive when every hypothesis has been refuted, the target looks hardened, and the session feels empty — refutation is terrain mapping, pivot the question family instead of abandoning the target, and never convert "we found nothing" into "there is nothing". Use whenever a hunt, audit, or debugging session produces zero findings, when the user says "no encontramos nada", "everything was refuted", "this repo is too hardened", "let's just drop it", "we tried ev...

Protect repository history during AI-assisted and agentic coding by tagging a restore point before each session, forbidding history-rewriting operations, and verifying actual repo state before claiming anything about it. Use this whenever an AI agent (Claude Code or similar) is about to make changes to a git repository, whenever you are about to run or recommend git operations that could lose work, and whenever you are about to document or report the state of a repo. Triggers — "start a codin...

Make code that runs on degraded, legacy, reconstructed, or unverifiable input fail visibly instead of returning a plausible-but-wrong answer. Use this whenever you write or review backward-compatible deserialization, loaders for data saved by an older schema, best-effort guarantees, optional components that may be absent, health/test states that are "not quite pass", or any path that fills in a missing value — anywhere "it ran without error" could be hiding "it ran on bad data". Push to use t...

Run a threat hunt as a falsifiable hypothesis about adversary behavior, not a keyword sweep — state before you query what you expect to see if it is true, what would refute it, and what "found nothing" actually proves, which is almost always far less than the hunter wants to claim. Use whenever someone is threat hunting or proposing to: "let's hunt for lateral movement", "go look for signs of compromise", "hunt for persistence", "we should proactively search for X", "did we find anything", "t...

Build a defensible timeline of what happened from heterogeneous, imperfectly-clocked sources — separating recorded time from actual time, ordering from causation, and "no event" from "no coverage". Use whenever events from more than one source must be placed in sequence: incident response, outage postmortems, forensic investigations, breach reconstruction, distributed-system debugging across services, audit trails, or a "what happened when" question. Trigger on "build a timeline", "reconstruc...

Grade the source and the indicator before acting on either — because an indicator is not intelligence and a feed is not truth, and auto-acting on ungraded intel means blocking benign traffic, chasing decayed IOCs, and spending analyst trust on someone else's low-confidence guess. Use whenever threat intelligence arrives and something is about to act on it: "block all these IOCs", "we got a threat feed", "this indicator list from the ISAC", "is this intel reliable", "should we alert on this IO...

Hunt for violations of declared or implied security invariants across transitions — a property established at T0 (validation, authority, identity, integrity, namespace) must still hold when the effect happens at Tn. Use whenever auditing or debugging anything with state transitions, redirects, resume/checkpoint flows, approval gates, retries, batching, serialization, or multi-layer pipelines. Trigger on "the check exists but", "validated once", "re-materializes", "re-injects", "authorization ...

Classify an action by reversibility and blast radius before executing it, then require a gate proportional to what cannot be undone — preview the exact targets, assert the expected count, take a restore point, and write the undo plan before the action, not after. Use before any destructive, bulk, or outward-facing operation: rm/DROP/TRUNCATE/DELETE without a tested WHERE, mass find-and-replace, force-push or history rewrite, migrations, `terraform apply`, prod deploys, package publishes, send...

Architect any system that produces a consequential output so that the LLM stays entirely out of the decision path and only narrates an already-sealed result. Use this whenever an LLM is anywhere near a verdict, score, classification, ranking, risk number, approval, or any output that triggers an action or becomes evidence; when designing where the model "sits" in a pipeline; when someone proposes letting the model "decide", "judge", "classify", or "score"; and when you need the model to expla...

Build a model evaluation that can actually fail — a mandatory baseline, a metric that matches the decision the output feeds, an interval instead of a point estimate, a test set treated as a consumable, subgroup breakdowns that expose what the aggregate hides, and negative controls that prove the pipeline is capable of producing a bad score. Use whenever a model is evaluated, compared, promoted, or reported, and whenever a number is used to justify shipping. Trigger on "accuracy", "F1", "AUC",...

Search an input space too large to enumerate, with an oracle strong enough that the bug is visible when it is hit — property-based tests, structure-aware fuzzing, differential and metamorphic oracles, corpus and coverage discipline, shrinking, and crash triage that separates a reproducer from a finding. Use whenever bugs should be found by generated input rather than by reading — "fuzz this", "property-based", "hypothesis/quickcheck/proptest", "libFuzzer", "AFL", "differential testing", "gene...

Threat-model operational technology by inverting the IT reflexes — in OT/ICS the priority is availability and physical safety, not confidentiality, so the moves that are correct on a corporate network (patch immediately, scan aggressively, force MFA, encrypt everything) can halt a process, trip a safety system, or get someone killed. Use whenever the system controls or monitors physical process: "secure our SCADA / PLC / ICS", "OT network", "should we patch this controller", "can we run a vul...

Hunt the bugs that live where two components read the same bytes and disagree about what they mean — the validator parses one way, the executor another, and the attacker writes input that is two things at once. Use whenever a value crosses a component, language, or process boundary and is re-interpreted — proxy in front of an app server, gateway before a backend, WAF before a handler, client validation before server storage, signature verified before content is re-parsed, or one format embedd...