SOTA Engineering Skills — Master Router
SkillMediaMaster 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.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the SOTA Engineering Skills — Master Router skill
What this skill tells your AI
The instructions your AI receives, as published by martinholovsky/sota-skills in skills/sota/SKILL.md and read by ahel’s review.
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. Severity resolves the same way:rules/03§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)
- 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 theater — read the code path that decides the behavior instead of benchmarking its symptoms.
- 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.
- 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.
- 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: "no instances of X" and "I only looked one way"
are indistinguishable from the outside, so before asserting absence, widen
the search and use a second independent method — and state the search you
actually ran. "Independent" means a different failure mode, not a different
phrasing. Field-reported: two searches of the same tree agreed on zero and
both were wrong, because both were
grep -rover a directory of symlinks, which-rdoes not follow. The only check that works is a positive control — search for something you have already seen there, in the same invocation; if the control returns nothing, the instrument is broken and the absence is not evidence (sota-shell-scriptingrules/06 §2). - Stack profile. If the repo or
~/.claudecontains aprofiles/*.mdstack profile (preferred stores, auth provider, license policy, platform conventions), its choices are the defaults for BUILD mode and the expected baseline for AUDIT mode. - Universal build non-negotiables (apply regardless of routing). On any network-reachable endpoint or handler (HTTP, RPC, queue, webhook, upload), always include: (a) abuse control — rate limiting / quotas keyed to the caller; (b) transport enforcement — TLS, HSTS, no plaintext fallback; (c) tests for the logic; (d) structured logging without secrets/PII. These are cross-cutting, so they get silently dropped under a long, dense task even when a rules file covers them — a measured attention effect, not a coverage gap. Keep this list short and re-check it last, before you ship (BUILD step 4). If one is deliberately handled elsewhere (e.g. rate limiting at the gateway), say so — don't silently omit it.
- Claim "done" only with evidence. Never report a task complete or a fix working from plausibility — "should work", "this fixes it", "Done!" are not evidence. State the check you actually ran and its result: test output with pass/fail counts and exit code, the command and its output, or the reproduced behavior. If you did not run it, say so plainly. Unverified completion is not completion — this applies to your own build output before you hand it back.
- Restate from the artifact, never from your own summary. Re-reading your
own write-up re-runs the reasoning that produced it — the weakest check
available. Before a claim reaches anything user-visible, go back to the
primary source: re-read the tool output, or re-run the command. Your earlier
prose in this session is not a primary source — and neither is a verbatim
copy of a file injected into context earlier in it. A quoted file reads as
primary evidence in a way a summary does not, which is exactly what makes it
the easier mistake: it may predate an edit made since. Re-read the path before
asserting or editing against its contents. Summaries silently drop the case
that contradicts them and raw output does not. Full adversarial procedure for
audit findings: AUDIT step 7 and
rules/03§4. - Publishing under someone else's name raises the bar. A claim to the
person who asked costs one reader's trust and is cheap to retract. A claim
published as them — a PR review comment, an issue, a commit message, a
mailing-list post — is public, attributed and effectively permanent. Verify
every factual claim by execution rather than inference, say which parts you
did not test, check the thread first for whether it is already known, and
never publish on someone's behalf without approval of the final text. Full
procedure:
sota-docs-workflowrules/03 §8. - Match the rigour to the stakes — and name the level you chose. A spike, a one-off script, a local experiment: build it, say in one line that it is a prototype and what you left out, stop. Anything reachable by an untrusted caller or touching money, credentials or another tenant's data gets the full treatment including principle 5, whether or not the request said "quick"; if it is genuinely ambiguous, ask in one line. An unnamed shortcut is not a prototype.
Routing table
| Skill | Use when the task involves... |
|---|---|
sota-architecture | System design, service boundaries, monolith vs microservices, DDD, event-driven design, sagas/outbox, reconciliation against a third party that holds authoritative state, resilience (timeouts/retries/circuit breakers), scalability, multi-tenancy, 12-factor/cloud-native, architectural anti-patterns |
sota-code-security | Writing or reviewing code that touches untrusted input, authn/authz, sessions/JWT/OAuth, crypto, XSS/CSRF/CORS, file uploads, deserialization, error/log hygiene, LLM/agent app security, silent control failure (a safeguard that looks enabled and does nothing) |
sota-threat-modeling | Designing a new system/feature with security in mind, drawing trust boundaries and DFDs, STRIDE/LINDDUN, risk rating, reconstructing a threat model from an existing codebase |
sota-skill-security | Installing, authoring, reviewing or auditing anything an agent loads as instructions — skills, plugins, rulesets, AGENTS.md/CLAUDE.md/.cursorrules: provenance and pinning, review-before-install, the instruction trust boundary (a PR that edits an agent file changes what your agent does), precedence and shadowing between overlapping skills, capability minimisation, and guidance that is confidently wrong |
sota-secrets-management | API keys, passwords, tokens, signing/TLS/SSH keys, .env files, Vault/cloud secret managers, workload identity (OIDC), secret rotation, leak detection and remediation |
sota-sandboxing | Isolation of untrusted code or input, least privilege, seccomp/Landlock/capabilities, container/K8s hardening, microVMs, WASM sandboxes, subprocess hygiene, sandboxing AI-agent code execution |
sota-performance | Latency, throughput, profiling, memory usage, caching (incl. stampede protection), I/O and network efficiency, Core Web Vitals, performance regression in CI |
sota-async-concurrency | async/await, threads, goroutines, channels, races, deadlocks, event-loop blocking, cancellation/timeouts, graceful shutdown, backpressure, bounded queues |
sota-api-design | REST/HTTP semantics, pagination, idempotency, versioning/deprecation, GraphQL, gRPC/proto evolution, websockets/SSE/realtime, webhooks, API rate limiting and tenant isolation |
sota-devsecops | CI/CD pipelines, GitHub Actions hardening, supply chain (SLSA, Sigstore, SBOM, dependency confusion), unused/inert dependencies and upstream-health checks, container builds, SAST/secret-scanning gates, Terraform/GitOps, admission control |
sota-databases | Schema design, Postgres/NoSQL choice, migrations (zero-downtime), indexes/EXPLAIN, transactions/isolation, ledgers & account balances, connection pooling, replication/backups, Redis, RLS/DB security, pgvector |
sota-frontend-design | UI/UX, visual design, typography/color/layout, design systems and tokens, components, forms, accessibility (WCAG 2.2), motion/animation design, modern CSS, responsive design |
sota-web-frameworks | React/Next.js and Vue/Nuxt engineering — Server Components & Server Actions, the RSC/client trust boundary, Next caching (use cache/PPR/ISR), Nitro server routes, hydration correctness, SSR state serialization, and framework-specific security & CVEs |
sota-observability | Logging, metrics, tracing (OpenTelemetry), SLOs/error budgets, alerting, health checks, dashboards, debugging production, "can we answer why is this slow?" |
sota-testing | Test strategy (pyramid/trophy), unit vs integration boundaries, test design/smells, mocks/fakes/test data, contract testing, e2e, property-based/fuzzing/mutation testing, flaky tests, coverage policy |
sota-llm-engineering | Building LLM features — evals, prompt/context engineering, structured output, RAG, agents/tool design, MCP, model selection/routing, latency/cost engineering, LLM observability — and any question about a model's tokens, context window, pricing or limits, including measuring your own files |
sota-ml-engineering | Production ML/MLOps (classical/predictive, not LLM apps) — training→serving→monitoring lifecycle, feature stores & registries, data leakage & train/serve skew, evaluation (ML Test Score, slices), deployment (canary/shadow/rollback), drift monitoring (PSI/KS) & retraining, ML security/governance (poisoning, MITRE ATLAS, NIST AI RMF) |
sota-cloud-infrastructure | Cloud accounts/landing zones, cloud IAM, VPC/subnet/DNS/CDN setup, compute selection (serverless vs containers vs K8s), object storage, FinOps/cost, RTO/RPO and disaster recovery |
sota-kubernetes | Kubernetes platform security & ops — RBAC & escalation paths, admission control (PSA/Kyverno/Gatekeeper/VAP, Audit→Enforce), GitOps controllers (Argo CD/Flux, AppProject scoping), operators/CRDs/webhooks, control plane & etcd encryption, Helm supply chain, multi-tenancy, cluster lifecycle, K8s audit logging; self-hosted (Talos/k3s) and managed |
sota-identity-access | Identity infrastructure & access management — OIDC/OAuth2.1/SAML/SCIM protocols, running an IdP (Kanidm/Keycloak/etc.), RBAC/ABAC/ReBAC authorization design, group→role mapping, joiner-mover-leaver lifecycle, deprovisioning, privileged access & break-glass, SPIFFE/workload identity, phishing-resistant MFA/passkeys, federation risk |
sota-network-security | Network security as a discipline — zero-trust (NIST 800-207), segmentation & blast-radius, the world/any over-broad-rule trap, Kubernetes NetworkPolicy depth (Cilium L7, default-deny egress), service mesh & mTLS / internal encryption, edge/ingress/WAF, egress control & metadata-endpoint blocking, DNS/TLS/PKI & cert lifecycle, email auth (SPF/DKIM/DMARC) |
sota-confidential-computing | Protecting workloads/data from the infrastructure operator — TEEs (AMD SEV-SNP, Intel TDX, ARM CCA, SGX enclaves, Nitro Enclaves, confidential GPUs), remote attestation (RATS, attest-then-release), confidential VMs/nodes/containers on K8s (CoCo/Kata/Trustee), and cryptographic PETs (FHE, MPC, ZKP, PSI) when hardware trust is off the table |
sota-detection-engineering | Detective controls, SOC & IR — detection-as-code, Sigma/YARA/Suricata/Falco/Tetragon rules, ATT&CK coverage, SIEM & telemetry coverage, alert tuning/SOAR, threat hunting & intel (STIX/TAXII), deception/honeytokens, incident response (NIST 800-61), detection validation (Atomic Red Team/Caldera) |
sota-data-engineering | Data pipelines, ELT/orchestration, dbt, Kafka/streaming, CDC, schema registry, lakehouse (Iceberg/Delta/Parquet), data quality/contracts, warehouse modeling |
sota-privacy-compliance | PII inventory/classification, privacy by design, consent, DSAR/deletion architecture, retention, GDPR/CCPA/HIPAA/PCI/AI Act engineering obligations, SOC 2/ISO 27001 audit readiness, breach response |
sota-security-compliance | Cybersecurity control frameworks & product-security regulations as engineering — NIST CSF 2.0, SP 800-53, 800-171/CMMC, SSDF (800-218), FedRAMP, EU Cyber Resilience Act (SBOM/CVD/signed updates), ISA/IEC 62443 (OT zones & conduits, Security Levels); control-framework-as-code crosswalks, CUI boundaries, FIPS-validated crypto |
sota-mobile | iOS/Android/cross-platform apps — stack choice, offline-first/sync, push, mobile security (Keychain/Keystore, attestation), performance budgets, store requirements, staged rollouts |
sota-cli-ux | CLI/developer-tool design — flags/subcommands, config precedence, stdout/stderr and --json contracts, exit codes, TTY detection, signals, completions, distribution |
sota-shell-scripting | Bash/sh scripts, CI run blocks, entrypoints, Makefiles — safety baseline (quoting, set -euo pipefail, traps), injection, secrets in scripts, shellcheck/shfmt |
sota-docs-workflow | Documentation (Diátaxis, READMEs, runbooks, API docs, changelogs, AGENTS.md), code review/PR workflow, commit/branch/release discipline |
sota-ux-writing | Any user-facing interface text — microcopy, button/label wording, error messages, empty states, onboarding copy, notifications, tone of voice, terminology, alt text, i18n-ready strings |
sota-copywriting | Outward-facing content — landing pages, headlines/CTAs, value propositions, SEO content, testimonials/social proof, claim substantiation, email marketing, app-store listings |
sota-rust | Any Rust code — ownership/API design, error handling, unsafe discipline, tokio/async, supply chain (cargo audit/deny/vet), performance, clippy/CI |
sota-golang | Any Go code — errors, package/interface design, goroutines/channels/leaks, net/http hardening, security (os/exec, os.Root, govulncheck), pprof/performance, golangci-lint/CI |
sota-c-cpp | Any C/C++ code — RAII/idioms, memory safety (UAF/overflow/sanitizers), undefined behavior, security (CERT/MISRA, banned APIs, OpenSSF hardening flags), concurrency/atomics, CMake/clang-tidy/fuzzing CI, performance |
sota-jvm | Any Java/Kotlin code — modern idioms (records/sealed/pattern-matching, Kotlin null-safety/coroutines), API/null/immutability design, concurrency (virtual threads, JMM, j.u.c, coroutines), security (deserialization/JNDI/XXE/injection, JCA crypto), GC/JFR/GraalVM performance, Maven/Gradle supply-chain & CI |
sota-python | Any Python code — uv/ruff/typing setup, idioms/pitfalls, asyncio, security (pickle/subprocess/SQL), performance, FastAPI/Django/pytest |
sota-javascript-typescript | Any JS/TS code — strict tsconfig/type design, idioms, promises/AbortController, Node backend hardening, XSS/supply-chain security, bundle/React performance, vitest/ESLint |
sota-dotnet | Any C#/.NET code — modern idioms (records, nullable reference types, pattern matching, spans), API/disposal/DI design, async/await & concurrency (ConfigureAwait, cancellation, channels), security (EF/Dapper SQL, deserialization, ASP.NET Core auth, crypto), GC/Span/AOT performance, NuGet supply chain & analyzers/CI |
sota-php | Any PHP code — strict_types/modern idioms (enums, readonly, match), security (PDO/SQLi, XSS escaping, uploads/LFI, unserialize/Phar, sessions, password_hash/sodium), framework-neutral web hardening, Composer supply chain, PHPStan/Psalm, OPcache/FPM/JIT performance |
sota-ruby | Any Ruby code — idioms (frozen strings, pattern matching, RBS/Sorbet), security (AR/SQLi, ERB escaping, strong params, Marshal/YAML.load, command injection, ReDoS), Bundler supply chain (bundler-audit, lockfile checksums), RuboCop/Brakeman, GVL/Ractors/YJIT performance |
Cross-cutting routing rules
Shortened here. Read the whole file on GitHub.
Signals
- GitHub stars
- 22
- Forks
- 4
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
sota- Source
- github.com/martinholovsky/sota-skills