agentleFS
anthony-chaudharyanthony-chaudhary/dos-kernel/.claude/skills/issue-verify/SKILL.md

issue-verify

Skill20 starsChanged 5 months agoMITView on GitHub

Adjudicate a GitHub issue's "this is resolved" claim from witnesses the claimant didn't author — then close it carrying the evidence, or refuse with the typed gap. Use when an issue looks already-solved, after landing a fix that should have closed one, or to sweep open issues for silently-resolved ones.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. bordenet/superpowers-plus★ 8same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Public-repo note: Every comment this skill posts is a public document — no dev-machine paths, hostnames, or private-process prose (the …

    line 30
  2. Very specific:

    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 …

    line 50
  3. Distinctive:

    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 …

    line 72
  4. Very specific:

    Run each gather-command and record the raw fact (run ID + conclusion, SHA + ancestry bit, registry field + timestamp).

    line 84
  5. Distinctive:

    Search for the failure signature in evidence newer than the claimed fix (later runs of the same workflow, later issue comments, later …

    line 92
  6. Distinctive:

    Only on ACCEPT, one mutation:

    line 123

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.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 — 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

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:

RungThe claim is about…The witness (env-authored)
gita code/doc change in this repogit 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
runCI / pipeline behaviorgh run list / gh run view --json conclusion,jobs — the Actions conclusion field, never the run's own log narration
read-backan 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 workno 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:

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
FoldVerdictActuation
all confirmedACCEPTclose, carrying the evidence (Step 6)
any refutedREJECT_POISONcomment the refuting evidence, leave OPEN
any unwitnessableABSTAINleave OPEN; tell the operator exactly which witness is missing and what would produce it

Step 6: Actuate (skip on --dry-run — print the would-be comment instead)

Only on ACCEPT, one mutation:

gh issue close <N> --comment "<evidence comment>"

The comment is the artifact — it must let a future reader re-derive the verdict without trusting you. Shape (the #1 close is the reference rendering):

Verified resolved — adjudicated the DOS way: the claim is corroborated by
read-backs the claimant didn't author, not by narration.

**Witness 1 — <rung>.** <the raw fact, with run-ID / SHA / URL>
**Witness 2 — <rung>.** <…one block per claim…>

Kernel verdict: `dos reward --claim --witness confirm` → **ACCEPT**.
<one line on WHY this rung and not another, if non-obvious>

<non-recurrence note: what newer evidence was checked, and why any later
failure is a distinct defect, with its pointer>

On REJECT_POISON, the same shape with the refuting witness and no close. On ABSTAIN, no comment by default — report to the operator instead (a public "couldn't verify" comment adds noise, not evidence).

Step 7: Report

  • Per issue: #N — ACCEPT (closed) / REJECT_POISON (left open: <refuting fact>) / ABSTAIN (left open: <missing witness>).
  • Any non-recurrence findings that deserve their own issue.
  • On --sweep: the verdict table, plus how many opens were not adjudicated and why.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.