← 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. It maps the task (build or audit mode) to the right domain skills (architecture, code security, threat modeling, secrets, sandboxing, performance, async/concurrency, APIs, devsecops, databases, frontend, web frameworks, observability, testing, LLM engineering, ML engineering, cloud, kubernetes, identity & access, network security, confidential computing, detection engineering, data engineering, privacy/compliance, security/compliance, mobile, CLI UX, UX writing, copywriting, shell scripting, docs/workflow) 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.
martinholovsky/SOTA-skills · ★ 8 · AI & Automation · score 75
Install: claude install-skill martinholovsky/SOTA-skills
# SOTA Engineering Skills — Master Router A library of 40 domain skills, each with a `SKILL.md` entry point and a `rules/` folder of focused rule files (every file < 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. 1. **Freshness first.** The library's version/spec/regulation facts were web-verified as of the last refresh (see RE