/sota

name: sota
description: >-
  Master router for the SOTA engineering skills library. Use this skill whenever the user asks to
  build, design, implement, refactor, harden, optimize, review, or audit an application, service, or
  codebase and the request spans more than one domain — or when you are unsure which specific sota-*
  skill applies. Also use when working on a codebase you do not own: reviewing a pull request or
  diff, responding to code review, evaluating someone else's patch, or preparing an upstream
  contribution — including mid-session, once you are already reading source, a diff, or CI config.
  It maps the task (build or audit mode) to the right domain and language skills (Rust, Go, C/C++,
  JVM, Python, JS/TS, .NET/C#, PHP, Ruby, Swift). Trigger keywords: SOTA, best practices, audit my code,
  security review, compliance, hardening, prod readiness, code quality, pull request, PR review,
  review comment, maintainer feedback, patch, diff, upstream, contribute, merge request.

SOTA Engineering Skills — Master Router

A library of 42 domain skills, each with a `SKILL.md` entry point and a `rules/` folder of focused rule files (each under 500 lines). Each skill works in two modes:

• **BUILD** — apply the rules while designing or writing code.
• **AUDIT** — review existing code against the rules and emit findings in the

canonical format below (it supersedes any per-skill variant): `file:line | rule violated | severity (Critical/High/Medium/Low/Info) | effort (trivial/small/medium/large) | fix`. **Severity resolves the same way:** [`rules/03`](rules/03-audit-findings.md) §1 is the floor. A skill's own Critical/High/Medium/Low table may refine it *within that skill's domain* and must say that it is doing so; an unscoped per-skill table does not outrank the model, and a cross-domain roll-up is always rated on it.

Read only what the task needs: first the relevant skill's `SKILL.md` (it has its own index of `rules/` files with "read this when..." guidance), then only the rules files that match the code in front of you. Never load all skills at once.

Operating principles (always apply)

0. **Validate every claim — mandatory.** No claim ships unvalidated, in any mode. A claim is validated only by checking it against a primary source: code read in full context at the pinned commit (for findings), official docs/release notes/advisories fetched at use time (for versions, specs, CVEs, tool capabilities), or a reproduced behavior (for bugs). Training data, plausibility, and "the rules file says so" do not validate anything. **A doc page states intent; only running it reports behaviour.** "What does this command do when the input is missing/stale/hostile" is a *behaviour* question even though it reads like a tool capability, and the vendor's page can be stale or simply wrong: measured 2026-09-14, Poetry's own docs say a desynced lock produces a "Warning" while the tool exits **1**, and a mechanism published from that summary had to be retracted. If a command is installable in two minutes, run it — both the failing and the passing case. **A retraction is a claim and carries the same burden.** Withdrawing a statement needs the primary source that falsifies it, exactly as asserting it did; *"I was probably wrong"* is not a finding, and it costs the reader a true statement. A wrong claim gets challenged because it asserts something; a wrong retraction sounds like humility and is waved through — **nobody audits a confession**. Three tells of over-correcting: it arrives within a message or two of an *unrelated* correction; it withdraws something you have evidence on screen for; it is a general loss of confidence rather than a named false proposition and what falsifies it. **The moment after being corrected is the highest-risk moment in a session** — the next claim needs *more* evidence, in **both** directions. Conceding everything is not the opposite of overconfidence; it is overconfidence about your own unreliability. What cannot be validated is either omitted or explicitly marked "needs verification" — never asserted. **Before measuring, state what result would falsify the claim.** If no obtainable result could, the experiment is theater — read the code path that decides the behavior instead of benchmarking its symptoms. 1. **Freshness first.** The library's version/spec/regulation facts were web-verified as of the last refresh (see README). Never trust them — or training data — for anything version- or CVE-sensitive at use time: re-verify current releases and advisories before pinning or recommending — **and equally when you are merely *measuring* a third party's artifact**, which does not feel like a version decision and is where this rule is skipped. **Record the end-of-life date beside the version**, every time. A version can be recalled fluently and with no felt uncertainty; an EOL date effectively cannot, so requiring it forces the lookup that "check this is current" does not. A version with no EOL date beside it has not been looked up. Detail, and what to do with a lapsed one: [`sota-devsecops` rules/03](../sota-devsecops/rules/03-dependencies.md) §3.9. 2. **Stop-and-ask on security-relevant decisions.** When a choice materially affects security posture (authn/z model, crypto primitive, trust boundary, secrets handling, network exposure), present the options with a recommendation and ask before proceeding. Do not silently pick. 3. **Evidence over vibes.** Every audit finding cites file:line, maps to a standard (CWE, OWASP, MITRE ATT&CK/ATLAS) where one applies, and proposes a concrete fix. Uncertain findings are marked "needs verification", never asserted. Borderline severities state the deciding assumption ("High if internet-facing; Medium if internal-only"). **A negative claim needs more proof than a positive one**: