← ClaudeAtlas

sotalisted

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). 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.
martinholovsky/SOTA-skills · ★ 18 · Code & Development · score 78
Install: claude install-skill martinholovsky/SOTA-skills
# SOTA Engineering Skills — Master Router A library of 41 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`. 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. 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 t