issue-verify
issue-verify adjudicates GitHub issue closure claims by gathering deterministic witnesses, command outputs, registry read-backs, or external system states, that the issue reporter didn't author, then closes the issue only if evidence confirms resolution. Use this skill when an issue appears solved but lacks an automated closing mechanism, after landing a fix that should have resolved one, or to audit open issues for silently-resolved cases, applying strict witness discipline to prevent false closures.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernel /tmp/issue-verify && cp -r /tmp/issue-verify/.claude/skills/issue-verify ~/.claude/skills/issue-verifySKILL.md
# 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.
- **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.
## Step 1: Snapshot the claim
```bash
gh issue view <N> --json number,title,body,state,createdAt,comments
```
- `state: CLOSED` → idempotent: report "already closed", stop.
- `--sweep` → `gh issue list --state open --json number,title` and run Steps
1–5 per issue; render one verdict row each; actuate only the ACCEPTs.
## Step 2: Extract the checkable effects
From the body (and any proposed fix in it), enumerate the EFFECTS that would be
true **iff** the issue is resolved — each as `{claim, rung, gather-command}`.
If the body proposes a fix, the compound claim is "that fix was applied AND the
failure mode no longer reproduces." Pick each claim's witness rung:
| Rung | The claim is about… | The witness (env-authored) |
|---|---|---|
| **git** | a code/doc change in this repo | `git merge-base --is-ancestor <sha> origin/master` for landing; `dos verify --workspace . <PLAN> <PHASE>` where a ship-stamp exists; `dos commit-audit --workspace . <sha>` for subject-vs-diff honesty of the claimed fixing commit |
| **run** | CI / pipeline behavior | `gh run list` / `gh run view --json conclusion,jobs` — the Actions `conclusion` field, never the run's own log narration |
| **read-back** | an external effect (registry, endpoint, published artifact) | fetch the authoritative state, e.g. `Invoke-RestMethod https://test.pypi.org/pypi/<pkg>/json` — the registry's bytes, not anyone's report of them |
| *(none)* | taste, intent, future work | no witness exists → the claim is UNWITNESSABLE → ABSTAIN |
## Step 3: Gather the witnesses
Run each gather-command and record the raw fact (run ID + conclusion, SHA +
ancestry bit, registry field + timestamp). A command that errors or returns
ambiguity records `none` for that claim — fail-to-abstain, do not retry your
way to a `confirm`.
## Step 4: The non-recurrence check (newest evidence wins)
A confirming witness *older* than the latest contrary signal proves nothing.
Search for the failure signature in evidence **newer** than the claimed fix
(later runs of the same workflow, later issue comments, later commits):
- Same defect recurring → the fix did not hold → the fold is **refute**.
- A *different* defect in the same surface → note it explicitly in the close
comment ("not a recurrence — distinct failure, distinct issue") and, if it
matters, open/point to its own issue. Do not let an unrelated red block a
witnessed close, and do not let a witnessed close bury an unrelated red.
(#1's worked example: the later `publish.yml` failure was the CI-green gate
refusing a red candidate — the TestPyPI leg was `skipped`, not failed.)
## Step 5: Fold and stamp the verdict
Fold the per-claim witnesses (ALL must confirm to accept — conjunctive, like
every kernel floor), then stamp the fold with the kernel's admission verdict:
```bash
dos reward --claim --witness confirm # every claim witnessed-confirmed → ACCEPT
dos reward --claim --witness refute # any claim witnessed-refuted → REJECT_POISON
dos reward --claim --witness none # any claim unwitnessable → ABSTAIN
# only-forgeable evidence? add --forgeable and it ABSTAINs by construction
```
| Fold | Verdict | Actuation |
|---|---|---|
| all confirmed | **ACCEPT** | close, carPick the next most important open GitHub issue this agent can actually complete, make its done-condition true, land it with witnesses (suite + parity + commit-audit), and priority-tag every issue touched along the way. Use when asked to "work the backlog", "complete the next most important issue", or to fix a specific issue number end-to-end.
Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.
Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/<codename> git tag on the same commit. Does NOT bump versions or build new artifacts.
One automatic plan-class lifecycle tick. Reads the DECLARED class set + transition list from the workspace `[lifecycle]` table (not a hardcoded taxonomy), evaluates each trigger, spawns a read-only JUDGE-rung adjudicator (the `dos.judges` seam — advisory, fail-to-abstain) to approve/defer each candidate transition, applies the gated transitions as plan-meta edits + one commit per cycle, and logs to the run archive. Failsafes (per-cycle cap, per-plan cooldown, a veto class) are `[lifecycle]` data; the judge content is a host `dos.judges` driver. Every path/class comes from `dos doctor --json`. Use to garden a plan portfolio's lifecycle automatically, judge-gated. The DOS lifecycle gardener (SKP Axis 5, docs/207 Phase 5c).
Run /dos-dispatch on a recurring cadence, alternating with /dos-replan when the backlog drains — the dispatch→replan→dispatch cycle. The continue/stop/next-mode decision is the kernel's typed loop decision, not inline prose: each iteration is classified (`dos gate`) into a verdict and the loop's counters (drained-twice, the unclear/dirty-zero breakers, the iteration cap) drive the next step. Several loops on disjoint lanes run concurrently, each taking its own lane lease via `dos arbitrate`. Driven entirely by `dos` verbs + the workspace's `dos.toml`. The DOS reference loop workflow (SKP Axis 5).
End-to-end plan-and-ship for one lane — snapshot the portfolio with /dos-next-up, take a lane lease via `dos arbitrate` so parallel dispatches don't collide, gate the empty case via `dos gate`, ship the packet, and archive the run under the configured run dir. Driven entirely by `dos` verbs + the workspace's `dos.toml`; names no host path, lane, or commit convention. Use when you want to plan and ship the next batch on one lane in a single command, with concurrency safety. The DOS reference dispatch workflow (SKP Axis 5).
Ground a "keep working until the goal is met" stop condition in a witness the agent did not author, instead of letting the agent self-certify "done". A harness goal/Stop-hook condition is normally checked by the model re-reading its OWN work — consistency, not grounding. This skill turns the operator's goal into checkable EFFECT claims and wires `dos hook stop` so the Stop is refused until git ancestry (a shipped phase) or an effect read-back corroborates the claimed effect. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use when you want a self-stopping agent (or a `/loop` worker) to be unable to declare a goal complete on its own say-so. The single-agent self-stop analogue of `dos-witness-claim`.
Snapshot a repo's phased-plan portfolio and produce a parallel-agent dispatch packet, driven entirely by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Walks the configured plans glob, audits each candidate pick against `dos verify` for its true shipped/unshipped status, renders a self-contained packet to the configured output dir, and reports a typed gate verdict via `dos gate`. Use when you want a "where are we / what's next / who-does-what" snapshot of any repo that has a few plan docs and real commits. This is the DOS reference workflow (SKP Axis 5); a host may use it, fork it, or ignore it.