[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72WP6NHJ5VGJS2XTQE3ZJYN":3,"skill-same:01M72WP6NHJ5VGJS2XTQE3ZJYN":204},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":40,"ownerHtmlUrl":41,"ownerBlogUrl":40,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M72WP6NHJ5VGJS2XTQE3ZJYN","pr-reviewer",null,"Audits a pull request cold, without authoring context, for correctness, convention compliance, test coverage and linter findings, then posts a structured verdict (Approve, Request Changes or Comment) with the CI status, a seat line and class-tagged findings. Use when asked to review, audit or approve a pull request or a spec pull request, to give a second opinion on a change, to run a REVIEW pass or to post a verdict. Trigger terms: review PR, code review, audit pull request, verdict, request changes, approve, seat, cold review. Not for writing a pull-request body or logbook entry (pr-logbook), reviewing uncommitted local changes, composing a local commit message or writing a spec (spec-author).","crewrig\u002Fcrewrig","crewrig","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F283580446?v=4","01M72WDBD9H0YW5JBHNZ0TEVWB","01M72WDBEBNRBAS94AXRPEVYNK",24,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: pr-reviewer\ndescription: \"Audits a pull request cold, without authoring context, for correctness, convention compliance, test coverage and linter findings, then posts a structured verdict (Approve, Request Changes or Comment) with the CI status, a seat line and class-tagged findings. Use when asked to review, audit or approve a pull request or a spec pull request, to give a second opinion on a change, to run a REVIEW pass or to post a verdict. Trigger terms: review PR, code review, audit pull request, verdict, request changes, approve, seat, cold review. Not for writing a pull-request body or logbook entry (pr-logbook), reviewing uncommitted local changes, composing a local commit message or writing a spec (spec-author).\"\ntype: skill\nlicense: Apache-2.0\ncompatibility: \"Requires Node >= 24 (the scripts are TypeScript files run with node), git and the gh CLI (diff fetch, check status, verdict post). Optional: markdownlint (lint-markdown.ts), ruff or flake8 (lint-python.ts), oxlint and oxfmt (lint-typescript.ts). A missing optional tool degrades to a note, never aborts the review.\"\nmetadata:\n  provenance:\n    canonical: \"${CANONICAL_REPO}\"\n    feedback: \"${CANONICAL_REPO}\"\n    version: \"2.3.2\"\nclaude:\n  allowed-tools:\n    - Read\n    - Bash\n    - Grep\n    - Glob\n---\n\n# PR Reviewer\n\nAudit a pull request as an independent reader: no authoring context, no shared assumptions, no manufactured objections. A review that approves everything is worthless, and one that invents objections wastes the author's time, so every finding names a file, a line and a reason, and a solid change is approved plainly.\n\nYou have no stake in the change. Read the diff as if you had never seen it. Be skeptical but fair: say what is wrong, where and why, or say it is sound.\n\n## How the scripts report\n\nEvery script under `scripts\u002F` runs as `node scripts\u002F\u003Cname>.ts`, resolved against this skill's directory. Each answers `--help`, prints one `{ok, data, findings}` object with `--json` (human text then goes to stderr), and exits `0` ok, `1` findings, `2` usage error, `3` the environment or an input is unusable. Read the exit code first: `3` never means the change is bad.\n\n## Protocol\n\nSix steps, in order. Skipping ahead is how a review ends up approving a change whose CI is red.\n\n### 1. Preflight: CI status and iteration label\n\nRun `node scripts\u002Fci-preflight.ts \u003Cpr> --json` (add `--required` when the repository distinguishes required checks).\n\n- Exit `0`: every check passes; continue.\n- Exit `1`: read `data.verdict_ceiling`. A failing check caps the verdict at `REQUEST_CHANGES` (or `COMMENT` when the failure is clearly an infrastructure flake, said explicitly with the job name). A pending check caps it at `COMMENT` with the verdict stated as deferred until CI resolves.\n- Exit `3`: gh is unusable; say so in the verdict instead of guessing a status.\n\nTo wait for CI, make ONE call: `gh pr checks \u003Cpr> --watch` in the foreground, with the longest timeout the tool allows (a background task does not wake every session). Never wait with a `sleep`, an `until` loop, a monitor or repeated queries, since each re-reads a large context. Never end your turn to wait; nothing wakes a session that did. If CI is still pending at the timeout, post the verdict capped at `COMMENT` with the CI status; do not wait again.\n\nWhen that command exits, make one direct `ci-preflight.ts` query before composing the verdict, since the watch only observes the checks from outside.\n\nA `cancelled` check with no newer push is a failure until proven otherwise: `cancel-on-failure` cancels the run when any job fails. Read the `failure` annotations (`gh api repos\u002F\u003Co>\u002F\u003Cr>\u002Fcheck-runs\u002F\u003Cid>\u002Fannotations`) or the run summary, and name the failing job in the verdict (`docs\u002Frunbooks\u002Fci-cancelled-run-diagnosis.md`).\n\nGhost check: a check still pending although its workflow run is `completed\u002Fsuccess` counts as resolved when the merge state is `CLEAN`. `ci-preflight.ts` reports it apart, as bucket `ghost` and in `data.ghosts`, and does not count it as pending. Name it in the verdict's CI section; do not defer the verdict because of it.\n\nThe CI status goes into the verdict in writing (pass, fail or pending, with the failing job). On a later pass of the same seat the reading of the diff narrows (step 3), but this step never does: the head's CI state is part of every pass.\n\nThen run `node scripts\u002Fiter-label.ts \u003Cpr> --json`. Finding identifiers on the `review` surface are minted from the `iter:\u003CN>` label (see *Finding tags*), so the label must exist before the first identifier. Exit `0` gives `data.iter` (and adds `iter:1` itself when none existed). Exit `3` means the label could not be added: state that in the verdict's CI section and mint no identifier under an assumed number.\n\n### 2. Read the project conventions\n\nRead `references\u002Fstep-2-conventions.md`.\n\n### 3. Fetch the diff and the metadata\n\nRead `references\u002Fstep-3-fetch.md`. A seated pass is bounded from its second pass onward; `references\u002Fseat-obligations.md` holds the seat line, the dossier and the vacancy rules.\n\n### 4. Run the linters\n\nRead `references\u002Fstep-4-linters.md`.\n\n### 5. Compose the verdict\n\nRead `references\u002Fstep-5-compose.md` (the seat line's placement per transport is in `references\u002Fseat-obligations.md`), then check the body with `node scripts\u002Flint-verdict.ts --surface \u003Creview|specs|plan> --transport \u003Creview|comment> --ordinal \u003CN> [--prior-ids \u003Cids>] \u003Cfile>`. Exit `1` lists malformed tags, identifiers or a misplaced seat line: fix them before posting, because a finding without its tag is returned to the reviewer and costs the author a round trip.\n\n### 6. Post the review\n\nRun `node scripts\u002Fpost-verdict.ts \u003Cpr> --event \u003Capprove|request-changes|comment> --body-file \u003Cfile> --dry-run` first, then without `--dry-run`. The script chooses the transport from the posting identity: a formal review when the authenticated login differs from the author, a plain `## Verdict: …` comment when they are the same (GitHub refuses a self-approval), and it refuses a body over 12 KB. Exit `3` with `data.rung` `denied` means the forge refused the post: return the full verdict to the orchestrator and stop. Asking another agent to post it would launder a permission this session was denied.\n\nBefore posting, read `references\u002Fassert-fresh-observation.md`: observe the artifact you quote immediately before the post.\n\n## Blocking and non-blocking\n\nMark every finding blocking or non-blocking. Approve when nothing blocks: the loop ends on a pass with no blocking finding, and non-blocking findings go to the deferred-findings ledger or a follow-up issue, never to another pass. Passes are capped at 2 at `trivial`\u002F`small` and 3 at `standard`; a fix pass reads only the change since the last examined revision.\n\n## Finding tags\n\nEvery finding, blocking or not, carries exactly one `class:` line whose value is `tech`, `arch` or `spec`; read `references\u002Fshared-finding-class-taxonomy.md` for what each class routes to. Tag each finding individually: a heading above several findings does not tag them. Non-blocking findings need the tag too, because autonomous modes route them through the same matrix as blocking ones.\n\nEach finding also carries an identifier naming the pass that raised it, stable for the life of the seat: `i\u003CN>-F\u003CM>` on the `review` surface, where `\u003CN>` is the `iter:\u003CN>` ordinal from step 1; `s\u003CN>-F\u003CM>` on the `specs` surface, where `\u003CN>` is the seat's pass ordinal counted across every artifact of that surface; `v\u003CN>-F\u003CM>` on the `plan` surface. A lowercase suffix marks a sub-finding (`v1-F2a`). The next pass's prior-finding audit enumerates these identifiers.\n\nA finding on a surface the change did not touch is allowed, but it must say which condition of the step-3 bound returned that surface to scope. Without that statement it is non-blocking and goes to the deferred-findings ledger instead of routing the iteration.\n\n## Linters\n\n`scripts\u002Flint-markdown.ts` (markdownlint), `scripts\u002Flint-skill.ts` (SKILL.md frontmatter keys, version bump against `BASE_REF`, script citations; parsed with `js-yaml` when resolvable, a line scan otherwise), `scripts\u002Flint-python.ts` (ruff or flake8, bare `print(`), `scripts\u002Flint-json.ts` (`JSON.parse` and a trailing-comma heuristic) and `scripts\u002Flint-typescript.ts` (Oxlint type-aware, Oxfmt). Run them as `node scripts\u002Flint-markdown.ts \u003Cfile>...` on the matching changed files. A missing optional tool prints a note and exits `0`; `--require-tools` turns that into exit `3`. An unreadable input exits `3` before anything is linted.\n\n## Folded-bugs check\n\nOn a bug-type issue (`docs\u002Flogbook-issues.md`, Rule D), check that a `tech` finding describing a foldable bug cross-references its folded item and the reverse; that the PR body carries a `Folded bugs` entry; that each resolved item has a regression test or a written justification; and that the item-count and added-line caps and the fold tests are respected. A bug folded despite failing a fold test is a `class: tech` finding.\n\n## Spec-review obligation — tier challenge\n\nWhen reviewing a spec pull request, read `references\u002Fspec-review-obligation.md`.\n\n## Grounding\n\nRead `references\u002Fshared-grounding-discipline.md`. One rule is specific to review: verify cross-references, line numbers and any claim about the surroundings of a modified file against the file at the PR's head ref, not the local working tree, which may be behind the base and anchor a confidently wrong blocking finding:\n\n```bash\ngh api \"repos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fcontents\u002F\u003Cpath>?ref=\u003CheadRef>\" --header \"Accept: application\u002Fvnd.github.raw\"\n```\n\n`gh pr diff` alone is insufficient: it shows added lines, not the rule numbering they point to.\n\n## Output hygiene\n\nEvery tool result stays in context and is re-read on each later call.\n\n- Query `gh` with `--json` and `--jq` fields, never the full payload.\n- `tail` or `grep` logs down to the failing lines.\n- Read files by line range, never a whole spec.\n- Run `git diff --stat` before reading hunks.\n\n## Friction\n\nRead `references\u002Fshared-friction-reporting.md`; invoke the `harness-report` skill at the end of the review when a signal fired.\n","# PR Reviewer\n\nAudit a pull request as an independent reader: no authoring context, no shared assumptions, no manufactured objections. A review that approves everything is worthless, and one that invents objections wastes the author's time, so every finding names a file, a line and a reason, and a solid change is approved plainly.\n\nYou have no stake in the change. Read the diff as if you had never seen it. Be skeptical but fair: say what is wrong, where and why, or say it is sound.\n\n## How the scripts report\n\nEvery script under `scripts\u002F` runs as `node scripts\u002F\u003Cname>.ts`, resolved against this skill's directory. Each answers `--help`, prints one `{ok, data, findings}` object with `--json` (human text then goes to stderr), and exits `0` ok, `1` findings, `2` usage error, `3` the environment or an input is unusable. Read the exit code first: `3` never means the change is bad.\n\n## Protocol\n\nSix steps, in order. Skipping ahead is how a review ends up approving a change whose CI is red.\n\n### 1. Preflight: CI status and iteration label\n\nRun `node scripts\u002Fci-preflight.ts \u003Cpr> --json` (add `--required` when the repository distinguishes required checks).\n\n- Exit `0`: every check passes; continue.\n- Exit `1`: read `data.verdict_ceiling`. A failing check caps the verdict at `REQUEST_CHANGES` (or `COMMENT` when the failure is clearly an infrastructure flake, said explicitly with the job name). A pending check caps it at `COMMENT` with the verdict stated as deferred until CI resolves.\n- Exit `3`: gh is unusable; say so in the verdict instead of guessing a status.\n\nTo wait for CI, make ONE call: `gh pr checks \u003Cpr> --watch` in the foreground, with the longest timeout the tool allows (a background task does not wake every session). Never wait with a `sleep`, an `until` loop, a monitor or repeated queries, since each re-reads a large context. Never end your turn to wait; nothing wakes a session that did. If CI is still pending at the timeout, post the verdict capped at `COMMENT` with the CI status; do not wait again.\n\nWhen that command exits, make one direct `ci-preflight.ts` query before composing the verdict, since the watch only observes the checks from outside.\n\nA `cancelled` check with no newer push is a failure until proven otherwise: `cancel-on-failure` cancels the run when any job fails. Read the `failure` annotations (`gh api repos\u002F\u003Co>\u002F\u003Cr>\u002Fcheck-runs\u002F\u003Cid>\u002Fannotations`) or the run summary, and name the failing job in the verdict (`docs\u002Frunbooks\u002Fci-cancelled-run-diagnosis.md`).\n\nGhost check: a check still pending although its workflow run is `completed\u002Fsuccess` counts as resolved when the merge state is `CLEAN`. `ci-preflight.ts` reports it apart, as bucket `ghost` and in `data.ghosts`, and does not count it as pending. Name it in the verdict's CI section; do not defer the verdict because of it.\n\nThe CI status goes into the verdict in writing (pass, fail or pending, with the failing job). On a later pass of the same seat the reading of the diff narrows (step 3), but this step never does: the head's CI state is part of every pass.\n\nThen run `node scripts\u002Fiter-label.ts \u003Cpr> --json`. Finding identifiers on the `review` surface are minted from the `iter:\u003CN>` label (see *Finding tags*), so the label must exist before the first identifier. Exit `0` gives `data.iter` (and adds `iter:1` itself when none existed). Exit `3` means the label could not be added: state that in the verdict's CI section and mint no identifier under an assumed number.\n\n### 2. Read the project conventions\n\nRead `references\u002Fstep-2-conventions.md`.\n\n### 3. Fetch the diff and the metadata\n\nRead `references\u002Fstep-3-fetch.md`. A seated pass is bounded from its second pass onward; `references\u002Fseat-obligations.md` holds the seat line, the dossier and the vacancy rules.\n\n### 4. Run the linters\n\nRead `references\u002Fstep-4-linters.md`.\n\n### 5. Compose the verdict\n\nRead `references\u002Fstep-5-compose.md` (the seat line's placement per transport is in `references\u002Fseat-obligations.md`), then check the body with `node scripts\u002Flint-verdict.ts --surface \u003Creview|specs|plan> --transport \u003Creview|comment> --ordinal \u003CN> [--prior-ids \u003Cids>] \u003Cfile>`. Exit `1` lists malformed tags, identifiers or a misplaced seat line: fix them before posting, because a finding without its tag is returned to the reviewer and costs the author a round trip.\n\n### 6. Post the review\n\nRun `node scripts\u002Fpost-verdict.ts \u003Cpr> --event \u003Capprove|request-changes|comment> --body-file \u003Cfile> --dry-run` first, then without `--dry-run`. The script chooses the transport from the posting identity: a formal review when the authenticated login differs from the author, a plain `## Verdict: …` comment when they are the same (GitHub refuses a self-approval), and it refuses a body over 12 KB. Exit `3` with `data.rung` `denied` means the forge refused the post: return the full verdict to the orchestrator and stop. Asking another agent to post it would launder a permission this session was denied.\n\nBefore posting, read `references\u002Fassert-fresh-observation.md`: observe the artifact you quote immediately before the post.\n\n## Blocking and non-blocking\n\nMark every finding blocking or non-blocking. Approve when nothing blocks: the loop ends on a pass with no blocking finding, and non-blocking findings go to the deferred-findings ledger or a follow-up issue, never to another pass. Passes are capped at 2 at `trivial`\u002F`small` and 3 at `standard`; a fix pass reads only the change since the last examined revision.\n\n## Finding tags\n\nEvery finding, blocking or not, carries exactly one `class:` line whose value is `tech`, `arch` or `spec`; read `references\u002Fshared-finding-class-taxonomy.md` for what each class routes to. Tag each finding individually: a heading above several findings does not tag them. Non-blocking findings need the tag too, because autonomous modes route them through the same matrix as blocking ones.\n\nEach finding also carries an identifier naming the pass that raised it, stable for the life of the seat: `i\u003CN>-F\u003CM>` on the `review` surface, where `\u003CN>` is the `iter:\u003CN>` ordinal from step 1; `s\u003CN>-F\u003CM>` on the `specs` surface, where `\u003CN>` is the seat's pass ordinal counted across every artifact of that surface; `v\u003CN>-F\u003CM>` on the `plan` surface. A lowercase suffix marks a sub-finding (`v1-F2a`). The next pass's prior-finding audit enumerates these identifiers.\n\nA finding on a surface the change did not touch is allowed, but it must say which condition of the step-3 bound returned that surface to scope. Without that statement it is non-blocking and goes to the deferred-findings ledger instead of routing the iteration.\n\n## Linters\n\n`scripts\u002Flint-markdown.ts` (markdownlint), `scripts\u002Flint-skill.ts` (SKILL.md frontmatter keys, version bump against `BASE_REF`, script citations; parsed with `js-yaml` when resolvable, a line scan otherwise), `scripts\u002Flint-python.ts` (ruff or flake8, bare `print(`), `scripts\u002Flint-json.ts` (`JSON.parse` and a trailing-comma heuristic) and `scripts\u002Flint-typescript.ts` (Oxlint type-aware, Oxfmt). Run them as `node scripts\u002Flint-markdown.ts \u003Cfile>...` on the matching changed files. A missing optional tool prints a note and exits `0`; `--require-tools` turns that into exit `3`. An unreadable input exits `3` before anything is linted.\n\n## Folded-bugs check\n\nOn a bug-type issue (`docs\u002Flogbook-issues.md`, Rule D), check that a `tech` finding describing a foldable bug cross-references its folded item and the reverse; that the PR body carries a `Folded bugs` entry; that each resolved item has a regression test or a written justification; and that the item-count and added-line caps and the fold tests are respected. A bug folded despite failing a fold test is a `class: tech` finding.\n\n## Spec-review obligation — tier challenge\n\nWhen reviewing a spec pull request, read `references\u002Fspec-review-obligation.md`.\n\n## Grounding\n\nRead `references\u002Fshared-grounding-discipline.md`. One rule is specific to review: verify cross-references, line numbers and any claim about the surroundings of a modified file against the file at the PR's head ref, not the local working tree, which may be behind the base and anchor a confidently wrong blocking finding:\n\n```bash\ngh api \"repos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fcontents\u002F\u003Cpath>?ref=\u003CheadRef>\" --header \"Accept: application\u002Fvnd.github.raw\"\n```\n\n`gh pr diff` alone is insufficient: it shows added lines, not the rule numbering they point to.\n\n## Output hygiene\n\nEvery tool result stays in context and is re-read on each later call.\n\n- Query `gh` with `--json` and `--jq` fields, never the full payload.\n- `tail` or `grep` logs down to the failing lines.\n- Read files by line range, never a whole spec.\n- Run `git diff --stat` before reading hunks.\n\n## Friction\n\nRead `references\u002Fshared-friction-reporting.md`; invoke the `harness-report` skill at the end of the review when a signal fired.\n",{"name":5,"type":23,"claude":24,"license":14,"metadata":30,"description":7,"compatibility":34},"skill",{"allowed-tools":25},[26,27,28,29],"Read","Bash","Grep","Glob",{"provenance":31},{"version":32,"feedback":33,"canonical":33},"2.3.2","${CANONICAL_REPO}","Requires Node >= 24 (the scripts are TypeScript files run with node), git and the gh CLI (diff fetch, check status, verdict post). Optional: markdownlint (lint-markdown.ts), ruff or flake8 (lint-python.ts), oxlint and oxfmt (lint-typescript.ts). A missing optional tool degrades to a note, never aborts the review.","main","6d7f2262eb86a02d21a60a8147ed6f8a27d7b8eb","artifacts\u002Fcore\u002Fskills\u002Fpr-reviewer",6,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig","https:\u002F\u002Fcrewrig.org","https:\u002F\u002Fgithub.com\u002Fcrewrig","This is the organisation behind the crewrig framework","2026-11-15 04:46:08",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add crewrig\u002Fcrewrig --skill pr-reviewer",{"tool":50,"command":51},"bunx","bunx skills add crewrig\u002Fcrewrig --skill pr-reviewer",{"tool":53,"command":54},"pnpm","pnpm dlx skills add crewrig\u002Fcrewrig --skill pr-reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002FSKILL.md",true,[58,64,70,74,78,82,86,89,93,97,101,105,109,112,116,119,123,127,130,134,138,142,146,150,154,158,162,168,172,176,180,184,188,192,196,200],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"evals\u002Fevals.json","REFERENCE","参考文档",14509,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Fevals.json",{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"evals\u002Ffiles\u002Fchange-clean.diff","OTHER","其他",1078,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fchange-clean.diff",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"evals\u002Ffiles\u002Fchange-defect.diff",1101,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fchange-defect.diff",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"evals\u002Ffiles\u002Fchange-docs.diff",239,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fchange-docs.diff",{"path":79,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Ffiles\u002Fchange-v2.diff",291,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fchange-v2.diff",{"path":83,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Ffiles\u002Fchecks-fail.json",72,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fchecks-fail.json",{"path":87,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":84,"sourceHtmlUrl":88},"evals\u002Ffiles\u002Fchecks-pass.json","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fchecks-pass.json",{"path":90,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":91,"sourceHtmlUrl":92},"evals\u002Ffiles\u002Fconventions.md",846,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fconventions.md",{"path":94,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":95,"sourceHtmlUrl":96},"evals\u002Ffiles\u002Fdisposition.md",255,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fdisposition.md",{"path":98,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":99,"sourceHtmlUrl":100},"evals\u002Ffiles\u002Fhead-rules.md",364,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fhead-rules.md",{"path":102,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":103,"sourceHtmlUrl":104},"evals\u002Ffiles\u002Flocal-rules.md",237,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Flocal-rules.md",{"path":106,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":107,"sourceHtmlUrl":108},"evals\u002Ffiles\u002Fpr-clean.json",460,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fpr-clean.json",{"path":110,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":107,"sourceHtmlUrl":111},"evals\u002Ffiles\u002Fpr-defect.json","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fpr-defect.json",{"path":113,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":114,"sourceHtmlUrl":115},"evals\u002Ffiles\u002Fpr-docs.json",388,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fpr-docs.json",{"path":117,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":107,"sourceHtmlUrl":118},"evals\u002Ffiles\u002Fpr-v2.json","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fpr-v2.json",{"path":120,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":121,"sourceHtmlUrl":122},"evals\u002Ffiles\u002Fprior-verdict.md",483,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fprior-verdict.md",{"path":124,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":125,"sourceHtmlUrl":126},"evals\u002Ffiles\u002Fwhoami-distinct.txt",13,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fwhoami-distinct.txt",{"path":128,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":38,"sourceHtmlUrl":129},"evals\u002Ffiles\u002Fwhoami-same.txt","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Ffiles\u002Fwhoami-same.txt",{"path":131,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":132,"sourceHtmlUrl":133},"evals\u002Fresults.json",672,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fevals\u002Fresults.json",{"path":135,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":136,"sourceHtmlUrl":137},"references\u002Fassert-fresh-observation.md",967,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fassert-fresh-observation.md",{"path":139,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":140,"sourceHtmlUrl":141},"references\u002Fseat-obligations.md",2448,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fseat-obligations.md",{"path":143,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":144,"sourceHtmlUrl":145},"references\u002Fspec-review-obligation.md",990,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fspec-review-obligation.md",{"path":147,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":148,"sourceHtmlUrl":149},"references\u002Fstep-2-conventions.md",449,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fstep-2-conventions.md",{"path":151,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":152,"sourceHtmlUrl":153},"references\u002Fstep-3-fetch.md",1533,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fstep-3-fetch.md",{"path":155,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":156,"sourceHtmlUrl":157},"references\u002Fstep-4-linters.md",1159,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fstep-4-linters.md",{"path":159,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":160,"sourceHtmlUrl":161},"references\u002Fstep-5-compose.md",2008,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Freferences\u002Fstep-5-compose.md",{"path":163,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":166,"sourceHtmlUrl":167},"scripts\u002Fcheck-comment-size.ts","SCRIPT","脚本",4239,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Fcheck-comment-size.ts",{"path":169,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":170,"sourceHtmlUrl":171},"scripts\u002Fci-preflight.ts",10732,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Fci-preflight.ts",{"path":173,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":174,"sourceHtmlUrl":175},"scripts\u002Fiter-label.ts",6600,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Fiter-label.ts",{"path":177,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":178,"sourceHtmlUrl":179},"scripts\u002Flint-json.ts",5166,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Flint-json.ts",{"path":181,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":182,"sourceHtmlUrl":183},"scripts\u002Flint-markdown.ts",6447,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Flint-markdown.ts",{"path":185,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":186,"sourceHtmlUrl":187},"scripts\u002Flint-python.ts",7321,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Flint-python.ts",{"path":189,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":190,"sourceHtmlUrl":191},"scripts\u002Flint-skill.ts",14595,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Flint-skill.ts",{"path":193,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":194,"sourceHtmlUrl":195},"scripts\u002Flint-typescript.ts",9720,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Flint-typescript.ts",{"path":197,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":198,"sourceHtmlUrl":199},"scripts\u002Flint-verdict.ts",11175,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Flint-verdict.ts",{"path":201,"resourceType":164,"resourceTypeDesc":165,"sizeBytes":202,"sourceHtmlUrl":203},"scripts\u002Fpost-verdict.ts",8511,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fartifacts\u002Fcore\u002Fskills\u002Fpr-reviewer\u002Fscripts\u002Fpost-verdict.ts",[205,213,218,223,228,233],{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":212},"01M76AJKRKGGYZFJJHKE32Q5ZZ","fixture","Fixture skill. Mentions scripts\u002Ffrontmatter-only.ts which must be ignored.","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Fyaml-example\u002FSKILL.md",[],[],"2026-11-12 13:55:43",{"skillNo":214,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":217,"publishedAt":212},"01M76AJJHS0AHW5HJJQCVVJ4DH","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Funterminated\u002FSKILL.md",[],[],{"skillNo":219,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":222,"publishedAt":212},"01M76AJH8VJ2NAE000285J1D8F","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Funresolved\u002FSKILL.md",[],[],{"skillNo":224,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":227,"publishedAt":212},"01M76AJG4M862QH00H5QVVT60P","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Fstray\u002FSKILL.md",[],[],{"skillNo":229,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":230,"categories":231,"keywords":232,"publishedAt":212},"01M76AJEZKZVMWZXCKXCFNQQ6B","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Fresolving\u002FSKILL.md",[],[],{"skillNo":234,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":235,"categories":236,"keywords":237,"publishedAt":212},"01M76AJD4G4K2YK2SMN8NSEG9R","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Freferences-unfenced\u002FSKILL.md",[],[]]