sota-docs-workflowlisted

# SOTA Docs & Engineering Workflow ## Purpose Expert-level rules for the artifacts around the code: documentation (structure, reference, freshness, runbooks) and the collaboration workflow (PRs, review, commits, releases). These are the highest-leverage, lowest-glamour practices — review latency and doc decay quietly dominate team throughput. Rules are imperative with rationale and good/bad examples; every rules file ends with an audit checklist. Load only the files relevant to the task via the index below. Boundaries: ADR practice lives in `sota-architecture`; API contract design in `sota-api-design`; tag signing/provenance and CI supply chain in `sota-devsecops`. This skill references them rather than repeating them. ## BUILD mode When creating docs or setting up workflow: 1. **Classify before writing.** Every doc is exactly one Diátaxis mode (tutorial / how-to / reference / explanation) and is titled accordingly; mixed-mode pages are the defect to design out (`rules/01` §1). 2. **Docs live with the code**: in-repo, PR-reviewed, CI link-checked, examples executed. If a doc can't change in the same PR as the code, it will decay (`rules/01` §2, §4). 3. **README = what / why / 5-minute quickstart / honest status**, then links out (`rules/01` §3). Runbooks are alert-linked and command-exact (`rules/01` §5). Ship the **documentation baseline** — README + LICENSE + CHANGELOG always; SECURITY/CONTRIBUTING/CODE_OF_CONDUCT once public — each with one ca