issue-verify

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 — 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.
• Fail-to-abstain — a witness you cannot gather (command errors, endpoint down, no witness exists for the claim) is none, NEVER confirm. No close without a confirming witness.
• Forgeable ⇒ structurally ignored — a "fixed!" comment, a commit subject, a > **Status:** line are claimant-authored bytes: they may select which witness to gather, never BE the witness. If the best you have is forgeable, pass --forgeable to dos reward and watch it ABSTAIN — that is the structure working, not a gap.
• Advisory until the one actuation — read-only throughout; the single mutation is the close + its evidence comment. Never edit an issue body, never delete, never close on a REJECT or ABSTAIN fold.

When NOT to use the manual close at all: if the resolving fix is a commit you are about to land in this repo, put Fixes #N in the commit body and let the merge close the issue — the tracker then records the closing commit as the witness (the repo's issues-workflow convention). This skill's manual close is for the other three cases: a fix that already landed without the reference, a fix that lives outside this repo's git (an external service's config — the #1 case), or an issue dissolved by an environment change.