issue-verifylisted

# Issue-verify — close issues from evidence, not narration > **An issue is a CLAIM; closing it is BELIEVING the claim.** The kernel's one > rule, aimed at the tracker: never set a belief bit from what anyone *says* — > set it from a read-back the claimant didn't author. This skill is the > `dos-witness-claim` pattern pointed at GitHub issues: extract the checkable > effects, witness each on the right rung, stamp the fold with the kernel's > admission verdict, and only then actuate the close. Worked example: > [#1](https://github.com/anthony-chaudhary/dos-kernel/issues/1) — two > env-authored witnesses (a green Actions run conclusion + the TestPyPI > registry's own JSON), one non-recurrence triage, one `dos reward … → ACCEPT`, > one evidenced close. **Layering.** Dev tooling that operates ON the repo (the `/release` tier) — it names a vendor (`gh`/GitHub), so it lives in `.claude/skills/`, never `src/dos/skills/` (a shipped SKP skill names no vendor or host). If the screenplay proves out, the promotion path is the usual lift: parameterize the tracker, move the shape into the SKP. **Public-repo note.** Every comment this skill posts is a public document — no dev-machine paths, hostnames, or private-process prose (the route-privacy-at-authoring-time rule applies to issue comments too). **The disciplines** (the JUDGE-rung hedges, applied to triage): - **Deterministic-first** — a witness is a command output or a registry read-back, never your impression of the thread. - **F