/sota-report

description: Write a SOTA-skills field report for this session — where the guidance failed, was absent, was wrong, or was right and did not fire. Run it at the END of a working session, while the history is still in context.

Write a SOTA-skills field report for this session.

You have been applying the sota-* skills (or should have been). I maintain that library and have no telemetry: it learns nothing from use unless a session like this one says so. What I need is not a summary of what you built — it is the places the guidance failed, was absent, was wrong, or was right and did not fire.

First, record which version produced this

The evidence is bound to the version that produced it, so the report opens with:

SOTA-skills version : <from the VERSION file next to the installed library> Library commit : <for a symlink install: the checkout's HEAD, short sha> Install type : symlink / --copy snapshot / plugin / unknown Date : <today>

Resolve it without guessing: `readlink ~/.claude/skills/sota` gives the repo path for a symlink install — `cat <that>/../../VERSION`, and `git -C <that>/../.. rev-parse --short HEAD` for the commit. **A symlink install moves with every `git pull` while VERSION stays put** until a release (field-reported 2026-10-12: one "1.48.0" stamp covered ten content commits), so the version alone cannot say which text you ran. If the session spanned a pull, give the commit range. For a plugin install look under `~/.claude/plugins`. **If you cannot resolve it, write `unknown` and say why.** A wrong version stamp is worse than none: it is the field a maintainer trusts to decide whether your finding still applies.

**Do not update the library and re-run this.** The session already happened under the installed version; updating changes the skills but cannot re-run the work, so you would produce a report about old behaviour stamped with a new version. Report against what you actually used. Being months behind is fine — most of the library does not move, and triage is one `git log` on the file you cite.

Write the file, don't print it

`FIELD-REPORT-<PROJECT>-<YYYY-MM-DD>.local.md`. Genericise as you write: no company names, internal service names, private hostnames, or customer data. Products appear only as neutral examples ("a Postgres instance", "an eBPF sensor").

**Where to put it: outside the target repo's working tree, unless you have checked two things there.** `.local.md` is gitignored *in SOTA-skills*; that is a fact about that repo, and it does not travel with this instruction. In the repo you are reporting on, check (1) that the pattern is actually ignored — `git check-ignore -v <file>` answers it, exit 0 naming the rule that matched and exit 1 with no output when nothing does, and it reads `.git/info/exclude` as well as `.gitignore`, which is where agent scaffolding usually lives — and (2) that no **working-directory** scanner runs over the tree, because a directory scanner does not read `.gitignore` at all (`sota-secrets-management` rules/04, verified on gitleaks 8.30.1). Writing the report into the root of a repo mid-session otherwise dirties the tree and feeds an unreviewed file to a secret gate, which then fails on your own report. When in doubt write it outside and move it in afterwards — that is what a field session actually did on 2026-09-15, after this instruction's literal form cost it a red gate.

What is worth reporting, in descending order of value

1. A rule of the library's that CAUSED a defect. Followed literally, it produced the bug. This outranks everything else — an absence is a gap, a wrong rule is a liability. 2. A rule you had IN CONTEXT and broke anyway. Say so explicitly and separate these from coverage gaps. They are evidence about rule *shape* — placement, salience, wording — and they change how the library is written rather than what it contains. 3. Two loaded rules that contradicted each other. Name both, say which you followed, and why. 4. Real surface area with no owning skill — a routing gap. Say what the task was, and which skill should have triggered from its description alone. 5. A claim in the library refuted by a primary source you checked this session — a version, a flag, an API behaviour, a spec. Freshness rot. 6. Something that worked, if a control or a gate caught a defect that discipline would not have. I need to know which mechanisms pay for themselves.

Per finding, this structure

What happened — the concrete sequence, with the command, error or diff Why it happened — the mechanism, not the emotion. "I was careless" is not a mechanism Evidence — a transcript, exit code, file:line, or measurement someone can re-run Loaded? — which rules were in context when it happened, with the search (E) What caught it — the control, the gate, the reader, or "nothing; the user did" Proposed change — target skill + section, and the rule as you would write it Confidence — and what would falsify it

**Counting from an agent transcript: count unique `tool_use` ids, never blocks or lines.** A call is written more than once. Measured 2026-10-22 over 1,840 local Claude Code transcripts: 90,110 Bash `tool_use` blocks, 45,431 unique ids. Of the 44,679 extra blocks, 2,986 repeat inside one file. The rest are the same id in another file: 24,958 in subagent sidechain files, and 16,735 in a later session file that re-stamps the record with its own session id. That fits forked subagents and resumed sessions carrying history forward, but the harness code that writes them was not read. So a recursive glob roughly doubles the count, and a per-file check can look clean. Join each id to its `tool_result` when you need the outcome; the join deduplicates too.

Four checks that decide whether I can act on it

A. Check coverage in the LIBRARY'S vocabulary, not yours. These checks are sweeps wh