[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X7N1YCKD6A1SDTYFVF57AB":3,"skill-same:01M6X7N1YCKD6A1SDTYFVF57AB":94},{"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":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":70,"ownerDescription":72,"updatedAt":73,"install":74,"resources":87},"01M6X7N1YCKD6A1SDTYFVF57AB","requesting-code-review",null,"Use when asking for a review or creating a PR — self-review first, frame the right context, test plan included — even when the user just says 'open a PR' or 'ready to merge'.","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\u002Frequesting-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","code review","code","requesting code review","when","frame","for","critical","self","ready","use","context","just","plan","open","test plan","first","pr","merge","test","2026-11-10 10:12:30",false,"---\nmodel_tier: high\nname: requesting-code-review\ndescription: \"Use when asking for a review or creating a PR — self-review first, frame the right context, test plan included — even when the user just says 'open a PR' or 'ready to merge'.\"\npersonas:\n  - critical-challenger\ndomain: process\nworkspaces:\n  - engineering\npacks:\n  - engineering-base\n---\n\n# requesting-code-review\n\n## When to use\n\n* About to run `\u002Fcreate-pr` or `\u002Fprepare-for-review`\n* A feature or bug fix is code-complete and the next step is \"get\n  eyes on it\"\n* A stacked PR is ready and you need the parent branch reviewer to\n  context-switch smoothly\n* Asking a human for a quick sanity check on a specific commit or\n  diff\n\nDo NOT use when:\n\n* You are *processing* review feedback — use [`receiving-code-review`](..\u002Freceiving-code-review\u002FSKILL.md)\n* The branch is not yet code-complete — the review-request gate\n  requires green tests and a clean diff\n* The change is documentation-only and has no behavior impact\n\n## Goal\n\nGive the reviewer exactly the context they need — what changed, why,\nhow to verify — without forcing them to reconstruct your thought\nprocess. A well-framed review request **halves** review time and\n**reduces** back-and-forth on missing context.\n\n## The Iron Law\n\n```\nNEVER REQUEST REVIEW FROM A BRANCH YOU HAVE NOT REVIEWED YOURSELF.\n```\n\nSelf-review is the single cheapest filter. It catches the issues a\nhuman reviewer would flag in round one, so the human reviewer can\nspend time on the issues only they can see.\n\n## Procedure\n\n### 1. Self-review first\n\nBefore asking anyone else:\n\n* Read the full diff (`git diff \u003Cbase>...\u003Chead>`), not just the files\n  you remember touching\n* Check for accidental debug output, dead code, leftover `dd()`,\n  `console.log`, commented-out blocks\n* Check for secrets in diff — API keys, connection strings, tokens\n* Check file-system side effects — generated files, lockfile churn,\n  IDE configs, `.env` changes\n* Run the linter + tests (see [`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md))\n* If you find issues → fix them, do **not** ship them and hope the\n  reviewer flags them\n\nUse the [`review-changes`](..\u002F..\u002Fcommands\u002Freview\u002Fchanges.md) command\nas the structured walk-through.\n\n### 2. Establish the diff baseline\n\nDetermine the correct base commit:\n\n```bash\n# Simple branch from main\nBASE=$(git merge-base HEAD main)\n\n# Stacked PR — parent branch is base, not main\nBASE=$(git merge-base HEAD \u003Cparent-branch>)\n\nHEAD=$(git rev-parse HEAD)\n```\n\nThe base matters for the reviewer's diff view — wrong base = they\nreview 80 unrelated commits.\n\n### 3. Write the review request context\n\nAny review request must answer four questions. If any is missing, the\nreviewer will ask — and that round trip is preventable.\n\n| Question | Where it lives |\n|---|---|\n| **What changed?** | PR title (imperative, Conventional Commits) + summary bullets |\n| **Why?** | Link to ticket \u002F issue \u002F Sentry event \u002F user message |\n| **How do I verify it?** | Test plan: commands to run, URLs to hit, expected behavior |\n| **What should I look at first?** | Highlights: \"pay attention to X because Y\" or \"skip Z, it is generated\" |\n\nSee [`create-pr-description`](..\u002F..\u002Fcommands\u002Fpr\u002Fcreate\u002Fdescription-only.md)\nfor the full structured template, and\n[`conventional-commits-writing`](..\u002Fconventional-commits-writing\u002FSKILL.md)\nfor the title format.\n\n### 4. Keep the PR reviewable in size\n\n* Target \u003C 400 lines of real diff (excluding generated \u002F lockfiles)\n* If bigger — consider splitting into a stack (refactor PR → feature\n  PR) so reviewers can handle each in one sitting\n* Flag generated files explicitly in the description so reviewers\n  skip them\n* Never mix a refactor + behavior change in the same PR — reviewers\n  cannot isolate the risk\n\n### 5. Pick the right reviewer set\n\n* **Architectural impact** → the code owner for the affected area\n* **Security-sensitive** → a security-reviewer role if the project has\n  one\n* **Bots** → let Copilot \u002F Greptile \u002F Augment run automatically; do not\n  gate human review on bot completion\n* **Cross-team change** → each affected team's owner\n\nIf the project has a `CODEOWNERS` file, GitHub handles this\nautomatically — do not override without a reason.\n\n### 6. Send and wait — do not nudge early\n\nAfter the PR is open:\n\n* Respond to questions, not to the implicit \"where is my review?\"\n  schedule\n* If the review is blocking and overdue → a single short nudge is\n  appropriate; do not re-open or force-push to bump the PR list\n\nWhen review comments arrive → switch to\n[`receiving-code-review`](..\u002Freceiving-code-review\u002FSKILL.md).\n\n## Output format\n\nWhen handing the review request to the reviewer (PR body, Slack, email):\n\n1. **Title** — Conventional Commit imperative\n2. **Summary** — 2–5 bullets of what changed\n3. **Motivation** — why, with ticket \u002F Sentry \u002F user-message link\n4. **Test plan** — exact commands or URLs + expected result\n5. **Risk \u002F scope notes** — what the reviewer should pay attention to\n6. **Non-goals** — what this PR deliberately does **not** do\n7. **Screenshots \u002F logs** — when UI or runtime behavior changed\n\n## Gotchas\n\n* \"Ready for review\" on a red CI run signals carelessness — wait for\n  green or explain the specific failure\n* A 1000-line PR with \"no behavior change\" still needs review — the\n  reviewer has no way to confirm \"no behavior change\" without reading\n  every line\n* Auto-merge on approval bypasses re-review after later force-pushes\n  — use deliberately, not by habit\n* A PR description that says \"see the code\" is not a description —\n  reviewers need the why\n* Requesting review from someone without context (new hire, other\n  team) without a longer pairing — they cannot do a deep review cold\n* Rebasing during review invalidates line-comments; let reviewers\n  finish a round before rebasing when possible\n\n## Do NOT\n\n* Do NOT request review before self-review\n* Do NOT request review on a branch with failing CI (except when\n  explicitly documenting \"CI broken, please eyeball X only\")\n* Do NOT mix unrelated changes in one PR\n* Do NOT force-push during active review without a good reason and a\n  note to the reviewer\n* Do NOT leave the PR description empty\n* Do NOT request review from reviewers who lack context just to get\n  approvals\n\n## Anti-patterns\n\n* \"Small cleanup\" titles on 800-line diffs\n* Test plan that says \"should work\"\n* Hiding a risky change inside a 40-file refactor PR\n* Pinging reviewers before CI goes green\n* Requesting review as a substitute for thinking the problem through\n\n## When to hand over to another skill \u002F command\n\n* Self-review walkthrough → [`review-changes`](..\u002F..\u002Fcommands\u002Freview\u002Fchanges.md)\n* Bringing a stacked branch up to date first →\n  [`prepare-for-review`](..\u002F..\u002Fcommands\u002Fprepare-for-review.md)\n* Writing the PR description → [`create-pr-description`](..\u002F..\u002Fcommands\u002Fpr\u002Fcreate\u002Fdescription-only.md)\n* Actually opening the PR → [`create-pr`](..\u002F..\u002Fcommands\u002Fpr\u002Fcreate.md)\n* Writing the commits themselves → [`commit`](..\u002F..\u002Fcommands\u002Fcommit.md),\n  [`conventional-commits-writing`](..\u002Fconventional-commits-writing\u002FSKILL.md)\n* Verifying readiness → [`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md)\n* Processing the feedback when it arrives → [`receiving-code-review`](..\u002Freceiving-code-review\u002FSKILL.md)\n\n## Validation checklist\n\nBefore asking for review:\n\n* [ ] Self-review walkthrough done on the full diff\n* [ ] Linter + targeted tests + full test suite green\n* [ ] PR title follows Conventional Commits\n* [ ] PR description has summary, motivation, test plan, risk notes\n* [ ] Diff is reviewable in size (split if > 400 lines of real code)\n* [ ] CODEOWNERS \u002F reviewer set is correct\n* [ ] No debug code, secrets, or stray files in the diff\n* [ ] No unrelated changes bundled in\n","# requesting-code-review\n\n## When to use\n\n* About to run `\u002Fcreate-pr` or `\u002Fprepare-for-review`\n* A feature or bug fix is code-complete and the next step is \"get\n  eyes on it\"\n* A stacked PR is ready and you need the parent branch reviewer to\n  context-switch smoothly\n* Asking a human for a quick sanity check on a specific commit or\n  diff\n\nDo NOT use when:\n\n* You are *processing* review feedback — use [`receiving-code-review`](..\u002Freceiving-code-review\u002FSKILL.md)\n* The branch is not yet code-complete — the review-request gate\n  requires green tests and a clean diff\n* The change is documentation-only and has no behavior impact\n\n## Goal\n\nGive the reviewer exactly the context they need — what changed, why,\nhow to verify — without forcing them to reconstruct your thought\nprocess. A well-framed review request **halves** review time and\n**reduces** back-and-forth on missing context.\n\n## The Iron Law\n\n```\nNEVER REQUEST REVIEW FROM A BRANCH YOU HAVE NOT REVIEWED YOURSELF.\n```\n\nSelf-review is the single cheapest filter. It catches the issues a\nhuman reviewer would flag in round one, so the human reviewer can\nspend time on the issues only they can see.\n\n## Procedure\n\n### 1. Self-review first\n\nBefore asking anyone else:\n\n* Read the full diff (`git diff \u003Cbase>...\u003Chead>`), not just the files\n  you remember touching\n* Check for accidental debug output, dead code, leftover `dd()`,\n  `console.log`, commented-out blocks\n* Check for secrets in diff — API keys, connection strings, tokens\n* Check file-system side effects — generated files, lockfile churn,\n  IDE configs, `.env` changes\n* Run the linter + tests (see [`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md))\n* If you find issues → fix them, do **not** ship them and hope the\n  reviewer flags them\n\nUse the [`review-changes`](..\u002F..\u002Fcommands\u002Freview\u002Fchanges.md) command\nas the structured walk-through.\n\n### 2. Establish the diff baseline\n\nDetermine the correct base commit:\n\n```bash\n# Simple branch from main\nBASE=$(git merge-base HEAD main)\n\n# Stacked PR — parent branch is base, not main\nBASE=$(git merge-base HEAD \u003Cparent-branch>)\n\nHEAD=$(git rev-parse HEAD)\n```\n\nThe base matters for the reviewer's diff view — wrong base = they\nreview 80 unrelated commits.\n\n### 3. Write the review request context\n\nAny review request must answer four questions. If any is missing, the\nreviewer will ask — and that round trip is preventable.\n\n| Question | Where it lives |\n|---|---|\n| **What changed?** | PR title (imperative, Conventional Commits) + summary bullets |\n| **Why?** | Link to ticket \u002F issue \u002F Sentry event \u002F user message |\n| **How do I verify it?** | Test plan: commands to run, URLs to hit, expected behavior |\n| **What should I look at first?** | Highlights: \"pay attention to X because Y\" or \"skip Z, it is generated\" |\n\nSee [`create-pr-description`](..\u002F..\u002Fcommands\u002Fpr\u002Fcreate\u002Fdescription-only.md)\nfor the full structured template, and\n[`conventional-commits-writing`](..\u002Fconventional-commits-writing\u002FSKILL.md)\nfor the title format.\n\n### 4. Keep the PR reviewable in size\n\n* Target \u003C 400 lines of real diff (excluding generated \u002F lockfiles)\n* If bigger — consider splitting into a stack (refactor PR → feature\n  PR) so reviewers can handle each in one sitting\n* Flag generated files explicitly in the description so reviewers\n  skip them\n* Never mix a refactor + behavior change in the same PR — reviewers\n  cannot isolate the risk\n\n### 5. Pick the right reviewer set\n\n* **Architectural impact** → the code owner for the affected area\n* **Security-sensitive** → a security-reviewer role if the project has\n  one\n* **Bots** → let Copilot \u002F Greptile \u002F Augment run automatically; do not\n  gate human review on bot completion\n* **Cross-team change** → each affected team's owner\n\nIf the project has a `CODEOWNERS` file, GitHub handles this\nautomatically — do not override without a reason.\n\n### 6. Send and wait — do not nudge early\n\nAfter the PR is open:\n\n* Respond to questions, not to the implicit \"where is my review?\"\n  schedule\n* If the review is blocking and overdue → a single short nudge is\n  appropriate; do not re-open or force-push to bump the PR list\n\nWhen review comments arrive → switch to\n[`receiving-code-review`](..\u002Freceiving-code-review\u002FSKILL.md).\n\n## Output format\n\nWhen handing the review request to the reviewer (PR body, Slack, email):\n\n1. **Title** — Conventional Commit imperative\n2. **Summary** — 2–5 bullets of what changed\n3. **Motivation** — why, with ticket \u002F Sentry \u002F user-message link\n4. **Test plan** — exact commands or URLs + expected result\n5. **Risk \u002F scope notes** — what the reviewer should pay attention to\n6. **Non-goals** — what this PR deliberately does **not** do\n7. **Screenshots \u002F logs** — when UI or runtime behavior changed\n\n## Gotchas\n\n* \"Ready for review\" on a red CI run signals carelessness — wait for\n  green or explain the specific failure\n* A 1000-line PR with \"no behavior change\" still needs review — the\n  reviewer has no way to confirm \"no behavior change\" without reading\n  every line\n* Auto-merge on approval bypasses re-review after later force-pushes\n  — use deliberately, not by habit\n* A PR description that says \"see the code\" is not a description —\n  reviewers need the why\n* Requesting review from someone without context (new hire, other\n  team) without a longer pairing — they cannot do a deep review cold\n* Rebasing during review invalidates line-comments; let reviewers\n  finish a round before rebasing when possible\n\n## Do NOT\n\n* Do NOT request review before self-review\n* Do NOT request review on a branch with failing CI (except when\n  explicitly documenting \"CI broken, please eyeball X only\")\n* Do NOT mix unrelated changes in one PR\n* Do NOT force-push during active review without a good reason and a\n  note to the reviewer\n* Do NOT leave the PR description empty\n* Do NOT request review from reviewers who lack context just to get\n  approvals\n\n## Anti-patterns\n\n* \"Small cleanup\" titles on 800-line diffs\n* Test plan that says \"should work\"\n* Hiding a risky change inside a 40-file refactor PR\n* Pinging reviewers before CI goes green\n* Requesting review as a substitute for thinking the problem through\n\n## When to hand over to another skill \u002F command\n\n* Self-review walkthrough → [`review-changes`](..\u002F..\u002Fcommands\u002Freview\u002Fchanges.md)\n* Bringing a stacked branch up to date first →\n  [`prepare-for-review`](..\u002F..\u002Fcommands\u002Fprepare-for-review.md)\n* Writing the PR description → [`create-pr-description`](..\u002F..\u002Fcommands\u002Fpr\u002Fcreate\u002Fdescription-only.md)\n* Actually opening the PR → [`create-pr`](..\u002F..\u002Fcommands\u002Fpr\u002Fcreate.md)\n* Writing the commits themselves → [`commit`](..\u002F..\u002Fcommands\u002Fcommit.md),\n  [`conventional-commits-writing`](..\u002Fconventional-commits-writing\u002FSKILL.md)\n* Verifying readiness → [`verify-completion-evidence`](..\u002Fverify-completion-evidence\u002FSKILL.md)\n* Processing the feedback when it arrives → [`receiving-code-review`](..\u002Freceiving-code-review\u002FSKILL.md)\n\n## Validation checklist\n\nBefore asking for review:\n\n* [ ] Self-review walkthrough done on the full diff\n* [ ] Linter + targeted tests + full test suite green\n* [ ] PR title follows Conventional Commits\n* [ ] PR description has summary, motivation, test plan, risk notes\n* [ ] Diff is reviewable in size (split if > 400 lines of real code)\n* [ ] CODEOWNERS \u002F reviewer set is correct\n* [ ] No debug code, secrets, or stray files in the diff\n* [ ] No unrelated changes bundled in\n",{"name":5,"packs":57,"domain":59,"personas":60,"model_tier":62,"workspaces":63,"description":7},[58],"engineering-base","process",[61],"critical-challenger","high",[64],"engineering","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Frequesting-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":75,"prompt":85,"zipAvailable":86},[76,79,82],{"tool":77,"command":78},"npx","npx skills add event4u-app\u002Fagent-config --skill requesting-code-review",{"tool":80,"command":81},"bunx","bunx skills add event4u-app\u002Fagent-config --skill requesting-code-review",{"tool":83,"command":84},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill requesting-code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Frequesting-code-review\u002FSKILL.md",true,[88],{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"evals\u002Ftriggers.json","REFERENCE","参考文档",3155,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Frequesting-code-review\u002Fevals\u002Ftriggers.json",[95,109,122,133,145,155],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"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",[101],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[103,104,105,106,107,108],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"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",[115],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[105,117,118,119,120,108,121],"portable","portable fixture","engineer","only","MCP",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"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",[128],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[118,130,117,105,131,62,132,108],"non portable fixture","semantic","runtime",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"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",[139],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[141,142,143,144],"candidate zero width","candidate","ZeRO","prose",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"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",[151],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[153,142,144,154],"candidate disclosure suppression","user",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"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",[161],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[163,142,164,165,166,167],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]