annatchijova
- 74 skills
- 0 followers
- 6 hours ago last updated
- ▌
- ▌
- ▌
- ▌
- ▌ SQL Aggregation Not Materialization · annatchijova bundlePush 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 recall) deserializes rows it does not need. Triggers — "this query is slow", "it scales with the table", "N+1", "database is the bottleneck", "the export times out", "count by", "group by", "stats endpoint". Push to use this whenever row-reading work grows with corpus size on a frequently-called path.
- ▌
- ▌ Git Discipline · annatchijova bundleProtect 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 coding session", "let the agent edit", "rebase", "squash", "force push", "clean up history", "what's the state of the repo", "commit these changes". Push to use this whenever an autonomous tool has write access to a repository, even for a small change.
- ▌
- ▌ Beyond The Sink · annatchijovaLook 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", "only hardening findings", "where else should we look", "replicate this", "check the other SDKs", "fresh eyes", "what are we missing". Trigger even when the user only pastes scanner output and asks what to do next. Sibling of attack-surface-triage — that skill ranks the surface; this one keeps the search from being scanner-shaped, single-family, and single-implementation.
- ▌
- ▌ Finding Custody · annatchijovaGovern 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 writeup, talk, blog post, CVE text, or conference submission is considered, whenever the same class exists in products nobody has reported yet, and whenever a working PoC needs somewhere to live. Trigger on "should we publish", "write it up", "embargo", "CVE text", "the vendor patched it", "can I blog about this", "who else has this bug", "where do I keep the PoC", or a finding going quiet with no record. It never argues for or against publishing; it makes the decision explicit, bounded, and revisitable.
- ▌ Surgical Patcher · annatchijova bundleApply 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 source of silent regressions is a model rewriting more than it intended. Push to use this even when the user just says "edit this file", "apply this fix", "refactor X", or "the audit found a problem in Y".
- ▌ Variant Analysis · annatchijovaTurn 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.
- ▌ Invariant Hunting · annatchijovaHunt 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 decay", "does the check survive", "who approved this", "TOCTOU", "resume", "redirect", "checkpoint", "stale state", "the property is established here but used there", or whenever a security decision is made in one layer and consumed in another. Sibling of red-team-auditing — that skill earns verdicts on candidates; this one generates the highest-yield candidates by naming the invariant the system believes it keeps.
- ▌ Red Team Auditing · annatchijovaAdversarial 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 / EXPLOITABLE / bypass" and the certainty needs to be earned rather than asserted. Trigger even if the user only says "find more", "attack this", "poke holes", "cuchi cuchi red team", or pastes an audit/finding table for review. Pairs with the abductive-engineering skill — this is its adversarial application.
- ▌ Audit Before Patch · annatchijova bundleValidate 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 model found a bug in", a diff or patch handed to you, findings from any automated tool. Push to use this even when the finding sounds authoritative and specific — confident, precise findings are exactly the ones that get applied blind.
- ▌ Deterministic Core · annatchijova bundleKeep 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 must be exactly reproducible; and whenever someone says "reproducible", "deterministic", "seal", "chain of custody", "bit-for-bit", or "Daubert". Push to use this even when the user only says "scoring", "the decision logic", or "why does the output differ between machines".
- ▌ Honest Degradation · annatchijova bundleMake 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 this whenever you see a fallback, a default-for-a-missing-field, a best-effort claim, or a try/except that lets execution continue, even if the user hasn't flagged it as a correctness concern.
- ▌
- ▌
- ▌ LLM Out Of The Loop · annatchijova bundleArchitect 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 explain or write up a result without being able to change it. Push to use this whenever an LLM and a consequential output appear in the same system, even if the user hasn't framed it as an architecture question.
- ▌ Reverse Engineering · annatchijovaReconstructing 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 format; analyze a suspicious sample for defense; or build an interoperable client against a system with no spec. Trigger even when the user only says "what is this file", "decode this dump", "how does this API actually work", "figure out this protocol", "what does this binary do", or pastes hex/packets/opaque bytes asking "what is this?" — ESPECIALLY when there is no source, because that absence is the condition this skill is built for. Sibling of software-archaeology, which assumes you HAVE the source.
- ▌
- ▌
- ▌ Discriminating Proof · annatchijovaTurn 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", "is this real", "ready to submit", "write the report", or when a claim rests on source reading alone and runtime confirmation is possible. Trigger even when a PoC already exists — to review whether its controls actually isolate the claimed factor. Sibling of falsifiable-testing — that skill builds tests that can fail; this one builds the single experiment whose failure kills the hypothesis and whose success a reviewer cannot dismiss.
- ▌ Forensic Persistence · annatchijovaKeep 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 everything", "dead end", "I'm stuck", "diminishing returns", or is tempted to declare a component safe because the tools came back empty. Also trigger when a bug survives several fix attempts, when a bounty report was rejected, or when deciding whether to continue, pivot, or park an investigation. Sibling of red-team-auditing and abductive-engineering — those skills run the hypotheses; this one governs what happens when the hypotheses keep dying.
- ▌ Purple Team Exercise · annatchijovaRun 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 the user only says "did our SIEM catch this", "test our detections", "validate this control", "what's our coverage for technique X", "run a purple exercise", or hands over red-team findings and asks "would we have seen it". This skill measures and specifies detection; it does NOT author vendor rule syntax (that's the detection-engineering sibling) and does NOT generate turnkey exploits (detonations are minimal, marked, non-destructive).
- ▌ Software Archaeology · annatchijovaDisciplined 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 current session. Trigger even when the user only says "clean this up", "this looks wrong, remove it", "refactor this", "make it modern", "why is this here", "touch this carefully", or pastes unfamiliar code with a change request — especially for deletions, because deletion is the change with the most invisible consequences. Fourth member of the family — abductive-engineering (inquiry), secure-by-construction (building new), red-team-auditing (attacking finished) — this one is for changing what already exists.
- ▌ Abductive Engineering · annatchijova bundleSoftware 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/hypothesis-driven approach to any engineering problem. Also trigger when the user mentions Peirce, abduction, inference to the best explanation, semiotics, or "why does this bug happen".
- ▌ Atomic State Mutation · annatchijova bundleMake 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, or dangling references after a delete. Push to use this whenever you see more than one write that must all succeed together, even if the code currently commits them separately.
- ▌ Attack Surface Triage · annatchijovaEnumerate 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 output and asks what to do with it. Also trigger when a security engagement is being scoped, when a pentest backlog needs ordering, or when a threat model needs candidate entry points. This skill produces a ranked queue of CANDIDATES with stated falsifiers — it never produces exploits, never asserts a vulnerability exists, and never scores by model intuition. Feeds red-team-auditing (confirm one candidate) and purple-team-exercise (measure detection for one technique).
- ▌
- ▌
- ▌ Detection Engineering · annatchijovaTurn 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 getting too many alerts", "tune this detection", "why didn't this fire", "detection as code", or "add a monitor"; and whenever a purple-team gap needs closing. Sibling of purple-team-exercise — that skill specifies WHAT must be caught, this one builds and proves the thing that catches it. It does not run exercises, does not triage incidents, and never claims coverage from a rule that has not fired on a real true positive.
- ▌
- ▌ Oracle Driven Fuzzing · annatchijovaSearch 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", "generate test cases", "how do I test this parser/serializer/state machine", "it only breaks on weird input" — or when a crash corpus needs triage. Also trigger when a fuzzer "found nothing", and whenever a round-trip, an encoder/decoder pair, a cache, or a second implementation exists, because those are free oracles. Sibling of falsifiable-testing (hand-written tests) and discriminating-proof (confirming one hypothesis); this skill governs the automated search that generates them. It never calls a crash a vulnerability.
- ▌
- ▌
- ▌
- ▌ Assume Breach Modeling · annatchijovaStart 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 movement", "if this container/CI job/service account is popped", "worst case", "can they pivot", "defense in depth", "least privilege", "zero trust", "network segmentation", "what does this key unlock", "how would we contain it", or a risk rating that rests on one control holding. Turns red findings into blue architecture. It models reachability from an authorized position and produces containment; it never plans intrusion into systems outside the engagement.
- ▌ Secure By Construction · annatchijovaDeliberate, 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 tests that are built to fail when the code is wrong. Trigger even when the user only says "write me a function", "implement X", "add a script", "add tests", "make the tests pass", "just get it working", "quick and dirty", or asks for speed — especially then, because speed is where the defects enter. Companion to abductive-engineering (the inquiry engine) and red-team-auditing (its adversarial audit); this skill is the construction phase.
- ▌
- ▌
- ▌
- ▌
- ▌
- ▌ Training Run Provenance · annatchijovaGet 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 has to be defended later. Trigger on "set the seed", "reproducible training", "why do I get different results", "torch.deterministic", "which model is in production", "model registry", "MLflow/W&B", "we can't reproduce the paper", "retrain", "the metric moved but the code didn't", or a model artifact whose training run cannot be identified. Extends deterministic-core into ML, where floats are the model and bitwise determinism ends at the frozen artifact — after which the decision built on top must be exact again.
- ▌
- ▌
- ▌
- ▌
- ▌ Validate At The Boundary · annatchijova bundleValidate 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 error, a NaN that appeared from nowhere, a path traversal or symlink concern, "validate input", "sanitize", "this crashed deep in a library". Push to use this whenever an external value reaches a sensitive operation without having been checked first.
- ▌
- ▌
- ▌
- ▌ Codebase Health Assessment · annatchijovaSystematic 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 copies of X?", or "what would break if I deleted Y?". Complements software-archaeology (which governs safe *modification* of individual modules) — this skill governs the *assessment* phase that decides which modules deserve that careful modification, which are candidates for bulk removal, and which need to be left alone with documentation. If software-archaeology is the surgeon, this skill is the triage nurse.
- ▌
- ▌ Daubert Defensible Writing · annatchijovaWriting 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", "make it convincing", or "make it sound solid" — especially then, because persuasion pressure is where overclaiming enters; and whenever a draft needs review for inflated certainty, unsupported claims, or buried limitations. Trigger even for a single paragraph if it states conclusions someone might challenge. Fifth member of the family (abductive-engineering, secure-by-construction, software-archaeology, red-team-auditing) — this one governs how their outputs get written down.
- ▌
- ▌ Resource Exhaustion Review · annatchijovaFind 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 laughs", "OOM", "the worker ran out of memory", "it hangs on large input", "quadratic", "N+1", "timeout under load", "retry storm", "thundering herd", "rate limit", "backpressure", "pagination", "batch size", "how big can this get", "we never set a limit", or a request whose cost depends on a caller-supplied count, depth, or size. Availability is an invariant like any other. This skill hardens code you own — it bounds work and sheds load; it never plans or conducts availability attacks against any system.
- ▌ Tamper Evident Audit Chain · annatchijova bundleBuild 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", "provenance", or "prove this wasn't changed". Push to use this even when the user only says "log every X" or "keep a record of Y" and that record might one day need to be trusted.
- ▌ Versioned Schema Evolution · annatchijova bundleStamp 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" path has to cope with more than one shape of stored data. Triggers — "schema migration", "backward compatible", "version mismatch", "old saved data", "from_dict", "deserialize", "we changed the format". Push to use this whenever serialized data outlives the exact code version that wrote it.
- ▌
- ▌ Model Evaluation Discipline · annatchijovaBuild 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", "our model gets X%", "it beats the baseline", "which model should we ship", "the metric improved", "evaluate this model", "benchmark", "is this good", "calibration", "the offline numbers looked fine", "SOTA", or a model comparison with one number per model. Sibling of falsifiable-testing, which governs tests that can fail; this one governs metrics that can fail. It does not tune models and does not chase leaderboard positions.
- ▌ Parser Differential Hunting · annatchijovaHunt 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 embedded in another. Trigger on "request smuggling", "path traversal", "canonicalization", "normalization", "Unicode/homoglyph/punycode/IDN", "duplicate keys", "content-type sniffing", "URL parsing", "the proxy and the backend disagree", "it validated but stored something else", "double decode", "polyglot", "type confusion", or two parsers of the same format appearing in one system. Expands invariant-hunting's semantic-boundary family into a full method; hands verdicts to discriminating-proof.
- ▌
- ▌
- ▌
- ▌
- ▌ Authorization Surface Mapping · annatchijovaBuild 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. Trigger on "IDOR", "BOLA", "broken access control", "can user A see user B's data", "tenant isolation", "row-level security", "privilege escalation", "who can access this endpoint", "check permissions", "admin bypass", "scoped token", "impersonation", "we added a role", or a new endpoint that takes an object id. Sibling of invariant-hunting, which follows one property across a transition; this skill enumerates the whole grid so no cell is untested. It maps and tests authorization; it does not design the policy engine.
- ▌
- ▌
- ▌ Dont Fall In Love With The Bug · annatchijovaDo 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 'it reproduces', 'ready to submit', 'write it up', 'is this exploitable', or an assumed quick fix.
- ▌