[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X7KVM4ABNQ85MAKB8E78AD":3,"skill-same:01M6X7KVM4ABNQ85MAKB8E78AD":92},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":68,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6X7KVM4ABNQ85MAKB8E78AD","receiving-code-review",null,"When processing code review feedback (bot or human) before changing anything — triages, verifies and pushes back with technical reasoning — even when the user just says 'fix the comments'.","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\u002Freceiving-code-review\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"review","receiving code review","code","code review","process","when","review feedback","high","comments","with","processing","critical","human","back","fix","code review feedback","technical","just","feedback","bot","2026-11-10 10:12:30",false,"---\nmodel_tier: high\nname: receiving-code-review\ndescription: \"When processing code review feedback (bot or human) before changing anything — triages, verifies and pushes back with technical reasoning — even when the user just says 'fix the comments'.\"\npersonas:\n  - critical-challenger\ndomain: process\nworkspaces:\n  - engineering\npacks:\n  - engineering-base\n---\n\n# receiving-code-review\n\n## When to use\n\n* A PR has review comments (from bots like Copilot, Greptile, Augment,\n  or from human reviewers) and the next step is to address them\n* Someone pasted review feedback into the conversation and asks you\n  to \"fix it\" or \"handle it\"\n* A pair-programming partner gave verbal suggestions about code you\n  just wrote\n* You are tempted to reply \"you are absolutely right\" before reading\n  the rest of the comment\n\nDo NOT use when:\n\n* You are writing a review yourself (different discipline)\n* The user explicitly asks for blind implementation of a specific change\n  that is not framed as review feedback\n* The feedback is pure style\u002Fformatting that a linter should decide\n  automatically — just run the linter\n\n## Goal\n\nTreat review feedback as **suggestions to evaluate**, not orders to\nexecute. Separate correct feedback from reviewer confusion. Push back\nwith technical reasoning when the suggestion is wrong for this\ncodebase. Never agree performatively.\n\n## The Iron Law\n\n```\nNO IMPLEMENTATION UNTIL THE FEEDBACK IS UNDERSTOOD AND VERIFIED.\n```\n\nA \"fix\" implemented against a misread comment is worse than no fix —\nit ships the wrong behavior under the label of \"addressed feedback\".\n\n## Procedure\n\n### 1. Read the full comment set before touching code\n\nRead **every** open comment on the PR first. Comments often relate to\neach other — fixing comment #3 in isolation can conflict with comment\n#5. Group them:\n\n* **Blocking** — breaks behavior, introduces a bug, security issue\n* **Important** — logic is correct but design \u002F readability issue\n* **Minor** — naming, comment style, formatting the linter missed\n* **Wrong** — reviewer misunderstood the code, or suggestion would\n  regress another behavior\n\n### 2. Restate each comment in your own words\n\nFor every comment, write (internally or to the user): *\"The reviewer\nis asking me to X because Y.\"*\n\nIf you cannot complete that sentence confidently → the comment is\nunclear. Ask for clarification **before** implementing anything. Do\nnot implement the clear ones first and ask later — they may be linked.\n\n### 3. Verify each claim against the code\n\nFor each comment classified as blocking\u002Fimportant:\n\n* Reproduce the alleged issue locally (run the test, hit the endpoint,\n  read the actual runtime value — see [`systematic-debugging`](..\u002Fsystematic-debugging\u002FSKILL.md))\n* Check what the code actually does, not what the reviewer **thinks**\n  it does\n* Check whether the suggested fix would break another test or caller\n* Check `git blame` \u002F history — the current code may be the way it is\n  for a reason\n* **Consult memory for prior context.** Via\n  [`memory-access`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fmemory-access.md),\n  call `retrieve(types=[\"historical-patterns\"],\n  keys=\u003Cfiles in the review>, limit=3)`. A registered historical pattern\n  may confirm the reviewer's concern (accept). For architectural rationale\n  (\"why is the current shape intentional?\"), check the ADR index\n  [`docs\u002Fdecisions\u002FINDEX.md`](..\u002F..\u002F..\u002Fdocs\u002Fdecisions\u002FINDEX.md) — push back\n  with the cited ADR number.\n\n### 4. Decide: accept, push back, or escalate\n\n| Situation | Response | Reproduced by |\n|---|---|---|\n| Reviewer is right, fix is local, no caller impact | Implement, reference the comment in the commit message | `verify: \u003Ccmd> -> \u003Cexit or \u002Fre\u002F>` that was red before the fix |\n| Reviewer is right but fix affects other callers | Note the downstream effects in the reply, then implement | `verify:` clause, as above |\n| Reviewer is wrong — based on misreading the code | Reply with evidence (specific line \u002F test \u002F value), do not change code | `verify:` clause showing the alleged defect absent, or `not reproduced` |\n| Reviewer suggests a feature the codebase does not use (YAGNI) | Reply asking whether the feature is actually needed, do not build speculatively | `not reproduced` |\n| Reviewer and user \u002F architecture disagree | Escalate to the user before implementing either path | `verify:` clause or `not reproduced` |\n\n**Reproduced by** records the step-3 reproduction in the verify-clause\nexpectation grammar (`\u003Ccmd> -> 0`, `\u003Ccmd> -> \u002Fregex\u002F`), or the literal\n`not reproduced`. An accepted blocking comment with no entry in that column\nstays open — the fix has nothing showing it addressed the reported defect.\nThis is `enforcement: instruction-only`: no gate reads the column.\n\n### 5. Reply in the right place, with the right tone\n\n* For inline PR comments → reply **in the thread** of that comment,\n  not as a top-level PR comment\n* Quote **evidence**, not opinion — \"line 47 already handles this via\n  `$x->isNull()`\" beats \"I think that's fine\"\n* No flattery. No \"great catch\", \"absolutely right\", \"thanks for\n  noticing\". The existing `language-and-tone` rule already bans this —\n  actions are the acknowledgement\n* If you were wrong in your earlier pushback, state it factually and\n  move on. No long apology\n\n### 6. Implement in priority order, one at a time\n\n1. Blocking issues first\n2. Important issues next\n3. Minor issues last (or bundle them into a single commit)\n4. Wrong \u002F YAGNI: no code change, only a reply with reasoning\n\nRun the relevant tests and linters **between** each group — do not\nbatch four changes and then run tests once. See\n[`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md).\n\n## Output format\n\nWhen reporting back to the user after handling review:\n\n1. **Triage table** — comment → classification → decision\n2. **Implemented changes** — bullet per change with file + commit ref\n3. **Pushed back** — bullet per rejected comment with the evidence\n4. **Outstanding** — anything awaiting clarification, with the\n   specific question\n\n## Gotchas\n\n* Bot comments (Copilot, Greptile) are **not** automatically right.\n  They frequently flag false positives on patterns the codebase uses\n  deliberately. Verify like you would a human comment.\n* A comment that reads like a question (\"should this be X?\") is often\n  a polite way of saying \"change it to X\". Ask if unclear instead of\n  guessing the register.\n* Resolving a comment in the GitHub UI without an accompanying fix or\n  reply silently marks it handled — reviewers may not notice the lack\n  of substance.\n* Stacked PRs — a comment on the base PR may already be fixed in the\n  child PR. Check both before touching code.\n* A suggestion that passes review aesthetics but fails the test suite\n  is still a regression. Run tests even when \"the change is trivial\".\n* Flattery leaks in as \"good point\" or \"thanks\". Delete before\n  sending. The code change itself is the acknowledgement.\n\n## Do NOT\n\n* Do NOT reply \"you are absolutely right\", \"great catch\", or any\n  flattery variant — actions acknowledge, words do not\n* Do NOT implement a suggestion before verifying it against the code\n* Do NOT fix the clear items first and ask about the unclear ones\n  later when the items are linked\n* Do NOT accept a reviewer's suggestion that conflicts with an\n  explicit architectural decision without raising it\n* Do NOT batch multiple unrelated fixes into one commit — reviewers\n  cannot re-review selectively\n* Do NOT mark a comment resolved without either a code change or a\n  reply with reasoning\n\n## Anti-patterns\n\n* Replying \"Fixed!\" after a commit that does not actually address the\n  comment (wrong file, missed case)\n* Rewriting the comment author's suggestion into your own words\n  without checking whether the reinterpretation still matches intent\n* Implementing the YAGNI-suggested feature \"just in case\" the reviewer\n  comes back\n* Silent disagreement — ignoring a comment without a reply\n\n## When to hand over to another skill \u002F command\n\n* Executing the fixes across many comments → [`fix-pr-comments`](..\u002F..\u002Fcommands\u002Ffix\u002Fpr-comments.md)\n  (handles both bot + human reviewers in one pass)\n* Running the full verification gate before pushing replies →\n  [`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md)\n* Writing the commit message that references the review →\n  [`conventional-commits-writing`](..\u002Fconventional-commits-writing\u002FSKILL.md)\n* Digging into *why* the reviewer's scenario actually fails →\n  [`systematic-debugging`](..\u002Fsystematic-debugging\u002FSKILL.md)\n\n## Validation checklist\n\nBefore considering review handling done:\n\n* [ ] Every open comment has been read, classified, and has a decision\n* [ ] No comment was implemented without a one-sentence restatement\n* [ ] Every implemented fix has been verified by a test or runtime check\n* [ ] Every rejected comment has a reply quoting evidence\n* [ ] No comment was marked resolved without code change or reply\n* [ ] No reply contains flattery\n* [ ] Linters and relevant tests pass after the changes\n","# receiving-code-review\n\n## When to use\n\n* A PR has review comments (from bots like Copilot, Greptile, Augment,\n  or from human reviewers) and the next step is to address them\n* Someone pasted review feedback into the conversation and asks you\n  to \"fix it\" or \"handle it\"\n* A pair-programming partner gave verbal suggestions about code you\n  just wrote\n* You are tempted to reply \"you are absolutely right\" before reading\n  the rest of the comment\n\nDo NOT use when:\n\n* You are writing a review yourself (different discipline)\n* The user explicitly asks for blind implementation of a specific change\n  that is not framed as review feedback\n* The feedback is pure style\u002Fformatting that a linter should decide\n  automatically — just run the linter\n\n## Goal\n\nTreat review feedback as **suggestions to evaluate**, not orders to\nexecute. Separate correct feedback from reviewer confusion. Push back\nwith technical reasoning when the suggestion is wrong for this\ncodebase. Never agree performatively.\n\n## The Iron Law\n\n```\nNO IMPLEMENTATION UNTIL THE FEEDBACK IS UNDERSTOOD AND VERIFIED.\n```\n\nA \"fix\" implemented against a misread comment is worse than no fix —\nit ships the wrong behavior under the label of \"addressed feedback\".\n\n## Procedure\n\n### 1. Read the full comment set before touching code\n\nRead **every** open comment on the PR first. Comments often relate to\neach other — fixing comment #3 in isolation can conflict with comment\n#5. Group them:\n\n* **Blocking** — breaks behavior, introduces a bug, security issue\n* **Important** — logic is correct but design \u002F readability issue\n* **Minor** — naming, comment style, formatting the linter missed\n* **Wrong** — reviewer misunderstood the code, or suggestion would\n  regress another behavior\n\n### 2. Restate each comment in your own words\n\nFor every comment, write (internally or to the user): *\"The reviewer\nis asking me to X because Y.\"*\n\nIf you cannot complete that sentence confidently → the comment is\nunclear. Ask for clarification **before** implementing anything. Do\nnot implement the clear ones first and ask later — they may be linked.\n\n### 3. Verify each claim against the code\n\nFor each comment classified as blocking\u002Fimportant:\n\n* Reproduce the alleged issue locally (run the test, hit the endpoint,\n  read the actual runtime value — see [`systematic-debugging`](..\u002Fsystematic-debugging\u002FSKILL.md))\n* Check what the code actually does, not what the reviewer **thinks**\n  it does\n* Check whether the suggested fix would break another test or caller\n* Check `git blame` \u002F history — the current code may be the way it is\n  for a reason\n* **Consult memory for prior context.** Via\n  [`memory-access`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fmemory-access.md),\n  call `retrieve(types=[\"historical-patterns\"],\n  keys=\u003Cfiles in the review>, limit=3)`. A registered historical pattern\n  may confirm the reviewer's concern (accept). For architectural rationale\n  (\"why is the current shape intentional?\"), check the ADR index\n  [`docs\u002Fdecisions\u002FINDEX.md`](..\u002F..\u002F..\u002Fdocs\u002Fdecisions\u002FINDEX.md) — push back\n  with the cited ADR number.\n\n### 4. Decide: accept, push back, or escalate\n\n| Situation | Response | Reproduced by |\n|---|---|---|\n| Reviewer is right, fix is local, no caller impact | Implement, reference the comment in the commit message | `verify: \u003Ccmd> -> \u003Cexit or \u002Fre\u002F>` that was red before the fix |\n| Reviewer is right but fix affects other callers | Note the downstream effects in the reply, then implement | `verify:` clause, as above |\n| Reviewer is wrong — based on misreading the code | Reply with evidence (specific line \u002F test \u002F value), do not change code | `verify:` clause showing the alleged defect absent, or `not reproduced` |\n| Reviewer suggests a feature the codebase does not use (YAGNI) | Reply asking whether the feature is actually needed, do not build speculatively | `not reproduced` |\n| Reviewer and user \u002F architecture disagree | Escalate to the user before implementing either path | `verify:` clause or `not reproduced` |\n\n**Reproduced by** records the step-3 reproduction in the verify-clause\nexpectation grammar (`\u003Ccmd> -> 0`, `\u003Ccmd> -> \u002Fregex\u002F`), or the literal\n`not reproduced`. An accepted blocking comment with no entry in that column\nstays open — the fix has nothing showing it addressed the reported defect.\nThis is `enforcement: instruction-only`: no gate reads the column.\n\n### 5. Reply in the right place, with the right tone\n\n* For inline PR comments → reply **in the thread** of that comment,\n  not as a top-level PR comment\n* Quote **evidence**, not opinion — \"line 47 already handles this via\n  `$x->isNull()`\" beats \"I think that's fine\"\n* No flattery. No \"great catch\", \"absolutely right\", \"thanks for\n  noticing\". The existing `language-and-tone` rule already bans this —\n  actions are the acknowledgement\n* If you were wrong in your earlier pushback, state it factually and\n  move on. No long apology\n\n### 6. Implement in priority order, one at a time\n\n1. Blocking issues first\n2. Important issues next\n3. Minor issues last (or bundle them into a single commit)\n4. Wrong \u002F YAGNI: no code change, only a reply with reasoning\n\nRun the relevant tests and linters **between** each group — do not\nbatch four changes and then run tests once. See\n[`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md).\n\n## Output format\n\nWhen reporting back to the user after handling review:\n\n1. **Triage table** — comment → classification → decision\n2. **Implemented changes** — bullet per change with file + commit ref\n3. **Pushed back** — bullet per rejected comment with the evidence\n4. **Outstanding** — anything awaiting clarification, with the\n   specific question\n\n## Gotchas\n\n* Bot comments (Copilot, Greptile) are **not** automatically right.\n  They frequently flag false positives on patterns the codebase uses\n  deliberately. Verify like you would a human comment.\n* A comment that reads like a question (\"should this be X?\") is often\n  a polite way of saying \"change it to X\". Ask if unclear instead of\n  guessing the register.\n* Resolving a comment in the GitHub UI without an accompanying fix or\n  reply silently marks it handled — reviewers may not notice the lack\n  of substance.\n* Stacked PRs — a comment on the base PR may already be fixed in the\n  child PR. Check both before touching code.\n* A suggestion that passes review aesthetics but fails the test suite\n  is still a regression. Run tests even when \"the change is trivial\".\n* Flattery leaks in as \"good point\" or \"thanks\". Delete before\n  sending. The code change itself is the acknowledgement.\n\n## Do NOT\n\n* Do NOT reply \"you are absolutely right\", \"great catch\", or any\n  flattery variant — actions acknowledge, words do not\n* Do NOT implement a suggestion before verifying it against the code\n* Do NOT fix the clear items first and ask about the unclear ones\n  later when the items are linked\n* Do NOT accept a reviewer's suggestion that conflicts with an\n  explicit architectural decision without raising it\n* Do NOT batch multiple unrelated fixes into one commit — reviewers\n  cannot re-review selectively\n* Do NOT mark a comment resolved without either a code change or a\n  reply with reasoning\n\n## Anti-patterns\n\n* Replying \"Fixed!\" after a commit that does not actually address the\n  comment (wrong file, missed case)\n* Rewriting the comment author's suggestion into your own words\n  without checking whether the reinterpretation still matches intent\n* Implementing the YAGNI-suggested feature \"just in case\" the reviewer\n  comes back\n* Silent disagreement — ignoring a comment without a reply\n\n## When to hand over to another skill \u002F command\n\n* Executing the fixes across many comments → [`fix-pr-comments`](..\u002F..\u002Fcommands\u002Ffix\u002Fpr-comments.md)\n  (handles both bot + human reviewers in one pass)\n* Running the full verification gate before pushing replies →\n  [`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md)\n* Writing the commit message that references the review →\n  [`conventional-commits-writing`](..\u002Fconventional-commits-writing\u002FSKILL.md)\n* Digging into *why* the reviewer's scenario actually fails →\n  [`systematic-debugging`](..\u002Fsystematic-debugging\u002FSKILL.md)\n\n## Validation checklist\n\nBefore considering review handling done:\n\n* [ ] Every open comment has been read, classified, and has a decision\n* [ ] No comment was implemented without a one-sentence restatement\n* [ ] Every implemented fix has been verified by a test or runtime check\n* [ ] Every rejected comment has a reply quoting evidence\n* [ ] No comment was marked resolved without code change or reply\n* [ ] No reply contains flattery\n* [ ] Linters and relevant tests pass after the changes\n",{"name":5,"packs":57,"domain":36,"personas":59,"model_tier":39,"workspaces":61,"description":7},[58],"engineering-base",[60],"critical-challenger",[62],"engineering","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Freceiving-code-review",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-13 03:25:49",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add event4u-app\u002Fagent-config --skill receiving-code-review",{"tool":78,"command":79},"bunx","bunx skills add event4u-app\u002Fagent-config --skill receiving-code-review",{"tool":81,"command":82},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill receiving-code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Freceiving-code-review\u002FSKILL.md",true,[86],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Ftriggers.json","REFERENCE","参考文档",3351,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Freceiving-code-review\u002Fevals\u002Ftriggers.json",[93,107,120,131,143,153],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":100,"publishedAt":52},"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",[99],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[101,102,103,104,105,106],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":52},"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",[113],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[103,115,116,117,118,106,119],"portable","portable fixture","engineer","only","MCP",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":52},"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",[126],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[116,128,115,103,129,39,130,106],"non portable fixture","semantic","runtime",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":52},"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",[137],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[139,140,141,142],"candidate zero width","candidate","ZeRO","prose",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":52},"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",[149],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[151,140,142,152],"candidate disclosure suppression","user",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":52},"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",[159],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[161,140,162,163,164,165],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]