[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C5BADQVV8RPC7NBWM1C436":3,"skill-same:01M6C5BADQVV8RPC7NBWM1C436":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6C5BADQVV8RPC7NBWM1C436","execution-grounded-review",null,"Execution-grounded review: run tests first, trace each acceptance criterion to execution evidence. Use when verifying an implementation meets spec.","laurigates\u002Fclaude-plugins","laurigates","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13014001?v=4","01M6C59YHWS9C7KMXKSRX1YXNP","Lauri Gates","01M6C59YP2APG9YAM4DWYQYGFJ",59,"MIT","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fagent-patterns-plugin\u002Fskills\u002Fexecution-grounded-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"execution grounded review","review","execution","2026","when","parse","opus","pytest","wed","go","git","read","merge","run","worktree","uv","files","git worktree","log","code","Bash","acceptance","gh pr","2026-11-10 10:12:30",false,"---\nname: execution-grounded-review\ndescription: \"Execution-grounded review: run tests first, trace each acceptance criterion to execution evidence. Use when verifying an implementation meets spec.\"\nargs: \"[target] [--criteria \u003Cfile>]\"\nargument-hint: \"diff|PR|files to verify; optional --criteria \u003Cfile> of acceptance criteria\"\nallowed-tools: Agent, Read, Glob, Grep, Bash(git diff *), Bash(git log *), Bash(git merge-base *), Bash(git worktree *), Bash(git rev-parse *), Bash(gh pr view *), Bash(npm *), Bash(npx *), Bash(uv run *), Bash(pytest *), Bash(cargo *), Bash(go test *), TodoWrite\nmodel: opus\ncreated: 2026-06-22\nmodified: 2026-10-07\ncompatibility: claude-code\nreviewed: 2026-09-02\n---\n\n\u003C!-- skill-size-exception: scripts\u002Fcheck-loop-integrity.sh -->\n\n# Execution-Grounded Review\n\nA normal review reads the diff and asks *\"does this look right?\"* — and an\nimplementation can *look* complete while a criterion silently fails. This skill\nrefuses to grade an implementation on appearance: it **runs the suite first**,\nthen traces each acceptance criterion to **execution evidence** — a test that\nactually exercised it, or observed behaviour — and marks anything it cannot\nback with execution as `UNVERIFIED` rather than passing it on faith.\n\nIt is the **execution-grounded verifier** in the agent-patterns review family:\nwhere `adversarial-review` attacks a *design* for faults and `cold-read-gate`\nmeasures whether *text* survives a reader, this skill verifies that *running\ncode* meets its *stated acceptance criteria*. It is the reusable independent\nverifier a judgement-based loop gate delegates to (`.claude\u002Frules\u002Floop-integrity.md`, Pillar 1).\n\n## When to Use This Skill\n\n| Use this skill when... | Use something else instead when... |\n|---|---|\n| Verifying an implementation meets explicit acceptance criteria, proven by running it | First-pass review of a diff → `code-quality-plugin:code-review` |\n| Gating a loop\u002Fphase `done` on an independent check of *behaviour* | Red-teaming a *design* or ADR for faults → `agent-patterns-plugin:adversarial-review` |\n| Confirming a fix actually fixes the reported failure (not just compiles) | Checking *premises\u002Ffacts* before work starts → `agent-patterns-plugin:verify-before-plan` |\n| Closing the loop on \"is every requirement actually covered by a test?\" | Legibility of outward text → `agent-patterns-plugin:cold-read-gate` |\n\n## The Stance\n\n| Move | What it means |\n|---|---|\n| **Execute first** | Run the full suite + typecheck + lint *before* any verdict. A criterion is `PASS` only with execution evidence — never \"the code looks like it does this\". |\n| **Trace each criterion** | One ledger row per acceptance criterion: premise → evidence (file:line \u002F test name \u002F observed output) → verdict. |\n| **No silent pass** | A criterion with no execution backing is `UNVERIFIED` (a coverage gap to surface), not an assumed pass. |\n| **Flaws before the verdict** | The report states its narrative-changing limitations — gaps and caveats that would flip or weaken the verdict — *ahead of* the verdict, and says `none` explicitly when there are none (Step 5). |\n| **Match the production sequence** | For a round-trip \u002F determinism \u002F reproducibility \u002F idempotence claim, a passing test is evidence only if its *operation sequence* reproduces the real production call path — not a convenient shorter one (see Step 3a). |\n| **Intent-starved verifier** | The isolated verifier reads the criteria, the diff, and the captured execution evidence — *not* the author's plan narrative or rationale, which would let it rationalise a pass. |\n| **Bounded loop** | One revise round on `fail`; a third means a structural problem the gate can't resolve. |\n\n> **Model is opus** — like `adversarial-review`, the inverse of `cold-read-gate`:\n> building an accurate requirement→evidence ledger is a reasoning task.\n\n## Parameters\n\nParse `$ARGUMENTS`:\n\n- **Target** (first positional) — what to verify: a path, a PR ref (`#123` or\n  URL), explicit files, or absent. If absent, default to the current change\n  (`git diff HEAD` + staged) and say so.\n- **`--criteria \u003Cfile>`** (optional) — a file of acceptance criteria. If absent,\n  gather criteria from the task\u002Fplan in context (the acceptance criteria stated\n  for this change) and **echo them back** before verifying, so the user can\n  correct the list the skill is grading against.\n\n## Execution\n\nExecute this execution-grounded verification:\n\n### Step 1: Run the suite first\n\nBefore reading the diff for \"correctness\", establish ground truth by execution.\nDetect and run the project's full suite + typecheck + lint, capturing output to\na scratch file (this is the **execution evidence** the verifier grades against):\n\n| Stack | Suite | Typecheck | Lint |\n|---|---|---|---|\n| Node\u002FTS | `npm test` (or `npx vitest run`) | `npx tsc --noEmit` | `npx biome check` |\n| Python | `uv run pytest -q` | `uv run ty check` | `uv run ruff check` |\n| Rust | `cargo test` | `cargo check` | `cargo clippy` |\n| Go | `go test .\u002F...` | `go vet .\u002F...` | — |\n\nRecord the exit codes and failing-test names. A red suite is itself an\n*independent* signal — a failing test does not care how hard the author worked\n(`.claude\u002Frules\u002Floop-integrity.md`).\n\n**When any step exits red, separate new failures from pre-existing ones.** Run\nthe same command on the merge-base (`git merge-base HEAD origin\u002F\u003Cdefault>`,\nchecked out in a throwaway `git worktree`) and record each failure as *new*\n(passes on the base, fails on the head) or *pre-existing* (fails on both). Only\na red run pays for this second run. If the base run cannot be made, record that:\nthe comparison is then missing evidence, never an assumed pass.\n\n### Step 2: Name the criteria\n\nState, in one numbered list, the acceptance criteria under verification (from\n`--criteria` or context). Each criterion is one ledger row in Step 3.\n\nAlways append one implicit criterion, last: **No regression — no test that\npasses on the merge-base fails on the head.** Grade it from Step 1's base\ncomparison: `PASS` when nothing failed or every failure is pre-existing, `FAIL`\nnaming each new failure, `UNVERIFIED` when a step is red and no base comparison\nexists. This is how breakage outside the listed criteria reaches the verdict\nwithout each caller restating it, while failures already on the base do not\nblock a change that did not cause them.\n\nIf there are no stated criteria, or no execution evidence (Step 1 could not run and\nnone was supplied), stop: emit no ledger and no `VERDICT` line, name the missing\ninput, and ask for it. A missing input is not a `fail` — `fail` claims the code\nwas graded and found wanting, and nothing was graded.\n\n### Step 3: Dispatch the intent-starved verifier\n\nOne `Agent`, `model: opus`, reading **only** the criteria, the diff, and the\ncaptured execution-evidence file — not the author's reasoning. Bind its output\nto the `LEDGER` schema below and paste that schema **verbatim** into the brief:\na schema forces a determinate answer on every row where prose lets a row go\nquietly unanswered.\n\n#### The `LEDGER` schema\n\n```json\n{\n  \"type\": \"object\",\n  \"required\": [\"rows\", \"coverage\", \"limitations\", \"verdict\"],\n  \"properties\": {\n    \"rows\": {\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"required\": [\"criterion\", \"evidence\", \"evidenceSpan\", \"verdict\", \"sequenceMatchesProduction\"],\n        \"properties\": {\n          \"criterion\": { \"type\": \"string\" },\n          \"evidence\": { \"type\": \"string\" },\n          \"evidenceSpan\": { \"type\": \"string\" },\n          \"verdict\": { \"enum\": [\"PASS\", \"FAIL\", \"PARTIAL\", \"UNVERIFIED\"] },\n          \"sequenceMatchesProduction\": { \"enum\": [\"yes\", \"no\", \"not-applicable\"] }\n        }\n      }\n    },\n    \"coverage\": { \"type\": \"string\" },\n    \"limitations\": {\n      \"type\": \"array\",\n      \"minItems\": 1,\n      \"items\": { \"type\": \"string\" }\n    },\n    \"verdict\": { \"enum\": [\"pass\", \"fail\"] }\n  }\n}\n```\n\n`evidence` is the test name \u002F `file:line` \u002F observed output drawn from the\nexecution-evidence file, or the literal `none`. `evidenceSpan` is where that\nevidence sits in the execution-evidence file — `\u003Cfile>:\u003CstartLine>-\u003CendLine>` —\nor the literal `none`; it lets the caller check an attribution instead of\ntrusting it (Step 3b). It carries no `maxLength` or `pattern` on purpose: a\nlocator rejected by a length cap gets resent, not fixed (#2280). `coverage` is\n`\u003C#rows with PASS\u002FFAIL evidence> \u002F \u003Ctotal rows>`.\n\n`limitations` lists every **narrative-changing** fact — one that, read after the\nverdict, would change what the verdict means. It sits before `verdict` in the\nschema and in the report on purpose, and it carries `minItems: 1`: when there is\nnothing to declare, the single entry is the literal `none`, so an absent caveat\nis a stated claim rather than an omission. One entry per item, from this\nchecklist:\n\n| Must appear in `limitations` | Why it changes the narrative |\n|---|---|\n| Every `UNVERIFIED` row, by criterion | The verdict rests on fewer criteria than were listed |\n| Every suite \u002F typecheck \u002F lint step that was skipped, errored before running, or ran on a subset (filtered, `--bail`, `-k`) | Step 1 evidence is narrower than \"the suite passed\" implies |\n| Every row with `sequenceMatchesProduction: \"no\"` | A green test exists but does not cover the production path |\n| Every `FAIL` or `PARTIAL` row whose `evidenceSpan` is `none` | The failure's cause was not located within the bound (Step 3b) |\n| Any caveat that would flip `pass` → `fail` if it proved true (flaky rerun, environment-only pass, stale evidence predating the last push) | The pass is conditional, and the reader must know on what |\n| Every step still running, timed out, or whose output is truncated or missing | The verdict describes a partial result as if it were complete |\n| Every pre-existing failure — red on both the merge-base and the head | The suite is red for a reason this change did not cause, and a reader who sees `pass` must know it |\n| Collateral damage no failing test catches: side effects or broken behaviour outside the listed criteria — including anything Step 4 drops from the verdict | Every criterion can pass while the change breaks something the suite does not cover |\n| Any factual claim in the inputs (a pass count, a metric, \"all green\") that the execution output does not back | The report would repeat a success the evidence never showed |\n\nEvery entry points at something the inputs show, or show to be missing: a step\nthat did not run, an output line, a criterion with no test. Speculative risks\nwith no sign in the inputs — code the verifier did not open, evidence that\n\"might\" be stale with no later commit named — are not limitations. Listing them\nis the measured false-flag cost of over-reporting, and it makes `none` unreachable\non a clean run.\n\nWhy this field exists, which parts the source paper measured, and which parts\nare this skill's own extension: [REFERENCE.md](REFERENCE.md) § Insecure reporting.\n\n| Row verdict | Meaning |\n|---|---|\n| `PASS` | execution evidence demonstrates the criterion holds |\n| `FAIL` | execution evidence demonstrates it is violated — name the concrete failing input\u002Ftest |\n| `PARTIAL` | covered for some inputs; a *stated* edge case is unhandled |\n| `UNVERIFIED` | no execution exercises this criterion (a coverage gap) — never pass a row because the code \"looks right\" |\n\n**`sequenceMatchesProduction` is required on every row**, and that requirement\nis the entire gain of the schema. Step 3a's check is the one a verifier skips\nsilently when it is only prose, because a green test *looks* like evidence — a\nrequired enum makes \"I did not check\" unrepresentable.\n\n| Value | When |\n|---|---|\n| `yes` | the test's operation sequence reproduces the real production call path |\n| `no` | the test passes over a shorter or rearranged sequence than production uses → the row's `verdict` becomes `UNVERIFIED` |\n| `not-applicable` | the criterion makes no round-trip \u002F determinism \u002F reproducibility \u002F idempotence claim |\n\nThe overall `verdict` is `pass` only when every row is `PASS`, no row is\n`sequenceMatchesProduction: \"no\"`, **and** every Step 1 step ran to completion\nover the full suite. Any `FAIL`, any `UNVERIFIED`, any sequence divergence, or a\nStep 1 step that was skipped, errored before running, ran on a subset, or is\nstill running makes it `fail`. Step 1 is a precondition of the verdict, not a\ncaveat to list beside a `pass`.\n\nTemplate:\n\n```\nsubagent_type: general-purpose\nmodel: opus\nprompt: |\n  You verify whether an implementation meets its acceptance criteria, grounded\n  in EXECUTION EVIDENCE. Read ONLY these inputs (no other files, no repo\n  exploration beyond resolving evidence cited below):\n    - Acceptance criteria: \u003Cnumbered list from Step 2>\n    - The change under review: \u003Cdiff \u002F file paths>\n    - Execution evidence (suite\u002Ftypecheck\u002Flint output): \u003Cscratch file path>\n\n  Do NOT read the author's plan, commit narrative, or rationale — grade the\n  behaviour, not the intent.\n\n  Emit ONE object conforming to this schema, with one row per criterion:\n    \u003Cpaste the LEDGER schema verbatim>\n\n  For every row, decide `sequenceMatchesProduction` explicitly: identify what\n  real call sequence exercises the claim in production and confirm the test\n  reproduces that sequence, not just a convenient shorter one.\n\n  When a criterion fails and the evidence file is long, locate before you read:\n  `grep -n` it for anchors from the criterion (test name, assertion text, error\n  class, changed file path), read only a window around each hit, and let a\n  candidate that does not explain the failure narrow the next query. Stop after\n  3 search rounds or 5 windows for that criterion; if nothing explains it, set\n  its `evidenceSpan` to \"none\" and say the cause was not located.\n  Cite evidence and its `evidenceSpan` for every row. Fill `limitations` from\n  the checklist (UNVERIFIED rows, skipped\u002Fpartial\u002Fstill-running steps, sequence\n  mismatches, unlocated spans, verdict-flipping caveats, collateral damage\n  outside the criteria, claims the output does not back); if there are none,\n  write the single entry \"none\" — never omit the field. Be honest in your response.\n  Your final message is the deliverable.\n```\n\n> **No workflow harness here — deliberately.** The schema is the whole delta;\n> agent count stays at one. This skill is the Pillar-1 oracle other loops\n> delegate their stop condition to, so a fan-out design would multiply through\n> every iteration of every loop in the repo — the one place where per-invocation\n> cost compounds rather than adds (`.claude\u002Frules\u002Fworkflow-vs-skill.md`).\n\nFor several independent targets, dispatch one verifier per target in a\nsingle-message parallel `Agent` batch — except on a 1M-context model (every\nFable 5.1 session, or Opus with the `[1m]` suffix), where the concurrent-\nsubagent rate-limit caveat applies (`skill-fork-context.md`); run those\nsequentially. Do **not** set `context: fork` — the caller needs the ledger\nin the main context to act on it.\n\n### Step 3a: Match the test's operation sequence to production\n\n\"A passing test exists for this claim\" is **not** sufficient evidence for a\nround-trip, determinism, reproducibility, or idempotence claim. The test can\npass while the design is broken, because a narrower hand-built repro silently\navoids the exact *ordering* that would expose a divergence. The tell is when the\ntest's sequence of operations differs from the real call path production uses.\n\nSo for any such claim, add a step to the verifier's brief:\n\n> Identify what real call sequence exercises this claim in production, and\n> confirm the test under review reproduces that sequence — not just a convenient\n> shorter one.\n\n**Stateful \u002F RNG-dependent code is the high-risk class** — lazy initialization,\nglobal mutable RNG state, and caching all defer or share observable state, so\n*when* an operation runs relative to its neighbours changes the result. A test\nof the shape `construct → forward immediately` and a production path of\n`construct → generate batches (consuming lazy RNG) → first forward` draw their\ndeferred state at the *same relative point in each stream*, so the round-trip\n\"works\" with no error — while a real trained model's reload diverges. The\npassing test is real; it just exercises the one ordering that can't see the bug.\n\nGrade such a claim `UNVERIFIED` until the test reproduces the production\nsequence, even though a green test exists — that is the row whose\n`sequenceMatchesProduction` is `no`.\n\n### Step 3b: Attribute a failure by searching the trace, not reading it\n\nWhen a criterion fails on a **long** run, its evidence is usually sparse and\nspread across actions far apart in the trace. Reading end to end gets worse as\nthe trace grows: the relevant lines are diluted by irrelevant ones, and the\nreader settles on the most recent plausible cause rather than the actual one.\nSummarising first does not help — a summary is exactly where sparse evidence is\ndropped. So when a row is heading for `FAIL` or `PARTIAL` and the\nexecution-evidence file is longer than one pass (roughly 300+ lines), the\nverifier searches instead:\n\n1. **Locate first.** `grep -n` the evidence file for anchors taken from the\n   criterion — the test name, the assertion text, the error class, the changed\n   file's path. Each hit is a candidate.\n2. **Read narrowly.** Open only a window around each candidate (about ±20\n   lines), never the file end to end.\n3. **Narrow, don't stop.** A candidate that does not explain the failure feeds\n   the next query — drop its anchor, add the symbol it pointed at — rather than\n   ending the search on the nearest plausible line.\n4. **Report the span.** The window that explains the failure becomes the row's\n   `evidenceSpan`, so the caller can open that range and check the attribution.\n\n**Attribution bound:** at most 3 search rounds and 5 candidate windows per\ncriterion — the hard ceiling `.claude\u002Frules\u002Floop-integrity.md` (\"Bounding\nrunaway\") requires of every loop. When the bound is reached with no explaining\nspan, the row records `evidenceSpan: \"none\"` and states that the cause was not\nlocated within the bound. That row goes to a human; it is never filled with the\nmost plausible-looking line. A named failing test in `evidence` still stands —\nthe missing span says only that its cause was not pinned down.\n\n### Step 4: Triage against over-correction\n\nThe verifier grades strictly, so guard **both** failure modes before acting —\nneither talk yourself into passing broken code, nor into failing correct code:\n\n| Act on it | Drop it |\n|---|---|\n| A `FAIL` with a named failing test\u002Finput | A `FAIL` on a requirement the spec never stated (the implicit no-regression criterion counts as stated) |\n| An `UNVERIFIED` criterion → write\u002Frun the missing test, then re-grade | An `UNVERIFIED` on behaviour outside the change's responsibility |\n| A `PARTIAL` where a *stated* edge case is unhandled | Style\u002Fpreference dressed up as a criterion failure |\n| A coverage gap on a load-bearing criterion | A hypothetical input the contract makes impossible |\n| A round-trip\u002Fdeterminism test whose sequence diverges from production (Step 3a) | A sequence difference that provably can't affect the claim's outcome |\n\n**\"Drop\" removes an item from the verdict, never from the report.** \"Outside\nthe scope of the task\" is a recorded rationalisation for concealing a flaw\n([REFERENCE.md](REFERENCE.md)), so a dropped item that is still narrative-changing — a\nfailing test unrelated to the criteria, a side effect on shared state, broken\nbehaviour the spec never mentioned — goes into `LIMITATIONS` as collateral\ndamage. Only items that cannot change the story leave the report entirely:\nstyle preferences, impossible inputs, and sequence differences that provably\ncannot affect the outcome.\n\n### Step 5: Report and bound the loop\n\nEmit the ledger in this order — the limitations come **before** the verdict, so\na reader who stops at the verdict has already seen what it rests on:\n\n```\nTARGET: \u003Ctarget>\nROWS: \u003Cper-criterion rows with evidence and evidenceSpan>\nCOVERAGE: \u003Cn>\u002F\u003Ctotal>\nLIMITATIONS:\n  - \u003Cone narrative-changing item per line, or the single line \"none\">\nVERDICT: pass|fail\n```\n\n`LIMITATIONS` is never omitted and never left empty: an empty list is written as\n`none`. A report that carries a `VERDICT` line with no `LIMITATIONS` block above\nit is malformed — re-emit it rather than acting on it. When Step 2 stopped for a\nmissing input, there is no report to emit; ask for the input instead.\n\nApply or hand off the genuine fixes (closing `UNVERIFIED` rows by adding the\nmissing test counts as a fix). Re-run from Step 1 **only if the\nverdict was `fail`**; do not loop more than twice — a third round means a\nstructural problem the gate can't resolve, which is the signal to surface to a\nhuman, not to keep grinding.\n\n## Anti-patterns\n\nMistakes and the step that corrects each: [references\u002Fanti-patterns.md](references\u002Fanti-patterns.md).\n\n## Related\n\n- [`adversarial-review`](..\u002Fadversarial-review\u002FSKILL.md) — attacks a *design*\n  for faults; this skill verifies *running behaviour* against criteria\n- [`verify-before-plan`](..\u002Fverify-before-plan\u002FSKILL.md) — verifies *premises*\n  before work; this verifies *outcomes* after\n- [`cold-read-gate`](..\u002Fcold-read-gate\u002FSKILL.md) — the isolation + triage +\n  bounded-loop pattern this skill reuses (legibility lens; uses haiku)\n- `code-quality-plugin:code-review` — the first-pass review this layers on top of\n- `workflow-orchestration-plugin:workflow-checkpoint-refactor` — a loop whose\n  phase gate delegates its independent verdict here\n- `.claude\u002Frules\u002Floop-integrity.md` — Pillar 1: a loop's stop condition is judged\n  by an independent verifier like this one, not the worker. **Keep this literal\n  path in the body**: `scripts\u002Fcheck-loop-integrity.sh` requires the token\n  `loop-integrity.md` in this file, so a later \"tighten the Related section\" edit\n  that drops it fails the build.\n","\u003C!-- skill-size-exception: scripts\u002Fcheck-loop-integrity.sh -->\n\n# Execution-Grounded Review\n\nA normal review reads the diff and asks *\"does this look right?\"* — and an\nimplementation can *look* complete while a criterion silently fails. This skill\nrefuses to grade an implementation on appearance: it **runs the suite first**,\nthen traces each acceptance criterion to **execution evidence** — a test that\nactually exercised it, or observed behaviour — and marks anything it cannot\nback with execution as `UNVERIFIED` rather than passing it on faith.\n\nIt is the **execution-grounded verifier** in the agent-patterns review family:\nwhere `adversarial-review` attacks a *design* for faults and `cold-read-gate`\nmeasures whether *text* survives a reader, this skill verifies that *running\ncode* meets its *stated acceptance criteria*. It is the reusable independent\nverifier a judgement-based loop gate delegates to (`.claude\u002Frules\u002Floop-integrity.md`, Pillar 1).\n\n## When to Use This Skill\n\n| Use this skill when... | Use something else instead when... |\n|---|---|\n| Verifying an implementation meets explicit acceptance criteria, proven by running it | First-pass review of a diff → `code-quality-plugin:code-review` |\n| Gating a loop\u002Fphase `done` on an independent check of *behaviour* | Red-teaming a *design* or ADR for faults → `agent-patterns-plugin:adversarial-review` |\n| Confirming a fix actually fixes the reported failure (not just compiles) | Checking *premises\u002Ffacts* before work starts → `agent-patterns-plugin:verify-before-plan` |\n| Closing the loop on \"is every requirement actually covered by a test?\" | Legibility of outward text → `agent-patterns-plugin:cold-read-gate` |\n\n## The Stance\n\n| Move | What it means |\n|---|---|\n| **Execute first** | Run the full suite + typecheck + lint *before* any verdict. A criterion is `PASS` only with execution evidence — never \"the code looks like it does this\". |\n| **Trace each criterion** | One ledger row per acceptance criterion: premise → evidence (file:line \u002F test name \u002F observed output) → verdict. |\n| **No silent pass** | A criterion with no execution backing is `UNVERIFIED` (a coverage gap to surface), not an assumed pass. |\n| **Flaws before the verdict** | The report states its narrative-changing limitations — gaps and caveats that would flip or weaken the verdict — *ahead of* the verdict, and says `none` explicitly when there are none (Step 5). |\n| **Match the production sequence** | For a round-trip \u002F determinism \u002F reproducibility \u002F idempotence claim, a passing test is evidence only if its *operation sequence* reproduces the real production call path — not a convenient shorter one (see Step 3a). |\n| **Intent-starved verifier** | The isolated verifier reads the criteria, the diff, and the captured execution evidence — *not* the author's plan narrative or rationale, which would let it rationalise a pass. |\n| **Bounded loop** | One revise round on `fail`; a third means a structural problem the gate can't resolve. |\n\n> **Model is opus** — like `adversarial-review`, the inverse of `cold-read-gate`:\n> building an accurate requirement→evidence ledger is a reasoning task.\n\n## Parameters\n\nParse `$ARGUMENTS`:\n\n- **Target** (first positional) — what to verify: a path, a PR ref (`#123` or\n  URL), explicit files, or absent. If absent, default to the current change\n  (`git diff HEAD` + staged) and say so.\n- **`--criteria \u003Cfile>`** (optional) — a file of acceptance criteria. If absent,\n  gather criteria from the task\u002Fplan in context (the acceptance criteria stated\n  for this change) and **echo them back** before verifying, so the user can\n  correct the list the skill is grading against.\n\n## Execution\n\nExecute this execution-grounded verification:\n\n### Step 1: Run the suite first\n\nBefore reading the diff for \"correctness\", establish ground truth by execution.\nDetect and run the project's full suite + typecheck + lint, capturing output to\na scratch file (this is the **execution evidence** the verifier grades against):\n\n| Stack | Suite | Typecheck | Lint |\n|---|---|---|---|\n| Node\u002FTS | `npm test` (or `npx vitest run`) | `npx tsc --noEmit` | `npx biome check` |\n| Python | `uv run pytest -q` | `uv run ty check` | `uv run ruff check` |\n| Rust | `cargo test` | `cargo check` | `cargo clippy` |\n| Go | `go test .\u002F...` | `go vet .\u002F...` | — |\n\nRecord the exit codes and failing-test names. A red suite is itself an\n*independent* signal — a failing test does not care how hard the author worked\n(`.claude\u002Frules\u002Floop-integrity.md`).\n\n**When any step exits red, separate new failures from pre-existing ones.** Run\nthe same command on the merge-base (`git merge-base HEAD origin\u002F\u003Cdefault>`,\nchecked out in a throwaway `git worktree`) and record each failure as *new*\n(passes on the base, fails on the head) or *pre-existing* (fails on both). Only\na red run pays for this second run. If the base run cannot be made, record that:\nthe comparison is then missing evidence, never an assumed pass.\n\n### Step 2: Name the criteria\n\nState, in one numbered list, the acceptance criteria under verification (from\n`--criteria` or context). Each criterion is one ledger row in Step 3.\n\nAlways append one implicit criterion, last: **No regression — no test that\npasses on the merge-base fails on the head.** Grade it from Step 1's base\ncomparison: `PASS` when nothing failed or every failure is pre-existing, `FAIL`\nnaming each new failure, `UNVERIFIED` when a step is red and no base comparison\nexists. This is how breakage outside the listed criteria reaches the verdict\nwithout each caller restating it, while failures already on the base do not\nblock a change that did not cause them.\n\nIf there are no stated criteria, or no execution evidence (Step 1 could not run and\nnone was supplied), stop: emit no ledger and no `VERDICT` line, name the missing\ninput, and ask for it. A missing input is not a `fail` — `fail` claims the code\nwas graded and found wanting, and nothing was graded.\n\n### Step 3: Dispatch the intent-starved verifier\n\nOne `Agent`, `model: opus`, reading **only** the criteria, the diff, and the\ncaptured execution-evidence file — not the author's reasoning. Bind its output\nto the `LEDGER` schema below and paste that schema **verbatim** into the brief:\na schema forces a determinate answer on every row where prose lets a row go\nquietly unanswered.\n\n#### The `LEDGER` schema\n\n```json\n{\n  \"type\": \"object\",\n  \"required\": [\"rows\", \"coverage\", \"limitations\", \"verdict\"],\n  \"properties\": {\n    \"rows\": {\n      \"type\": \"array\",\n      \"items\": {\n        \"type\": \"object\",\n        \"required\": [\"criterion\", \"evidence\", \"evidenceSpan\", \"verdict\", \"sequenceMatchesProduction\"],\n        \"properties\": {\n          \"criterion\": { \"type\": \"string\" },\n          \"evidence\": { \"type\": \"string\" },\n          \"evidenceSpan\": { \"type\": \"string\" },\n          \"verdict\": { \"enum\": [\"PASS\", \"FAIL\", \"PARTIAL\", \"UNVERIFIED\"] },\n          \"sequenceMatchesProduction\": { \"enum\": [\"yes\", \"no\", \"not-applicable\"] }\n        }\n      }\n    },\n    \"coverage\": { \"type\": \"string\" },\n    \"limitations\": {\n      \"type\": \"array\",\n      \"minItems\": 1,\n      \"items\": { \"type\": \"string\" }\n    },\n    \"verdict\": { \"enum\": [\"pass\", \"fail\"] }\n  }\n}\n```\n\n`evidence` is the test name \u002F `file:line` \u002F observed output drawn from the\nexecution-evidence file, or the literal `none`. `evidenceSpan` is where that\nevidence sits in the execution-evidence file — `\u003Cfile>:\u003CstartLine>-\u003CendLine>` —\nor the literal `none`; it lets the caller check an attribution instead of\ntrusting it (Step 3b). It carries no `maxLength` or `pattern` on purpose: a\nlocator rejected by a length cap gets resent, not fixed (#2280). `coverage` is\n`\u003C#rows with PASS\u002FFAIL evidence> \u002F \u003Ctotal rows>`.\n\n`limitations` lists every **narrative-changing** fact — one that, read after the\nverdict, would change what the verdict means. It sits before `verdict` in the\nschema and in the report on purpose, and it carries `minItems: 1`: when there is\nnothing to declare, the single entry is the literal `none`, so an absent caveat\nis a stated claim rather than an omission. One entry per item, from this\nchecklist:\n\n| Must appear in `limitations` | Why it changes the narrative |\n|---|---|\n| Every `UNVERIFIED` row, by criterion | The verdict rests on fewer criteria than were listed |\n| Every suite \u002F typecheck \u002F lint step that was skipped, errored before running, or ran on a subset (filtered, `--bail`, `-k`) | Step 1 evidence is narrower than \"the suite passed\" implies |\n| Every row with `sequenceMatchesProduction: \"no\"` | A green test exists but does not cover the production path |\n| Every `FAIL` or `PARTIAL` row whose `evidenceSpan` is `none` | The failure's cause was not located within the bound (Step 3b) |\n| Any caveat that would flip `pass` → `fail` if it proved true (flaky rerun, environment-only pass, stale evidence predating the last push) | The pass is conditional, and the reader must know on what |\n| Every step still running, timed out, or whose output is truncated or missing | The verdict describes a partial result as if it were complete |\n| Every pre-existing failure — red on both the merge-base and the head | The suite is red for a reason this change did not cause, and a reader who sees `pass` must know it |\n| Collateral damage no failing test catches: side effects or broken behaviour outside the listed criteria — including anything Step 4 drops from the verdict | Every criterion can pass while the change breaks something the suite does not cover |\n| Any factual claim in the inputs (a pass count, a metric, \"all green\") that the execution output does not back | The report would repeat a success the evidence never showed |\n\nEvery entry points at something the inputs show, or show to be missing: a step\nthat did not run, an output line, a criterion with no test. Speculative risks\nwith no sign in the inputs — code the verifier did not open, evidence that\n\"might\" be stale with no later commit named — are not limitations. Listing them\nis the measured false-flag cost of over-reporting, and it makes `none` unreachable\non a clean run.\n\nWhy this field exists, which parts the source paper measured, and which parts\nare this skill's own extension: [REFERENCE.md](REFERENCE.md) § Insecure reporting.\n\n| Row verdict | Meaning |\n|---|---|\n| `PASS` | execution evidence demonstrates the criterion holds |\n| `FAIL` | execution evidence demonstrates it is violated — name the concrete failing input\u002Ftest |\n| `PARTIAL` | covered for some inputs; a *stated* edge case is unhandled |\n| `UNVERIFIED` | no execution exercises this criterion (a coverage gap) — never pass a row because the code \"looks right\" |\n\n**`sequenceMatchesProduction` is required on every row**, and that requirement\nis the entire gain of the schema. Step 3a's check is the one a verifier skips\nsilently when it is only prose, because a green test *looks* like evidence — a\nrequired enum makes \"I did not check\" unrepresentable.\n\n| Value | When |\n|---|---|\n| `yes` | the test's operation sequence reproduces the real production call path |\n| `no` | the test passes over a shorter or rearranged sequence than production uses → the row's `verdict` becomes `UNVERIFIED` |\n| `not-applicable` | the criterion makes no round-trip \u002F determinism \u002F reproducibility \u002F idempotence claim |\n\nThe overall `verdict` is `pass` only when every row is `PASS`, no row is\n`sequenceMatchesProduction: \"no\"`, **and** every Step 1 step ran to completion\nover the full suite. Any `FAIL`, any `UNVERIFIED`, any sequence divergence, or a\nStep 1 step that was skipped, errored before running, ran on a subset, or is\nstill running makes it `fail`. Step 1 is a precondition of the verdict, not a\ncaveat to list beside a `pass`.\n\nTemplate:\n\n```\nsubagent_type: general-purpose\nmodel: opus\nprompt: |\n  You verify whether an implementation meets its acceptance criteria, grounded\n  in EXECUTION EVIDENCE. Read ONLY these inputs (no other files, no repo\n  exploration beyond resolving evidence cited below):\n    - Acceptance criteria: \u003Cnumbered list from Step 2>\n    - The change under review: \u003Cdiff \u002F file paths>\n    - Execution evidence (suite\u002Ftypecheck\u002Flint output): \u003Cscratch file path>\n\n  Do NOT read the author's plan, commit narrative, or rationale — grade the\n  behaviour, not the intent.\n\n  Emit ONE object conforming to this schema, with one row per criterion:\n    \u003Cpaste the LEDGER schema verbatim>\n\n  For every row, decide `sequenceMatchesProduction` explicitly: identify what\n  real call sequence exercises the claim in production and confirm the test\n  reproduces that sequence, not just a convenient shorter one.\n\n  When a criterion fails and the evidence file is long, locate before you read:\n  `grep -n` it for anchors from the criterion (test name, assertion text, error\n  class, changed file path), read only a window around each hit, and let a\n  candidate that does not explain the failure narrow the next query. Stop after\n  3 search rounds or 5 windows for that criterion; if nothing explains it, set\n  its `evidenceSpan` to \"none\" and say the cause was not located.\n  Cite evidence and its `evidenceSpan` for every row. Fill `limitations` from\n  the checklist (UNVERIFIED rows, skipped\u002Fpartial\u002Fstill-running steps, sequence\n  mismatches, unlocated spans, verdict-flipping caveats, collateral damage\n  outside the criteria, claims the output does not back); if there are none,\n  write the single entry \"none\" — never omit the field. Be honest in your response.\n  Your final message is the deliverable.\n```\n\n> **No workflow harness here — deliberately.** The schema is the whole delta;\n> agent count stays at one. This skill is the Pillar-1 oracle other loops\n> delegate their stop condition to, so a fan-out design would multiply through\n> every iteration of every loop in the repo — the one place where per-invocation\n> cost compounds rather than adds (`.claude\u002Frules\u002Fworkflow-vs-skill.md`).\n\nFor several independent targets, dispatch one verifier per target in a\nsingle-message parallel `Agent` batch — except on a 1M-context model (every\nFable 5.1 session, or Opus with the `[1m]` suffix), where the concurrent-\nsubagent rate-limit caveat applies (`skill-fork-context.md`); run those\nsequentially. Do **not** set `context: fork` — the caller needs the ledger\nin the main context to act on it.\n\n### Step 3a: Match the test's operation sequence to production\n\n\"A passing test exists for this claim\" is **not** sufficient evidence for a\nround-trip, determinism, reproducibility, or idempotence claim. The test can\npass while the design is broken, because a narrower hand-built repro silently\navoids the exact *ordering* that would expose a divergence. The tell is when the\ntest's sequence of operations differs from the real call path production uses.\n\nSo for any such claim, add a step to the verifier's brief:\n\n> Identify what real call sequence exercises this claim in production, and\n> confirm the test under review reproduces that sequence — not just a convenient\n> shorter one.\n\n**Stateful \u002F RNG-dependent code is the high-risk class** — lazy initialization,\nglobal mutable RNG state, and caching all defer or share observable state, so\n*when* an operation runs relative to its neighbours changes the result. A test\nof the shape `construct → forward immediately` and a production path of\n`construct → generate batches (consuming lazy RNG) → first forward` draw their\ndeferred state at the *same relative point in each stream*, so the round-trip\n\"works\" with no error — while a real trained model's reload diverges. The\npassing test is real; it just exercises the one ordering that can't see the bug.\n\nGrade such a claim `UNVERIFIED` until the test reproduces the production\nsequence, even though a green test exists — that is the row whose\n`sequenceMatchesProduction` is `no`.\n\n### Step 3b: Attribute a failure by searching the trace, not reading it\n\nWhen a criterion fails on a **long** run, its evidence is usually sparse and\nspread across actions far apart in the trace. Reading end to end gets worse as\nthe trace grows: the relevant lines are diluted by irrelevant ones, and the\nreader settles on the most recent plausible cause rather than the actual one.\nSummarising first does not help — a summary is exactly where sparse evidence is\ndropped. So when a row is heading for `FAIL` or `PARTIAL` and the\nexecution-evidence file is longer than one pass (roughly 300+ lines), the\nverifier searches instead:\n\n1. **Locate first.** `grep -n` the evidence file for anchors taken from the\n   criterion — the test name, the assertion text, the error class, the changed\n   file's path. Each hit is a candidate.\n2. **Read narrowly.** Open only a window around each candidate (about ±20\n   lines), never the file end to end.\n3. **Narrow, don't stop.** A candidate that does not explain the failure feeds\n   the next query — drop its anchor, add the symbol it pointed at — rather than\n   ending the search on the nearest plausible line.\n4. **Report the span.** The window that explains the failure becomes the row's\n   `evidenceSpan`, so the caller can open that range and check the attribution.\n\n**Attribution bound:** at most 3 search rounds and 5 candidate windows per\ncriterion — the hard ceiling `.claude\u002Frules\u002Floop-integrity.md` (\"Bounding\nrunaway\") requires of every loop. When the bound is reached with no explaining\nspan, the row records `evidenceSpan: \"none\"` and states that the cause was not\nlocated within the bound. That row goes to a human; it is never filled with the\nmost plausible-looking line. A named failing test in `evidence` still stands —\nthe missing span says only that its cause was not pinned down.\n\n### Step 4: Triage against over-correction\n\nThe verifier grades strictly, so guard **both** failure modes before acting —\nneither talk yourself into passing broken code, nor into failing correct code:\n\n| Act on it | Drop it |\n|---|---|\n| A `FAIL` with a named failing test\u002Finput | A `FAIL` on a requirement the spec never stated (the implicit no-regression criterion counts as stated) |\n| An `UNVERIFIED` criterion → write\u002Frun the missing test, then re-grade | An `UNVERIFIED` on behaviour outside the change's responsibility |\n| A `PARTIAL` where a *stated* edge case is unhandled | Style\u002Fpreference dressed up as a criterion failure |\n| A coverage gap on a load-bearing criterion | A hypothetical input the contract makes impossible |\n| A round-trip\u002Fdeterminism test whose sequence diverges from production (Step 3a) | A sequence difference that provably can't affect the claim's outcome |\n\n**\"Drop\" removes an item from the verdict, never from the report.** \"Outside\nthe scope of the task\" is a recorded rationalisation for concealing a flaw\n([REFERENCE.md](REFERENCE.md)), so a dropped item that is still narrative-changing — a\nfailing test unrelated to the criteria, a side effect on shared state, broken\nbehaviour the spec never mentioned — goes into `LIMITATIONS` as collateral\ndamage. Only items that cannot change the story leave the report entirely:\nstyle preferences, impossible inputs, and sequence differences that provably\ncannot affect the outcome.\n\n### Step 5: Report and bound the loop\n\nEmit the ledger in this order — the limitations come **before** the verdict, so\na reader who stops at the verdict has already seen what it rests on:\n\n```\nTARGET: \u003Ctarget>\nROWS: \u003Cper-criterion rows with evidence and evidenceSpan>\nCOVERAGE: \u003Cn>\u002F\u003Ctotal>\nLIMITATIONS:\n  - \u003Cone narrative-changing item per line, or the single line \"none\">\nVERDICT: pass|fail\n```\n\n`LIMITATIONS` is never omitted and never left empty: an empty list is written as\n`none`. A report that carries a `VERDICT` line with no `LIMITATIONS` block above\nit is malformed — re-emit it rather than acting on it. When Step 2 stopped for a\nmissing input, there is no report to emit; ask for the input instead.\n\nApply or hand off the genuine fixes (closing `UNVERIFIED` rows by adding the\nmissing test counts as a fix). Re-run from Step 1 **only if the\nverdict was `fail`**; do not loop more than twice — a third round means a\nstructural problem the gate can't resolve, which is the signal to surface to a\nhuman, not to keep grinding.\n\n## Anti-patterns\n\nMistakes and the step that corrects each: [references\u002Fanti-patterns.md](references\u002Fanti-patterns.md).\n\n## Related\n\n- [`adversarial-review`](..\u002Fadversarial-review\u002FSKILL.md) — attacks a *design*\n  for faults; this skill verifies *running behaviour* against criteria\n- [`verify-before-plan`](..\u002Fverify-before-plan\u002FSKILL.md) — verifies *premises*\n  before work; this verifies *outcomes* after\n- [`cold-read-gate`](..\u002Fcold-read-gate\u002FSKILL.md) — the isolation + triage +\n  bounded-loop pattern this skill reuses (legibility lens; uses haiku)\n- `code-quality-plugin:code-review` — the first-pass review this layers on top of\n- `workflow-orchestration-plugin:workflow-checkpoint-refactor` — a loop whose\n  phase gate delegates its independent verdict here\n- `.claude\u002Frules\u002Floop-integrity.md` — Pillar 1: a loop's stop condition is judged\n  by an independent verifier like this one, not the worker. **Keep this literal\n  path in the body**: `scripts\u002Fcheck-loop-integrity.sh` requires the token\n  `loop-integrity.md` in this file, so a later \"tighten the Related section\" edit\n  that drops it fails the build.\n",{"args":47,"name":5,"model":25,"created":48,"modified":49,"reviewed":50,"description":7,"allowed-tools":51,"argument-hint":52,"compatibility":53},"[target] [--criteria \u003Cfile>]",1782086400000,1791331200000,1788307200000,"Agent, Read, Glob, Grep, Bash(git diff *), Bash(git log *), Bash(git merge-base *), Bash(git worktree *), Bash(git rev-parse *), Bash(gh pr view *), Bash(npm *), Bash(npx *), Bash(uv run *), Bash(pytest *), Bash(cargo *), Bash(go test *), TodoWrite","diff|PR|files to verify; optional --criteria \u003Cfile> of acceptance criteria","claude-code","main","51e0f120e9cb48382ee27086b2e8be32eff0ac9a","agent-patterns-plugin\u002Fskills\u002Fexecution-grounded-review",6,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins","https:\u002F\u002Fgithub.com\u002Flaurigates","Linux enthusiast, cloud engineer, neovim addict, electronics hobbyist.","2026-11-12 03:43:32",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add laurigates\u002Fclaude-plugins --skill execution-grounded-review",{"tool":68,"command":69},"bunx","bunx skills add laurigates\u002Fclaude-plugins --skill execution-grounded-review",{"tool":71,"command":72},"pnpm","pnpm dlx skills add laurigates\u002Fclaude-plugins --skill execution-grounded-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fagent-patterns-plugin\u002Fskills\u002Fexecution-grounded-review\u002FSKILL.md",true,[76,82,86],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"evals.json","REFERENCE","参考文档",32110,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fagent-patterns-plugin\u002Fskills\u002Fexecution-grounded-review\u002Fevals.json",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"REFERENCE.md",4077,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fagent-patterns-plugin\u002Fskills\u002Fexecution-grounded-review\u002FREFERENCE.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fanti-patterns.md",1368,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fagent-patterns-plugin\u002Fskills\u002Fexecution-grounded-review\u002Freferences\u002Fanti-patterns.md",[91,119,140,156,178,206],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":102,"publishedAt":42},"01M70PFHMH9ADY0CRE6047Y4B2","kitty-show-image","Show the user an image with a note on what to judge, via a file send or a labelled kitty tab. Use when the user must see an image, or icat fails with no \u002Fdev\u002Ftty.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkitty-plugin\u002Fskills\u002Fkitty-show-image\u002FSKILL.md",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[103,104,105,106,107,108,109,110,111,112,113,23,39,114,115,116,117,118,22,30],"show","kitty show image","image","kitty","show image","ls","get","send","open","dev","use","file","text","with","xdg","via",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":42},"01M70PFEN18HKQ4RCQ1VPGMPTB","kitty-session-persistence","Snapshot and restore kitty terminal sessions on macOS. Use when surviving WindowServer hangs without losing tabs, configuring snapshots, or restoring after a force-reboot.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkitty-plugin\u002Fskills\u002Fkitty-session-persistence\u002FSKILL.md",[],[106,126,127,128,129,130,23,39,131,132,133,22,30,134,135,136,137,138,139,113],"kitty session persistence","session","persistence","false","snapshots","uname","reboot","terminal","write","edit","snapshot","macos","sessions","restore",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":42},"01M70PFC77XGXCVQ1543VGZHYR","kitty-remote-control","Safe kitty remote control from an agent — read panes with kitty @ ls\u002Fget-text, notify, and never mutate the live terminal unasked. Use when running inside kitty.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkitty-plugin\u002Fskills\u002Fkitty-remote-control\u002FSKILL.md",[],[147,148,106,149,150,108,151,152,109,153,154,113,23,155,39,115,116,133,22,30],"kitty remote control","remote","control","remote control","running","never","panes","notify","query",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":42},"01M70P6WVMCT5JG4SACTM69AF9","docs-reference-check","Dangling doc-reference gate: flag markdown naming repo paths or relative links that no longer exist. Use when docs cite moved\u002Fdeleted files, or wiring a doc-drift lint.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fdocumentation-plugin\u002Fskills\u002Fdocs-reference-check\u002FSKILL.md",[],[163,164,165,166,167,168,169,170,35,171,113,23,39,172,114,173,174,175,176,177],"docs reference check","check","reference check","reference","docs","links","python3","repo","auto","drift","lint","wiring","chezmoi","references","cp",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":193,"publishedAt":42},"01M6C6NDE7DAQGNWSF22J5CJ0Z","youtube-upload","Upload a video to YouTube via the Data API v3 and edit its title, description, tags or thumbnail afterwards. Use when publishing or retitling a YouTube video.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fyoutube-plugin\u002Fskills\u002Fyoutube-upload\u002FSKILL.md",[184,187,188],{"categoryNo":185,"categoryName":186,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},{"categoryNo":189,"categoryName":190,"taxonomyType":191,"taxonomyTypeDesc":192},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[194,195,196,197,169,32,30,198,135,199,200,34,113,39,114,201,202,23,203,204,205,118,22],"youtube upload","upload","youtube","Video","uv run","publishing","data","api","v3","tags","id","title",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":215,"publishedAt":42},"01M6C6NABWW1X58KJJM4F6GQMQ","youtube-studio-share","Share a private YouTube video with a whole Google Workspace organization by scripting YouTube Studio in the browser. Use when a video must be org-only.","https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fyoutube-plugin\u002Fskills\u002Fyoutube-studio-share\u002FSKILL.md",[212],{"categoryNo":213,"categoryName":214,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000023","Skill与智能体开发",[216,217,218,219,196,197,220,221,222,223,224,30,225,226,227,228,113,229,23,116,230,22],"youtube studio share","share","youtube studio","studio","browser","javascript","scripting","google workspace","workspace","tool","google","only","MCP","chrome","organization"]