[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X6BXPE53QSF89NH327BBGD":3,"skill-same:01M6X6BXPE53QSF89NH327BBGD":124},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":64,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M6X6BXPE53QSF89NH327BBGD","code-review-lens",null,"Use when the user says \"review this\", \"check my code\", or wants feedback on changes. Reviews for correctness, quality, security, and coding standards.","event4u-app\u002Fagent-config","event4u-app","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199339632?v=4","01M6X5TWBNCQCE1VDKT4E9KF7N","event4u.app","01M6X5TWF4HRM266RG2Q5VVH1X",19,"MIT","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"review","code review lens","lens","code review","code","security","when","changes","for","high","my","correctness","reviews","files","standards","use","check","coding","feedback","coding standards","2026-11-10 10:12:30",false,"---\nmodel_tier: high\nname: code-review-lens\ndescription: \"Use when the user says \\\"review this\\\", \\\"check my code\\\", or wants feedback on changes. Reviews for correctness, quality, security, and coding standards.\"\ndomain: quality\nparallelizable: files\nworkspaces:\n  - engineering\npacks:\n  - engineering-base\n---\n\n# code-review-lens\n\n## When to use\n\nUse this skill when:\n- Reviewing a PR (own or someone else's)\n- Self-reviewing local changes before creating a PR\n- Responding to review feedback on your PR\n- The user asks to \"review\", \"check\", or \"look at\" code changes\n\n## Procedure: Review code\n\n### Mindset\n\n- **Be thorough but pragmatic** — catch real bugs, not style nitpicks that tools handle.\n- **Understand intent first** — read the PR description, linked ticket, and commit messages before looking at code.\n- **Check the full picture** — a change in a service may require changes in tests, migrations, docs.\n- **Assume good intent** — suggest improvements, don't criticize.\n\n### Review order\n\n1. **Understand the goal** — what is this change trying to achieve?\n2. **Detect the change-type + depth** — route to the right checklist and pick the review depth (below).\n3. **Architecture** — does the approach make sense? Right layer? Right pattern?\n4. **Correctness** — does it actually work? Edge cases? Error handling?\n5. **Quality** — types, naming, readability, SOLID?\n6. **Redundancy** — see below; a verdict, not a \"this looks duplicated\".\n7. **Propagation** — did a changed concept reach every occurrence? see below.\n8. **Security** — input validation, authorization, injection?\n9. **Performance** — N+1 queries, missing indexes, unbounded queries?\n10. **Tests** — are new paths covered? Are existing tests still valid?\n11. **Conventions** — does it follow project standards?\n\n## The redundancy dimension\n\n`DRY` as a checklist word produced findings nobody could act on: it names a\nprinciple, not a decision, and it has no answer for the case where two copies\nshould stay. Replace it with a verdict.\n\nClassify the finding against\n[`redundancy-taxonomy`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fredundancy-taxonomy.md) —\nimplementation, knowledge, or representation — and record one verdict from that\ndocument's list. `keep-duplicated` and `de-abstract` are successful outcomes; a\nfinding with no recorded verdict stays open. Knowledge, policy, contract and\ndelivery-authority duplication outrank clone percentage: two copies of a\n*decision* diverge into a bug, two copies of a loop usually do not.\n\n**Diff-aware, always.** The finding is duplication this change **introduces**,\nor duplication on a surface it touches. Pre-existing duplication is baseline —\nit is named once if the reviewer thinks it matters and it never fails an\nunrelated change. A review that reds a diff against debt it did not create is a\nreview nobody will run twice.\n\nFor comments, labels, tooltips, placeholders and empty states, run the\nInformation Delta Test from the same document rather than judging text volume.\nA reduction that removes an accessibility name is a defect, not a cleanup.\n\nNaming is the same dimension pointed the other way: a diff that introduces a\nsecond term for a concept the tree already names is the finding, and an existing\nsplit is baseline. The classes and the `canonicalize-term` \u002F `keep-distinct`\nverdicts are in the same document.\n\n## The propagation dimension\n\nA change is complete when the **concept** changed everywhere, not when the named\nfile compiles. Two shapes to check, both of which the file-level review misses:\n\n**A closed set gained or lost a member** (enum, union, literal type, state\nmachine, role or permission set, schema `enum`, DB check constraint). List the\nconsumers and their status — every `switch` \u002F `match` \u002F if-chain over the type,\nevery lookup table keyed by it, every validator, serializer, schema, fixture and\ntranslation key. A `default` branch that silently absorbs the new member is a\nmissing case, not a handled one. Procedure:\n[`downstream-changes-mechanics`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fdownstream-changes-mechanics.md).\n\n**A shared behaviour moved and its siblings did not.** A defect fixed in one\nplace is presumed to recur until searched: name the exact wrong construct, grep\nthe tree, and report the count — zero is a real answer and worth stating, because\nit distinguishes \"this was unique\" from \"nobody looked\".\n\nDiff-aware on the same terms as redundancy: the finding is a concept **this\nchange** left half-migrated. Pre-existing incompleteness elsewhere is baseline.\n\nWhen the diff **creates** a class, component, service or hook rather than\nchanging one, the question is whether it needed to exist: what was searched,\nwhat was found, and why composing or extending the incumbent was rejected. An\nanswer, not a ceremony — and the thresholds for when repetition actually earns\nan abstraction are in\n[`component-oriented-and-oop-development`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fcomponent-oriented-and-oop-development.md).\n\n## Change-type routing — load only the checklist the diff needs\n\nPer-domain checklists live in `checklists\u002F`, loaded **on demand** — a review\ncarries only the depth the change needs (progressive disclosure; a dependency\nbump does not pay for the backend security table). Detect the change-type from\nthe diff's file paths, then read the matching file:\n\n| Change-type | File-pattern signal (any match) | Checklist |\n|---|---|---|\n| **dependency** (expedited) | ONLY `composer.json`\u002F`*.lock`, `package.json`\u002Flockfiles, `pyproject.toml`, `go.mod`\u002F`go.sum`, `Cargo.toml`\u002F`*.lock` | [`checklists\u002Fdependency.md`](checklists\u002Fdependency.md) |\n| **migration \u002F database** | `**\u002Fmigrations\u002F**`, `**\u002F*migration*`, schema files, query-heavy data-access code | [`checklists\u002Fdatabase.md`](checklists\u002Fdatabase.md) |\n| **frontend \u002F UI** | `*.tsx`, `*.jsx`, `*.vue`, `*.blade.php`, `*.css`, `components\u002F**`, `resources\u002Fviews\u002F**` | [`checklists\u002Ffrontend.md`](checklists\u002Ffrontend.md) |\n| **infra \u002F IaC \u002F CI** | `*.tf`, `Dockerfile*`, `k8s\u002F**`, `*.yaml` under `.github\u002Fworkflows\u002F`, Pulumi\u002FAnsible | [`checklists\u002Finfra.md`](checklists\u002Finfra.md) |\n| **test-only** | ONLY `tests\u002F**`, `*.test.*`, `*.spec.*`, `*Test.php` | [`checklists\u002Ftest-only.md`](checklists\u002Ftest-only.md) |\n| **docs-only** | ONLY `*.md`, `docs\u002F**` | [`checklists\u002Fdocs.md`](checklists\u002Fdocs.md) |\n| **backend \u002F default** | anything else (server-side logic) | [`checklists\u002Fbackend.md`](checklists\u002Fbackend.md) |\n\nA diff spanning several types loads each matching checklist; a mixed diff is\nnever downgraded to the expedited path (a lockfile bump *plus* code is backend\n+ dependency). Every `checklists\u002F*.md` file MUST be reachable from a row above.\n\nFramework-specific conventions defer to the carve-outs: PHP \u002F Laravel →\n[`laravel`](..\u002Flaravel\u002FSKILL.md), [`laravel-validation`](..\u002Flaravel-validation\u002FSKILL.md),\n[`eloquent`](..\u002Feloquent\u002FSKILL.md), [`pest-testing`](..\u002Fpest-testing\u002FSKILL.md),\n[`blade-ui`](..\u002Fblade-ui\u002FSKILL.md), [`php-coder`](..\u002Fphp-coder\u002FSKILL.md);\nSymfony → [`symfony-workflow`](..\u002Fsymfony-workflow\u002FSKILL.md); Next.js \u002F TS →\n[`nextjs-patterns`](..\u002Fnextjs-patterns\u002FSKILL.md), [`react-shadcn-ui`](..\u002Freact-shadcn-ui\u002FSKILL.md).\n\n### Metadata gates — verdict `❓` until satisfied\n\nSome changes are unverifiable from source; when a gate fires the verdict is\n`❓`, not approval — ask for the missing evidence:\n\n- **UI diff without a screenshot \u002F visual check** → `❓` (rendered result unverifiable from source).\n- **New module \u002F feature without a test plan** → `❓` (behaviour coverage unconfirmable).\n- **Optional cross-cutting gate** (per-project): a new state-changing op without a telemetry OR authz touch → `❓`.\n\n### Adaptive review depth\n\nPick depth from diff size, override upward on risk:\n\n| Diff \u002F surface size | Depth | What it means |\n|---|---|---|\n| **SMALL** (single file \u002F few lines) | DEEP | Read every line; trace each branch. |\n| **MEDIUM** (a feature, several files) | FOCUSED | Deep on changed logic + its callers; skim the rest. |\n| **LARGE** (sweeping \u002F many files) | SURGICAL | Deep on the risk-bearing files; explicitly bound the rest as un-deep-reviewed. |\n\n**Risk triggers force HIGH depth regardless of diff size:** auth \u002F crypto,\nexternal calls \u002F SSRF, removal of a validation or authz check, money \u002F\ntenant-boundary code. [`blast-radius-analyzer`](..\u002Fblast-radius-analyzer\u002FSKILL.md)\nis one input to sizing; the depth policy + coverage-honesty line are this\nskill's addition. Every review ends with a **Coverage & confidence** line\n(deep-reviewed vs skimmed\u002Fbounded-out files + confidence) — silent partial\ncoverage reads as full coverage.\n\n## Re-review scoping + parallel-review de-biasing\n\n- **Re-review scoping** — on a follow-up push, scope to the **changed lines\n  only**; never flag new issues in untouched code (note pre-existing issues\n  separately, never in the blocking set). Same discipline `fix-pr-comments`\n  reply rounds apply.\n- **Ordering-bias** — when N reviewers\u002Flenses get the **same file set**\n  (`parallelizable: files`; council lenses), give each an independently\n  shuffled file order (deterministic seed per session, logged for replay) so\n  a fixed order does not correlate their blind spots. Single-reviewer → no shuffle.\n\n**MEASURED, and the result is a null — 2026-08-23.** This control is prose and nothing in\nthe package implements it. That is now true for a recorded reason rather than by\nomission: the pre-registered question — does rotating reviewer order change the finding set\non a frozen corpus, by more than 15 % — **cannot be answered from the corpus that exists**.\n`agents\u002Fevidence\u002Freviews\u002F` holds 123 findings artifacts, and none of them records the file\norder it was produced under, so the counterfactual is not recoverable; re-running reviewers\nproduces fresh judgements in which ordering is confounded with run-to-run variance. Full\nnull, with its reopening condition: `agents\u002Fevidence\u002Freview-rotation-prereg-and-null.md`.\nA reduced-power crossover was considered and refused — it would risk a false closure on a\ncontrol this paragraph still specifies.\n\n## Before creating a PR\n\n1. When `quality.local_auto_run: true`: run the project's quality pipeline (see the stack carve-out for the exact commands — PHP: `quality-tools`) and tests via the project's runner (`make test`, `npm test`, `pytest`, `go test .\u002F...`, or the project's wrapper script). Under the default (`false` \u002F missing): skip both — remote CI on the PR is the gate.\n2. Ensure CI passes on the branch (remote CI is authoritative).\n3. Self-review the diff: `git diff origin\u002Fmain..HEAD`.\n\n## Receiving feedback\n\n### The response pattern\n\nConstraint: **understand each comment fully before touching code, verify it against codebase reality, and implement one item at a time (test each).** Restate anything ambiguous in your own words — or ask. Push back with technical reasoning when a suggestion is unsound for *this* codebase rather than complying reflexively.\n\nIf **any item is unclear**, STOP — do not implement anything yet. Items may be related;\npartial understanding leads to wrong implementation.\n\n### No performative agreement\n\n- **Do NOT** reply with \"Great point!\", \"You're absolutely right!\", \"Excellent catch!\" or similar.\n- **Instead:** Just fix it. \"Fixed.\" or \"Updated — [brief description of what changed].\"\n- Actions speak louder than words — the code itself shows you heard the feedback.\n\n### Source-specific handling\n\n**Internal team feedback** (trusted colleagues):\n- Implement after understanding — no need for deep skepticism.\n- Still ask if scope is unclear.\n- Skip to action or technical acknowledgment.\n\n**External \u002F Copilot \u002F bot feedback** (less context):\n- Check: Technically correct for THIS codebase?\n- Check: Does it break existing functionality?\n- Check: Is there a reason for the current implementation?\n- Check: Does the reviewer understand the full context?\n- **YAGNI check:** If the reviewer suggests \"implementing properly\", grep the codebase\n  for actual usage. If unused → suggest removing (YAGNI).\n- If it conflicts with existing architectural decisions → discuss with the team first.\n\n### When to push back\n\nPush back when:\n- Suggestion breaks existing functionality.\n- Reviewer lacks full context.\n- Violates YAGNI (unused feature).\n- Technically incorrect for this stack.\n- Legacy\u002Fcompatibility reasons exist.\n- Conflicts with architectural decisions.\n\nHow: Use technical reasoning, not defensiveness. Reference working tests\u002Fcode.\n\n### Addressing PR comments systematically\n\nConstraint: **clarify anything unclear before implementing, fix one item at a time (test each), and reply in each review thread** — not as a top-level PR comment. Triage first (blocking → simple → complex) so blockers land first; `gh pr view --comments` lists the threads.\n\n```bash\n# Reply to a specific review comment thread\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  -f body=\"Fixed in latest commit.\"\n```\n\n## Rubric pass (optional, surfacing-only)\n\nAfter completing a review, run\n[`judge-artifact-completeness`](..\u002Fjudge-artifact-completeness\u002FSKILL.md)\nwith rubric `pr-review-score` to verify evidence-fit, risk\u002Fblast-radius\ncoverage, and migration\u002Frollback completeness. Invoke when the review is\nhigh-risk or the user asks for a completeness check — not by default.\n\n## Output format\n\nValidate, then emit these parts in order:\n\n1. **Reasoned validation first** — group candidates by file + line range,\n   disposition each CONFIRMED \u002F adjusted \u002F DROPPED with a one-line reason (not\n   vote-counting).\n2. **Tier 1 — Mechanical** — enumerated, fix-ready findings by severity blocks, never mixed.\n3. **Tier 2 — Alignment** — each flag names the principle\u002FADR at stake + the concern (from the governance-conflict scan); not fix-ready by construction.\n4. **Dropped false positives** — collapsible; each DROPPED candidate + reason. Empty is fine, but the section is mandatory (its presence proves validation ran).\n5. **Verdict line** — `YES` \u002F `NOT-SURE` (`❓`, a metadata gate fired or coverage bounded) \u002F `NO`, plus Tier-1 blocker\u002Fsuggestion counts.\n6. **Coverage & confidence line** — deep vs skimmed\u002Fbounded-out files + confidence.\n\nFull template, governance-conflict scan (status-aware over `docs\u002Fdecisions\u002F`,\nincl. draft ADRs; guarded `git blame` reviewer hint), and the security-class\ndeep-verify path → [`checklists\u002Fproducing-the-review.md`](checklists\u002Fproducing-the-review.md).\n\n> **Tally-vs-reasoned boundary.** Finding-level review uses reasoned validation\n> (each finding stands on its own traced reason); option-level decisions use\n> the council **stance tally** ([`ai-council`](..\u002Fai-council\u002FSKILL.md)). Never\n> cross-apply — no resolving a bug finding by counting votes, no resolving a\n> design option by reasoned-validating one take. Mirrored in `ai-council` so\n> the boundary is grep-checkable from both sides.\n\nGroup related findings; skip what the linter \u002F type-checker already catches.\n\n## Adversarial review\n\nBefore creating a PR or presenting code changes, run the **`adversarial-review`** skill.\nFocus on the \"Code changes \u002F Refactoring\" attack questions.\n\n## Auto-trigger keywords\n\n- code review\n- PR review\n- pull request\n- review checklist\n- review feedback\n- review changes\n- check my code\n\n## Gotcha\n\n- Don't rewrite code that works and is tested just because you'd write it differently.\n- The model tends to suggest changes that are out of scope — stay focused on the PR's intent.\n- \"I would prefer X\" is not a valid review comment unless X prevents a bug or violates a rule.\n- Always check if the PR has tests — missing tests is always worth flagging.\n\n## Do NOT\n\n- Do NOT approve without actually reading the code.\n- Do NOT agree with review comments without verifying them against the codebase.\n- Do NOT use performative language when responding to feedback (\"Great point!\", \"Excellent catch!\").\n- Do NOT nitpick style issues the project's formatter \u002F auto-refactor (ECS, Prettier, Ruff, gofmt) handles automatically.\n- Do NOT merge without CI passing and quality checks green.\n","# code-review-lens\n\n## When to use\n\nUse this skill when:\n- Reviewing a PR (own or someone else's)\n- Self-reviewing local changes before creating a PR\n- Responding to review feedback on your PR\n- The user asks to \"review\", \"check\", or \"look at\" code changes\n\n## Procedure: Review code\n\n### Mindset\n\n- **Be thorough but pragmatic** — catch real bugs, not style nitpicks that tools handle.\n- **Understand intent first** — read the PR description, linked ticket, and commit messages before looking at code.\n- **Check the full picture** — a change in a service may require changes in tests, migrations, docs.\n- **Assume good intent** — suggest improvements, don't criticize.\n\n### Review order\n\n1. **Understand the goal** — what is this change trying to achieve?\n2. **Detect the change-type + depth** — route to the right checklist and pick the review depth (below).\n3. **Architecture** — does the approach make sense? Right layer? Right pattern?\n4. **Correctness** — does it actually work? Edge cases? Error handling?\n5. **Quality** — types, naming, readability, SOLID?\n6. **Redundancy** — see below; a verdict, not a \"this looks duplicated\".\n7. **Propagation** — did a changed concept reach every occurrence? see below.\n8. **Security** — input validation, authorization, injection?\n9. **Performance** — N+1 queries, missing indexes, unbounded queries?\n10. **Tests** — are new paths covered? Are existing tests still valid?\n11. **Conventions** — does it follow project standards?\n\n## The redundancy dimension\n\n`DRY` as a checklist word produced findings nobody could act on: it names a\nprinciple, not a decision, and it has no answer for the case where two copies\nshould stay. Replace it with a verdict.\n\nClassify the finding against\n[`redundancy-taxonomy`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fredundancy-taxonomy.md) —\nimplementation, knowledge, or representation — and record one verdict from that\ndocument's list. `keep-duplicated` and `de-abstract` are successful outcomes; a\nfinding with no recorded verdict stays open. Knowledge, policy, contract and\ndelivery-authority duplication outrank clone percentage: two copies of a\n*decision* diverge into a bug, two copies of a loop usually do not.\n\n**Diff-aware, always.** The finding is duplication this change **introduces**,\nor duplication on a surface it touches. Pre-existing duplication is baseline —\nit is named once if the reviewer thinks it matters and it never fails an\nunrelated change. A review that reds a diff against debt it did not create is a\nreview nobody will run twice.\n\nFor comments, labels, tooltips, placeholders and empty states, run the\nInformation Delta Test from the same document rather than judging text volume.\nA reduction that removes an accessibility name is a defect, not a cleanup.\n\nNaming is the same dimension pointed the other way: a diff that introduces a\nsecond term for a concept the tree already names is the finding, and an existing\nsplit is baseline. The classes and the `canonicalize-term` \u002F `keep-distinct`\nverdicts are in the same document.\n\n## The propagation dimension\n\nA change is complete when the **concept** changed everywhere, not when the named\nfile compiles. Two shapes to check, both of which the file-level review misses:\n\n**A closed set gained or lost a member** (enum, union, literal type, state\nmachine, role or permission set, schema `enum`, DB check constraint). List the\nconsumers and their status — every `switch` \u002F `match` \u002F if-chain over the type,\nevery lookup table keyed by it, every validator, serializer, schema, fixture and\ntranslation key. A `default` branch that silently absorbs the new member is a\nmissing case, not a handled one. Procedure:\n[`downstream-changes-mechanics`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fdownstream-changes-mechanics.md).\n\n**A shared behaviour moved and its siblings did not.** A defect fixed in one\nplace is presumed to recur until searched: name the exact wrong construct, grep\nthe tree, and report the count — zero is a real answer and worth stating, because\nit distinguishes \"this was unique\" from \"nobody looked\".\n\nDiff-aware on the same terms as redundancy: the finding is a concept **this\nchange** left half-migrated. Pre-existing incompleteness elsewhere is baseline.\n\nWhen the diff **creates** a class, component, service or hook rather than\nchanging one, the question is whether it needed to exist: what was searched,\nwhat was found, and why composing or extending the incumbent was rejected. An\nanswer, not a ceremony — and the thresholds for when repetition actually earns\nan abstraction are in\n[`component-oriented-and-oop-development`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fcomponent-oriented-and-oop-development.md).\n\n## Change-type routing — load only the checklist the diff needs\n\nPer-domain checklists live in `checklists\u002F`, loaded **on demand** — a review\ncarries only the depth the change needs (progressive disclosure; a dependency\nbump does not pay for the backend security table). Detect the change-type from\nthe diff's file paths, then read the matching file:\n\n| Change-type | File-pattern signal (any match) | Checklist |\n|---|---|---|\n| **dependency** (expedited) | ONLY `composer.json`\u002F`*.lock`, `package.json`\u002Flockfiles, `pyproject.toml`, `go.mod`\u002F`go.sum`, `Cargo.toml`\u002F`*.lock` | [`checklists\u002Fdependency.md`](checklists\u002Fdependency.md) |\n| **migration \u002F database** | `**\u002Fmigrations\u002F**`, `**\u002F*migration*`, schema files, query-heavy data-access code | [`checklists\u002Fdatabase.md`](checklists\u002Fdatabase.md) |\n| **frontend \u002F UI** | `*.tsx`, `*.jsx`, `*.vue`, `*.blade.php`, `*.css`, `components\u002F**`, `resources\u002Fviews\u002F**` | [`checklists\u002Ffrontend.md`](checklists\u002Ffrontend.md) |\n| **infra \u002F IaC \u002F CI** | `*.tf`, `Dockerfile*`, `k8s\u002F**`, `*.yaml` under `.github\u002Fworkflows\u002F`, Pulumi\u002FAnsible | [`checklists\u002Finfra.md`](checklists\u002Finfra.md) |\n| **test-only** | ONLY `tests\u002F**`, `*.test.*`, `*.spec.*`, `*Test.php` | [`checklists\u002Ftest-only.md`](checklists\u002Ftest-only.md) |\n| **docs-only** | ONLY `*.md`, `docs\u002F**` | [`checklists\u002Fdocs.md`](checklists\u002Fdocs.md) |\n| **backend \u002F default** | anything else (server-side logic) | [`checklists\u002Fbackend.md`](checklists\u002Fbackend.md) |\n\nA diff spanning several types loads each matching checklist; a mixed diff is\nnever downgraded to the expedited path (a lockfile bump *plus* code is backend\n+ dependency). Every `checklists\u002F*.md` file MUST be reachable from a row above.\n\nFramework-specific conventions defer to the carve-outs: PHP \u002F Laravel →\n[`laravel`](..\u002Flaravel\u002FSKILL.md), [`laravel-validation`](..\u002Flaravel-validation\u002FSKILL.md),\n[`eloquent`](..\u002Feloquent\u002FSKILL.md), [`pest-testing`](..\u002Fpest-testing\u002FSKILL.md),\n[`blade-ui`](..\u002Fblade-ui\u002FSKILL.md), [`php-coder`](..\u002Fphp-coder\u002FSKILL.md);\nSymfony → [`symfony-workflow`](..\u002Fsymfony-workflow\u002FSKILL.md); Next.js \u002F TS →\n[`nextjs-patterns`](..\u002Fnextjs-patterns\u002FSKILL.md), [`react-shadcn-ui`](..\u002Freact-shadcn-ui\u002FSKILL.md).\n\n### Metadata gates — verdict `❓` until satisfied\n\nSome changes are unverifiable from source; when a gate fires the verdict is\n`❓`, not approval — ask for the missing evidence:\n\n- **UI diff without a screenshot \u002F visual check** → `❓` (rendered result unverifiable from source).\n- **New module \u002F feature without a test plan** → `❓` (behaviour coverage unconfirmable).\n- **Optional cross-cutting gate** (per-project): a new state-changing op without a telemetry OR authz touch → `❓`.\n\n### Adaptive review depth\n\nPick depth from diff size, override upward on risk:\n\n| Diff \u002F surface size | Depth | What it means |\n|---|---|---|\n| **SMALL** (single file \u002F few lines) | DEEP | Read every line; trace each branch. |\n| **MEDIUM** (a feature, several files) | FOCUSED | Deep on changed logic + its callers; skim the rest. |\n| **LARGE** (sweeping \u002F many files) | SURGICAL | Deep on the risk-bearing files; explicitly bound the rest as un-deep-reviewed. |\n\n**Risk triggers force HIGH depth regardless of diff size:** auth \u002F crypto,\nexternal calls \u002F SSRF, removal of a validation or authz check, money \u002F\ntenant-boundary code. [`blast-radius-analyzer`](..\u002Fblast-radius-analyzer\u002FSKILL.md)\nis one input to sizing; the depth policy + coverage-honesty line are this\nskill's addition. Every review ends with a **Coverage & confidence** line\n(deep-reviewed vs skimmed\u002Fbounded-out files + confidence) — silent partial\ncoverage reads as full coverage.\n\n## Re-review scoping + parallel-review de-biasing\n\n- **Re-review scoping** — on a follow-up push, scope to the **changed lines\n  only**; never flag new issues in untouched code (note pre-existing issues\n  separately, never in the blocking set). Same discipline `fix-pr-comments`\n  reply rounds apply.\n- **Ordering-bias** — when N reviewers\u002Flenses get the **same file set**\n  (`parallelizable: files`; council lenses), give each an independently\n  shuffled file order (deterministic seed per session, logged for replay) so\n  a fixed order does not correlate their blind spots. Single-reviewer → no shuffle.\n\n**MEASURED, and the result is a null — 2026-08-23.** This control is prose and nothing in\nthe package implements it. That is now true for a recorded reason rather than by\nomission: the pre-registered question — does rotating reviewer order change the finding set\non a frozen corpus, by more than 15 % — **cannot be answered from the corpus that exists**.\n`agents\u002Fevidence\u002Freviews\u002F` holds 123 findings artifacts, and none of them records the file\norder it was produced under, so the counterfactual is not recoverable; re-running reviewers\nproduces fresh judgements in which ordering is confounded with run-to-run variance. Full\nnull, with its reopening condition: `agents\u002Fevidence\u002Freview-rotation-prereg-and-null.md`.\nA reduced-power crossover was considered and refused — it would risk a false closure on a\ncontrol this paragraph still specifies.\n\n## Before creating a PR\n\n1. When `quality.local_auto_run: true`: run the project's quality pipeline (see the stack carve-out for the exact commands — PHP: `quality-tools`) and tests via the project's runner (`make test`, `npm test`, `pytest`, `go test .\u002F...`, or the project's wrapper script). Under the default (`false` \u002F missing): skip both — remote CI on the PR is the gate.\n2. Ensure CI passes on the branch (remote CI is authoritative).\n3. Self-review the diff: `git diff origin\u002Fmain..HEAD`.\n\n## Receiving feedback\n\n### The response pattern\n\nConstraint: **understand each comment fully before touching code, verify it against codebase reality, and implement one item at a time (test each).** Restate anything ambiguous in your own words — or ask. Push back with technical reasoning when a suggestion is unsound for *this* codebase rather than complying reflexively.\n\nIf **any item is unclear**, STOP — do not implement anything yet. Items may be related;\npartial understanding leads to wrong implementation.\n\n### No performative agreement\n\n- **Do NOT** reply with \"Great point!\", \"You're absolutely right!\", \"Excellent catch!\" or similar.\n- **Instead:** Just fix it. \"Fixed.\" or \"Updated — [brief description of what changed].\"\n- Actions speak louder than words — the code itself shows you heard the feedback.\n\n### Source-specific handling\n\n**Internal team feedback** (trusted colleagues):\n- Implement after understanding — no need for deep skepticism.\n- Still ask if scope is unclear.\n- Skip to action or technical acknowledgment.\n\n**External \u002F Copilot \u002F bot feedback** (less context):\n- Check: Technically correct for THIS codebase?\n- Check: Does it break existing functionality?\n- Check: Is there a reason for the current implementation?\n- Check: Does the reviewer understand the full context?\n- **YAGNI check:** If the reviewer suggests \"implementing properly\", grep the codebase\n  for actual usage. If unused → suggest removing (YAGNI).\n- If it conflicts with existing architectural decisions → discuss with the team first.\n\n### When to push back\n\nPush back when:\n- Suggestion breaks existing functionality.\n- Reviewer lacks full context.\n- Violates YAGNI (unused feature).\n- Technically incorrect for this stack.\n- Legacy\u002Fcompatibility reasons exist.\n- Conflicts with architectural decisions.\n\nHow: Use technical reasoning, not defensiveness. Reference working tests\u002Fcode.\n\n### Addressing PR comments systematically\n\nConstraint: **clarify anything unclear before implementing, fix one item at a time (test each), and reply in each review thread** — not as a top-level PR comment. Triage first (blocking → simple → complex) so blockers land first; `gh pr view --comments` lists the threads.\n\n```bash\n# Reply to a specific review comment thread\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  -f body=\"Fixed in latest commit.\"\n```\n\n## Rubric pass (optional, surfacing-only)\n\nAfter completing a review, run\n[`judge-artifact-completeness`](..\u002Fjudge-artifact-completeness\u002FSKILL.md)\nwith rubric `pr-review-score` to verify evidence-fit, risk\u002Fblast-radius\ncoverage, and migration\u002Frollback completeness. Invoke when the review is\nhigh-risk or the user asks for a completeness check — not by default.\n\n## Output format\n\nValidate, then emit these parts in order:\n\n1. **Reasoned validation first** — group candidates by file + line range,\n   disposition each CONFIRMED \u002F adjusted \u002F DROPPED with a one-line reason (not\n   vote-counting).\n2. **Tier 1 — Mechanical** — enumerated, fix-ready findings by severity blocks, never mixed.\n3. **Tier 2 — Alignment** — each flag names the principle\u002FADR at stake + the concern (from the governance-conflict scan); not fix-ready by construction.\n4. **Dropped false positives** — collapsible; each DROPPED candidate + reason. Empty is fine, but the section is mandatory (its presence proves validation ran).\n5. **Verdict line** — `YES` \u002F `NOT-SURE` (`❓`, a metadata gate fired or coverage bounded) \u002F `NO`, plus Tier-1 blocker\u002Fsuggestion counts.\n6. **Coverage & confidence line** — deep vs skimmed\u002Fbounded-out files + confidence.\n\nFull template, governance-conflict scan (status-aware over `docs\u002Fdecisions\u002F`,\nincl. draft ADRs; guarded `git blame` reviewer hint), and the security-class\ndeep-verify path → [`checklists\u002Fproducing-the-review.md`](checklists\u002Fproducing-the-review.md).\n\n> **Tally-vs-reasoned boundary.** Finding-level review uses reasoned validation\n> (each finding stands on its own traced reason); option-level decisions use\n> the council **stance tally** ([`ai-council`](..\u002Fai-council\u002FSKILL.md)). Never\n> cross-apply — no resolving a bug finding by counting votes, no resolving a\n> design option by reasoned-validating one take. Mirrored in `ai-council` so\n> the boundary is grep-checkable from both sides.\n\nGroup related findings; skip what the linter \u002F type-checker already catches.\n\n## Adversarial review\n\nBefore creating a PR or presenting code changes, run the **`adversarial-review`** skill.\nFocus on the \"Code changes \u002F Refactoring\" attack questions.\n\n## Auto-trigger keywords\n\n- code review\n- PR review\n- pull request\n- review checklist\n- review feedback\n- review changes\n- check my code\n\n## Gotcha\n\n- Don't rewrite code that works and is tested just because you'd write it differently.\n- The model tends to suggest changes that are out of scope — stay focused on the PR's intent.\n- \"I would prefer X\" is not a valid review comment unless X prevents a bug or violates a rule.\n- Always check if the PR has tests — missing tests is always worth flagging.\n\n## Do NOT\n\n- Do NOT approve without actually reading the code.\n- Do NOT agree with review comments without verifying them against the codebase.\n- Do NOT use performative language when responding to feedback (\"Great point!\", \"Excellent catch!\").\n- Do NOT nitpick style issues the project's formatter \u002F auto-refactor (ECS, Prettier, Ruff, gofmt) handles automatically.\n- Do NOT merge without CI passing and quality checks green.\n",{"name":5,"packs":54,"domain":56,"model_tier":38,"workspaces":57,"description":7,"parallelizable":42},[55],"engineering-base","quality",[58],"engineering","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Fcode-review-lens",1,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config","https:\u002F\u002Fevent4u.app","https:\u002F\u002Fgithub.com\u002Fevent4u-app","Your events in your hand","2026-11-14 02:29:41",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add event4u-app\u002Fagent-config --skill code-review-lens",{"tool":74,"command":75},"bunx","bunx skills add event4u-app\u002Fagent-config --skill code-review-lens",{"tool":77,"command":78},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill code-review-lens","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002FSKILL.md",true,[82,88,92,96,100,104,108,112,116,120],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"checklists\u002Fbackend.md","REFERENCE","参考文档",4143,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Fbackend.md",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"checklists\u002Fdatabase.md",1779,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Fdatabase.md",{"path":93,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":94,"sourceHtmlUrl":95},"checklists\u002Fdependency.md",1232,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Fdependency.md",{"path":97,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":98,"sourceHtmlUrl":99},"checklists\u002Fdocs.md",779,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Fdocs.md",{"path":101,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":102,"sourceHtmlUrl":103},"checklists\u002Ffrontend.md",1877,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Ffrontend.md",{"path":105,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":106,"sourceHtmlUrl":107},"checklists\u002Finfra.md",1465,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Finfra.md",{"path":109,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":110,"sourceHtmlUrl":111},"checklists\u002Fproducing-the-review.md",2865,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Fproducing-the-review.md",{"path":113,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":114,"sourceHtmlUrl":115},"checklists\u002Ftest-only.md",975,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fchecklists\u002Ftest-only.md",{"path":117,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":118,"sourceHtmlUrl":119},"evals\u002Fevals.json",6484,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fevals\u002Fevals.json",{"path":121,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":122,"sourceHtmlUrl":123},"evals\u002Ftriggers.json",2038,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-review-lens\u002Fevals\u002Ftriggers.json",[125,141,154,165,177,187],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":134,"publishedAt":49},"01M6X84PK96XBPENXH66JCTSD1","unknown-key-fixture","Declares a key the schema does not know.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Funknown-key\u002FSKILL.md",[131],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[135,136,137,138,139,140],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":49},"01M6X84HW7NAHZ7GZMQ9RXK1XJ","portable-fixture","Declares only semantics the MCP-lite carrier transports whole.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fportable\u002FSKILL.md",[147],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[137,149,150,151,152,140,153],"portable","portable fixture","engineer","only","MCP",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":161,"publishedAt":49},"01M6X84F29FE0RGGZ1ZTFGZTX2","non-portable-fixture","Declares a runtime semantic the carrier drops.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fnon-portable\u002FSKILL.md",[160],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[150,162,149,137,163,38,164,140],"non portable fixture","semantic","runtime",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":49},"01M6X848F706PT9MDCX75JKJ6B","candidate-zero-width","A candidate whose prose carries an invisible joiner.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fzero-width-injection\u002FSKILL.md",[171],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[173,174,175,176],"candidate zero width","candidate","ZeRO","prose",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":184,"publishedAt":49},"01M6X841SSC2T31VDF41SA6DG1","candidate-disclosure-suppression","A candidate whose prose tells the agent to withhold from the user.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdisclosure-suppression\u002FSKILL.md",[183],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[185,174,176,186],"candidate disclosure suppression","user",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":194,"publishedAt":49},"01M6X83TFS5AGPBPVTQNWP0BB3","candidate-dangerous-frontmatter","A candidate claiming an unscoped tool grant and a permission bypass.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdangerous-frontmatter\u002FSKILL.md",[193],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},[195,174,196,197,198,199],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]