Merge branch 'master' of github.com:kevinveenbirkenbach/skills

Forbids substantive defaults for parameters, settings and env lookups
across languages; only false, null and "" are free. A missing value
must fail loudly at the earliest point instead of silently becoming a
plausible wrong answer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/active-listening/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: active-listening
+description: >
+  Gather every requirement before acting. Trigger at the start of any task
+  whose scope, constraints, or success criteria are not fully pinned down, and
+  whenever another skill needs an operator-only fact — ask focused questions
+  until nothing needed is still open, then reflect the understanding back.
+  Portable across projects.
+---
+
+Do not act on a half-understood request. Listen actively until you could state
+the task, its constraints, and its definition of done without guessing.
+
+## Procedure
+
+1. **Surface the unknowns.** List every open question the task leaves: ambiguous
+   scope, unstated constraints, success criteria, edge cases, which files or
+   systems are in play, what "done" means, and any decision only the operator
+   can make.
+2. **Derive what you can first.** Remove from that list every question you can
+   answer yourself from the code, the logs, the git history, or a sensible
+   default. Active listening is not offloading your own investigation onto the
+   operator.
+3. **Ask, focused.** Put the genuinely-open questions to the operator — grouped,
+   concrete, answerable, with a recommended default where one exists. Prefer a
+   few high-leverage questions over a long interrogation. Use the host's
+   structured question mechanism when one exists.
+4. **Listen and integrate.** Fold each answer in. A new answer often opens a new
+   question — keep going.
+5. **Loop until closed.** Repeat until no needed information is still open.
+6. **Reflect back.** Restate the task, its constraints, and its definition of
+   done in your own words for a final confirmation before acting.
+
+## Rules
+
+- Never invent an answer to an open question to avoid asking.
+- Never ask what you can determine yourself.
+- One genuinely-blocking unknown is enough reason to ask; do not proceed past it.

skills/autoskill/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: autoskill
+description: >
+  Detect operator repetition and turn it into a skill. Trigger when the
+  operator gives an instruction, correction, or prompt pattern for roughly
+  the third time in a conversation (or says they keep repeating themselves),
+  and the pattern is general enough to reuse. Portable across projects.
+---
+
+When you notice the operator repeating the same kind of instruction,
+correction, or prompt pattern (about three occurrences, exact wording may
+vary), do the following:
+
+1. Finish the current task first; never interrupt work in progress.
+2. Then propose, in one short paragraph: the repeated pattern you observed,
+   a skill name suggestion, the trigger phrasing, and what the skill would
+   do. Ask whether to create it.
+3. On approval, write the skill:
+   - a conversation shortcut or expansion: add it to the `shortcuts` skill
+     table instead of creating a new skill.
+   - project-specific behavior: create it in the project's own skills
+     directory (e.g. `skills/<name>/SKILL.md` in the repository).
+   - portable behavior: create `skills/<name>/SKILL.md` in the operator's
+     skills repository.
+   Follow the local naming conventions and keep the skill a thin,
+   single-purpose instruction; route to an authoritative doc when one
+   exists instead of duplicating it.
+4. Do not propose a skill for one-off work, secrets, or anything whose
+   repetition is already covered by an existing skill; when an existing
+   skill almost fits, propose extending it instead.

skills/comments-clean/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: comments-clean
+description: >
+  Purge explanatory comments from staged and unstaged changes. Run
+  AUTOMATICALLY, without being asked, every time the operator requests a
+  commit or stage in any wording (commit, commit no-verify, stage next,
+  socon, sobu, socobu, "commite ..."), BEFORE executing that request; also
+  on /comments-clean or when the operator complains about comments.
+  Explanatory comments are bad practice: they narrate code instead of
+  letting it speak. Portable across projects.
+---
+
+When the operator asks to commit or stage, run this audit first and only
+then perform the requested git action; never ask whether to run it.
+
+Audit every staged and unstaged change (`git diff` plus `git diff --cached`,
+added lines only) and delete every explanatory comment:
+
+1. Delete: restated code, step narration, section banners, "Note that",
+   rationale prose, apology comments, and any comment whose information the
+   code, task name, or commit message already carries. When in doubt,
+   delete.
+2. Keep only: parameter/exit-code docs, nocheck/noqa/shellcheck directives,
+   and project-sanctioned exception markers that name a concrete trip-wire.
+   A relabeled narration is not an exception; delete it instead.
+3. Re-run the project's comment lint if one exists and re-stage the files
+   that were already staged.
+4. Penalty: if this audit finds anything you wrote yourself, admit it in
+   the report (file and count, no excuses), lower your confidence numbers
+   for the affected bundle, and write the incident to persistent agent
+   memory (extend the existing minimal-comments feedback entry with the
+   date and the pattern you slipped on) so the calibration survives the
+   session.

skills/commit-next/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: commit-next
+description: >
+  Commit the staged bundle with --no-verify, then stage the next logical
+  bundle and brief the operator on it. Trigger on /commit-next or when the
+  operator asks to commit and stage the next bundle in one step. Portable
+  across projects.
+---
+
+1. Run the commit-no-verify skill on the currently staged changes
+   (comments-clean audit first, then `git commit --no-verify`, exact
+   staging index only).
+2. Group the remaining uncommitted changes into logical bundles (one
+   concern per bundle: same failure class, same mechanism, or same role)
+   and stage the next one; never mix concerns to save a commit.
+3. For the newly staged bundle run the explain skill (what the changes do
+   and how the pieces interact, file:line-anchored) followed by the
+   confidence skill (fix confidence, break risk, evidence, residuals).
+4. Close with what remains unstaged and wait for the operator's commit
+   decision; never auto-commit the newly staged bundle.

skills/commit-no-verify/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: commit-no-verify
+description: >
+  Commit the currently staged changes with --no-verify (skip the pre-commit
+  hooks). Trigger on /commit-no-verify or when the operator asks for a
+  no-verify commit in any wording. Invoking this skill IS the explicit
+  per-commit authorization that --no-verify requires; it never carries over
+  to later commits. Portable across projects.
+---
+
+1. Run the comments-clean audit over the staged and unstaged changes first.
+2. Commit exactly the staging index with `git commit --no-verify` and a
+   Conventional-Commits message derived from the staged diff; never add
+   unstaged files, never push.
+3. Report the created commit hash and what remains uncommitted.

skills/confidence/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: confidence
+description: >
+  Report calibrated confidence unprompted. Trigger whenever you stage
+  changes, declare a fix or bundle ready, or summarize completed work the
+  operator may commit or deploy — the operator must never have to ask "how
+  sure are you?". Portable across projects.
+---
+
+Every stage summary, fix report, or ready-to-commit bundle ends with a
+confidence block:
+
+1. **Fix confidence** (percent): probability the change does what it
+   claims. **Break risk** (percent): probability it breaks anything else.
+   Two separate numbers, never one blended figure.
+2. **Evidence**: the strongest proof lines only — what was executed,
+   reproduced, enumerated, or read from authoritative source. Distinguish
+   proven (ran it, saw it) from derived (reasoned statically).
+3. **Residuals**: name exactly what keeps the number below 100 and what
+   would close the gap (live deploy, missing artifact, unexercised path).
+   Never a bare percentage without its residuals.
+
+Calibration rules:
+- Number the claim you verified, not the effort you spent; discount after
+  any error the operator caught in the same area.
+- Distinguish "fixes the observed failure" from "makes the job green" when
+  hidden layers may follow, and give both numbers.
+- Static analysis alone caps at the low nineties; only executed evidence
+  (test, reproduction, live probe) justifies more.

skills/dialectic/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: dialectic
+description: >
+  Reach a defensible conclusion through a dialectical process — thesis,
+  adversarial antithesis, synthesis — iterated until one thesis survives every
+  attack at ~99% confidence. Trigger for any consequential root-cause, design,
+  or decision where being wrong is expensive and the answer is not yet certain.
+  Deep-inspects every accessible source. Portable across projects.
+---
+
+Reach the truth by dialectic, not by first guess. Do not stop at a plausible
+answer; drive the loop until a thesis survives every attack at ~99% confidence.
+
+## Before you start: listen
+
+Invoke the `active-listening` skill first. Do not begin the dialectic until you
+have gathered every requirement, constraint, and success criterion the task
+needs. A dialectic run on the wrong question wastes the whole loop. Return to
+`active-listening` mid-loop whenever an objection turns on a fact only the
+operator holds.
+
+## The loop
+
+1. **Thesis.** Form the strongest initial claim you can, grounded in evidence,
+   not assumption. Deep-inspect every source you can reach: the source code and
+   git history; the running containers (exec, logs, inspect through whatever
+   make or CLI helpers the project exposes); CI logs and artifacts; tests; docs.
+   Cite `file:line` and command output — never a bare assertion.
+2. **Antithesis.** Spawn MULTIPLE independent skeptics (parallel subagents or a
+   workflow) whose only job is to REFUTE the thesis. Each re-inspects the
+   sources itself and defaults to "refuted" on any concrete hole. Give diverse
+   skeptics diverse lenses: correctness, an alternate mechanism, does-it-
+   reproduce, does-the-fix-break-something-else.
+3. **Synthesis.** Fold every surviving objection back into a refined thesis. A
+   skeptic that found a real hole replaces or corrects the thesis; a skeptic
+   that failed to refute raises confidence.
+4. **Iterate.** Repeat thesis → antithesis → synthesis until a full skeptic
+   round finds no new hole and the thesis holds at ~99%. If confidence stalls
+   below 99%, name the exact residual and the evidence that would close it, then
+   go get that evidence (more inspection, or `active-listening` for an
+   operator-only fact) and loop again.
+
+## Rules
+
+- Executed evidence beats reasoning: run it, exec into it, read the log. A
+  thesis backed only by static reasoning caps in the low nineties.
+- The antithesis MUST be independent — never let the thesis-author be its own
+  sole skeptic.
+- Diversity over redundancy: skeptics with different lenses catch failure modes
+  identical skeptics miss.
+- Report the final thesis with its evidence AND the losing objections, so the
+  operator sees why it survived.

skills/explain/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: explain
+description: >
+  Explain code and its interactions. Trigger when the operator asks what a
+  piece of code does, how a mechanism works, why components interact the way
+  they do, or invokes /explain on a file, function, role, or module.
+  Portable across projects.
+---
+
+Explain the named code so an engineer who has never seen it can follow it:
+
+1. Read the code and every collaborator it touches (callers, callees,
+   templates, configs) before explaining; never explain from the name alone.
+2. Lead with the purpose in one sentence, then walk the flow in execution
+   order: inputs, transformations, side effects, outputs. Name the real
+   files and line references.
+3. Make the interactions explicit: which component induces, triggers, or
+   consumes which, and where the single source of truth lives. Point out
+   trip-wires (non-obvious ordering, escaping, caching, permission edges)
+   as part of the flow, not as an appendix.
+4. Afterwards ask whether to persist a Mermaid diagram of the explained
+   mechanism under a `## Schema` heading in the README.md next to the
+   affected code (create the heading if missing, replace its previous
+   diagram if present). On approval, keep the diagram to the explained
+   scope: components as nodes, induction/data flow as labeled edges.

skills/help-skills/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: help-skills
+description: >
+  List and explain every skill available in the current session. Trigger on
+  /help-skills, "welche skills gibt es", "skill übersicht", or when the
+  operator asks what skills exist or what a skill does. Portable across
+  projects.
+---
+
+Produce a one-shot overview of every skill the session can invoke:
+
+1. Sources, in this order: the session's available-skills listing, the
+   project's own skills (`skills/` and `.claude/skills/` in the repo), the
+   user-global skills (`~/.claude/skills/`), and plugin-provided skills.
+   Deduplicate by name; note when a project skill shadows a global one.
+2. Output one table per origin (project, global, plugin): skill name,
+   trigger (slash command or phrasing), one-line purpose in your own words
+   — compress the description, do not paste it.
+3. When the operator names a specific skill or topic, explain only the
+   matching skills in more depth: what they do, when they fire on their
+   own, and how they compose (e.g. commit-next → commit-no-verify →
+   comments-clean).
+4. End with the activation hint: project installers or `make install` in
+   the skills repository refresh the live copies; a restart loads renamed
+   or new skills.

skills/no-defaults/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: no-defaults
+description: >
+  Forbid default values for parameters, settings, and environment lookups in
+  every language. Load and apply AUTOMATICALLY on every task that writes,
+  edits, generates, refactors, or reviews code, config, templates, schemas,
+  or infrastructure — never wait to be asked. A default silently substitutes
+  a guess for a value the caller failed to supply, so a misconfiguration
+  becomes wrong behaviour instead of a loud failure. Demand strict, explicit
+  values and fail loudly when one is missing. `false`, `null` and `""` are the
+  only free defaults; every other default needs a written justification.
+  Portable across projects.
+---
+
+A default value is a guess, written at the point where the caller's intent is
+least known, and it turns a missing value into a plausible wrong answer instead
+of an error. Two callers then read the same call differently: one means "use the
+default", the other simply forgot. That ambiguity is the defect this rule exists
+to prevent.
+
+Never write a substantive default. Require the value. When it is absent, fail
+immediately, loudly, and with a message that names the missing thing.
+
+## The rule
+
+1. Every parameter, option, setting, environment lookup, column, and template
+   variable MUST be supplied explicitly by its caller.
+2. A missing value MUST abort at the earliest possible moment — argument
+   parsing, config load, container start — never at the point of use, and never
+   by proceeding with a substitute.
+3. The error MUST name the missing key and where to set it.
+4. Optionality, when a value genuinely may be absent, MUST be modelled as an
+   explicit named case that the call site handles, never as a silent
+   substitution. `None`/`null` handled in a visible branch is fine; a fallback
+   baked into the accessor is not.
+
+## The empty defaults are free
+
+`false`, `null` (`None`, `nil`, `undefined`), and the empty string `""` MAY be
+used as defaults without justification. They are the one class that carries no
+guess: they denote absence itself rather than inventing a value the caller might
+have meant. `${VAR:-}`, `d.get(k)`, `a ?? null`, and `def f(a=None)` are fine.
+
+Every other default value — a number, a non-empty string, a non-empty list or
+map, an enum member, a path, a timeout, a retry count — MUST carry an inline
+comment stating why that specific value is correct for every caller that omits
+it. No comment, no default. Use whatever exception-comment form the project
+sanctions; where none exists, a plain comment on or directly above the default.
+
+The comment is the point: it forces you to name the assumption, so a reviewer
+can disagree with it. "Sensible", "standard", and "usual" name nothing — if the
+justification does not survive being written down, the default does not survive
+either.
+
+## Banned constructs, by language
+
+Each `Never` below means the default is a substantive value. The same construct
+with `false`, `null`, or `""` is permitted, and with any other value is permitted
+only when justified in a comment.
+
+| Language | Never | Instead |
+|---|---|---|
+| Bash | `${VAR:-x}`, `${VAR:=x}`, `: "${VAR:=x}"` | `: "${VAR:?set VAR in <file>}"` |
+| Python | `def f(a=1)`, `d.get(k, x)`, `getattr(o, n, x)`, `os.environ.get(k, x)`, `argparse(default=)` | required args, `d[k]`, `os.environ[k]`, `add_argument(required=True)` |
+| Jinja / Ansible | `\| default(x)`, `lookup('env', k) \| default('')` | `\| mandatory`, `assert` on the var |
+| JS / TS | `function f(a = 1)`, `const {a = 1} = o`, `a \|\| x`, `a ?? x` | required params, explicit `if (a === undefined) throw` |
+| Go | relying on zero values | constructor that validates every field |
+| Rust | `unwrap_or`, `unwrap_or_default`, `#[serde(default)]` | `ok_or(Error::MissingX)?`, `#[serde(deny_unknown_fields)]` |
+| Java / C# | optional parameters, `??`, `getOrDefault` | required constructor args, explicit null check that throws |
+| SQL | `DEFAULT` on a column | `NOT NULL` and supply it in every insert |
+| Make | `VAR ?= x` | `VAR := $(or $(VAR),$(error VAR is required))` |
+| Docker / Compose | `${VAR:-x}`, `ENV` placeholders standing in for config | `${VAR:?VAR is required}` |
+| Terraform / Helm | `variable { default = }`, `default` in `values.yaml` | no default; fail on the missing input |
+
+## How to apply
+
+Before writing any parameter, ask: what happens if the caller omits it? If the
+answer is anything other than "it fails and says so", rewrite it.
+
+While editing, treat every `default`, `?:`, `??`, `||`, `:-`, `:=`, `or`,
+`fallback`, and `getOrElse` in a value-resolution position as a finding unless
+its substitute is `false`, `null` or `""`, or a comment already justifies it.
+Grep your own diff for them before presenting it.
+
+Pushing a default one layer up is not a fix: a caller that passes a constant it
+invented has only moved the guess. Follow the value to its true owner —
+the operator, the inventory, the deployment config — and require it there.
+
+Removing an existing default is a behaviour change. Do not do it silently as a
+drive-by: name it, and let the operator decide whether it lands in this change
+or its own.
+
+## What does not count as a justification
+
+"It is conventional", "every other project does it", "the value is obvious",
+and "it keeps the signature short" justify nothing — they assert that someone
+else made the choice, which is the ambiguity this rule exists to remove. A valid
+justification names why this value is right for a caller who says nothing.
+
+An operator asking for a specific default, in this conversation, for this value,
+settles it without a comment.
+
+## Penalty
+
+If this audit finds an unjustified default you wrote yourself: say so in the
+report, with file and count and no excuses; lower the confidence numbers for the affected
+bundle; and write the incident to persistent agent memory, recording the date
+and the construct you reached for, so the calibration survives the session.

skills/observe/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: observe
+description: >
+  Watch a named target (a CI run, a pipeline, a build, a log) on a fixed
+  cadence and apply the triage skill whenever new failures appear. Trigger on
+  /observe <target> or when the operator asks to keep monitoring something and
+  fix regressions as they surface. Portable across projects.
+---
+
+Keep a target under continuous watch and act only when it degrades. The loop is
+the watcher; triage is the response. Do not re-investigate failures already
+resolved this session, and do not idle-poll work the harness will notify you
+about.
+
+## Before you start: fix the target
+
+The operator names one concrete target: a CI run id or url, a pipeline, a
+branch's checks, a build, or a log file. Restate it in one line and record the
+current failure set as the baseline (the failures already known or already
+fixed this session). Everything the watch reports is diffed against that
+baseline, so a stale baseline re-triages solved failures.
+
+## The loop
+
+Drive this with `/loop` in dynamic mode (no fixed interval unless the operator
+gave one): after each observation, schedule the next wake-up yourself and pass
+the same `/observe` prompt back so the next firing repeats the watch.
+
+1. **Poll the target.** Pull its current state (job list, check conclusions, the
+   log's tail). Enumerate the failures exactly as the `triage` skill's step 1
+   does: failure, cancelled, timed-out; a downstream aggregate that fails only
+   because an upstream did is not its own failure.
+2. **Diff against the baseline.** A failure is *new* only if it is not in the
+   baseline and was not already triaged this session. If nothing is new, log one
+   short line ("still green" / "N known failures, no change") and reschedule.
+3. **Triage each new failure.** Invoke the `triage` skill on the new set only —
+   which applies `dialectic` per failing job to a ~99% root cause and a real
+   fix. Never mask (no retry-until-pass, no disabled check, no soft-skip). Fold
+   each newly fixed failure into the baseline so it is not re-triaged.
+4. **Reschedule.** Pick the next delay from what you are waiting on: an active
+   run that changes every few minutes gets a check matched to its cadence; a
+   quiet or long-running target gets a long fallback (1200s+). Keep watching
+   until the target reaches a terminal state (run completed, pipeline finished)
+   AND every failure it produced has a verified fix, then stop the loop.
+
+## Rules
+
+- The loop is a fallback timer, not a busy-wait: if the harness will notify you
+  when tracked work finishes (a background task, a spawned agent), wait for that
+  notification instead of polling for it; reserve the timed wake-up for external
+  state the harness cannot see (a remote CI run, a deploy queue).
+- Executed evidence beats reasoning: read the actual failing log line and the
+  artifact, not the job title — triage and dialectic carry this through.
+- One baseline, updated in place: dedup every observation against all failures
+  seen so far, or a flaky-then-fixed failure reappears every cycle and the watch
+  never converges.
+- Report only on change: a new failure and its triage verdict, or a terminal
+  "target is green, watch closed". Silence between changes is correct.
+- Never invent results for a run still in progress; report what the poll
+  actually returned.

skills/robot/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: robot
+description: >
+  Work fully autonomously to a goal. Trigger when the operator wants hands-off,
+  uninterrupted execution — the agent drives the task to completion without
+  check-ins, never stops before the goal is reached, and uses only commands it
+  is already cleared to run. Portable across projects.
+---
+
+Operate as an autonomous robot: given a goal, reach it without hand-holding.
+
+## Contract
+
+- **No questions once the goal is clear.** Clarify only genuinely-blocking
+  unknowns up front (via the `active-listening` skill), then proceed without
+  further check-ins. Pick the cleanest option and continue; never pause to
+  confirm a choice you can make yourself.
+- **Never stop before the goal.** Do not end the run, hand back, or declare done
+  while any part of the goal is unmet — premature termination is forbidden. A
+  blocker is something to solve or route around, not a reason to quit; if one
+  step is genuinely, externally impossible, surface exactly why and keep working
+  on everything else until nothing solvable remains.
+- **Stay inside your clearance.** Use ONLY commands you are pre-authorized to
+  run. Never invoke anything the agent or tool settings mark as denied or as
+  requiring per-invocation approval (ask) — no commit, push, deploy, or other
+  approval-gated action unless the operator has already cleared it for this run.
+  When a needed action is out of clearance, do all the cleared work and report
+  the single blocked step for the operator to run.
+- **Verify, do not assume.** Reaching the goal means proving it: run it, read the
+  output, confirm the end state. Never report success on a step you did not
+  actually verify.
+
+## Rules
+
+- Escalate an uncertain root cause or design decision to the `dialectic` skill
+  rather than guessing; uncertainty is never a reason to stop.
+- Sustain the loop across long, multi-step work — the run is finished only when
+  the whole goal is verifiably met.

skills/triage/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: triage
+description: >
+  Triage a failing CI run, pipeline, or job set to a verified root cause and a
+  real fix. Trigger when a build, test, or deploy pipeline has one or more failed
+  jobs. Applies the dialectic skill to every failing job independently. Portable
+  across projects.
+---
+
+Drive a red pipeline to green by root cause, not by guesswork. Treat every
+failing job as its own investigation, and do not declare a fix until that job's
+root cause is proven.
+
+## Procedure
+
+1. **Enumerate every failing job.** Pull the run's job list and isolate each job
+   whose conclusion is failure, cancelled, or timed-out. A downstream aggregate
+   job that fails only because an upstream job did is not a separate root cause —
+   note it and move on.
+2. **Dialectic per failing job.** For EACH failing job, invoke the `dialectic`
+   skill: form a thesis about the root cause from evidence (the job log, its
+   artifacts, the code at the run's commit, git history), attack it with
+   independent skeptics, and iterate to a ~99% thesis. The jobs are independent,
+   so run their investigations in parallel where the tooling allows.
+3. **Distinguish shared vs hidden causes.** When several jobs share one root
+   cause, fix it once. When a job hides a second failure behind the first, keep
+   going until the job is actually green, not just past the first error.
+4. **Fix at the root.** Apply the real fix in the repository for each proven root
+   cause. Never mask a failure — no retry-until-pass, no disabling the check, no
+   soft-skip. If a failure is genuinely external (upstream outage, flaky infra),
+   confirm that with evidence and surface it honestly instead of fixing around
+   it.
+5. **Follow the run.** While the run is still in progress, re-check it
+   periodically and triage each newly failed job as it appears. The run is done
+   only when it has finished and every failure has a verified fix.
+
+## Rules
+
+- Executed evidence beats reasoning: read the actual failing log line and the
+  artifact, not the job title.
+- Classify each failure: a real defect (fix it), a flake or infra hiccup (prove
+  it is transient before dismissing), or already-fixed-by-a-later-commit (verify
+  the fix is present in the run's commit before claiming it).
+- Report a per-job verdict: root cause, the evidence that proves it, and the fix.