sota-llm-engineeringlisted
State-of-the-art LLM application engineering rules (mid-2026 baseline) for BUILDING and AUDITING LLM-powered features. Claude should use this skill whenever it is building, modifying, or reviewing anything that calls a language model — chat features, RAG pipelines, agents and tool use, structured extraction, classification, summarization, embeddings/vector search, evals and regression gates, prompt or context engineering, model selection/routing, fine-tuning decisions, or LLM cost/latency/observability work. Trigger keywords: LLM, AI feature, prompt, system prompt, context window, RAG, retrieval, embeddings, vector DB, rerank, chunking, agent, tool use, MCP, multi-agent, evals, golden set, LLM-as-judge, fine-tuning, model selection, routing, structured output, JSON schema, prompt caching, token budget, hallucination, grounding. Covers build-quality only — for prompt-injection/agent-security use sota-code-security rules/08 and sota-sandboxing rules/05.
martinholovsky/SOTA-skills · ★ 8 · AI & Automation · score 75
Install: claude install-skill martinholovsky/SOTA-skills
# SOTA LLM Engineering
## Purpose
One skill, two modes. The `rules/` files define the mid-2026 baseline for
engineering LLM-powered software that is **measured, grounded, bounded, and
observable**. In **BUILD** mode you write LLM features that conform to the
rules by default. In **AUDIT** mode you hunt for violations and report them as
severity-rated findings. The rules are the single source of truth for both.
Framing: an LLM call is a non-deterministic, expensive, latency-heavy RPC to a
dependency that changes underneath you. Everything here follows from that —
you don't ship logic you can't measure (evals), you don't trust output you
didn't validate (structured output, grounding), you don't run loops you can't
stop (budgets), and you don't deploy what you can't trace (observability).
**Scope boundary:** this skill owns build quality. Prompt injection, the
lethal trifecta, tool-call authorization, and model-output-as-untrusted-data
live in `sota-code-security` rules/08; agent sandboxing/isolation lives in
`sota-sandboxing` rules/05; PII/regulatory handling lives in
`sota-privacy-compliance`. Reference them; don't re-derive them.
**Freshness rule:** model names, prices, context limits, and spec revisions in
these files were verified June 2026 and rot fast. When a decision hinges on a
specific model/price/limit, re-verify against provider docs (or the project's
`claude-api`-style reference skill) before encoding it. Write code
version-agnostically: model IDs and parameter