[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NQBECN46XYCTB6HB4NNRJE":3,"skill-same:01M6NQBECN46XYCTB6HB4NNRJE":64},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6NQBECN46XYCTB6HB4NNRJE","review-pr",null,"Review one pull request as an independent, read-only reviewer and post the record comment merge-check reads. The manual trigger for a cross-agent review.","C360Studio\u002Fsemteams","C360Studio","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F107274645?v=4","01M6NQ809JZG513TZ7FJX8SAKQ","Complete 360 Studio","01M6NQ80DRB447R1H9W554K7V8",0,"MIT","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview-pr\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"review pr","review","pr","check","reviewer","only","read","trigger","agent review","manual","request","merge","read-only","for","pull request","post","record","as","pull","2026-11-10 10:12:30",false,"---\nname: review-pr\ndescription: >-\n  Review one pull request as an independent, read-only reviewer and post the record comment\n  merge-check reads. The manual trigger for a cross-agent review.\n---\n\n# Review a Pull Request\n\nRead [the reviewer contract](..\u002F..\u002Fcontracts\u002Freviewer.md) first; it names the protocol sections a review needs. Review in a separate run that wrote none of the change. The deliverable stays read-only; the author makes corrections.\n\n## 1. Pick the PR\n\nUse the PR the user named. Otherwise list the open, non-draft PRs whose `implemented-by:` line does not name you and whose comments hold no record (`reviewed-by:` with `Reviewed at \u003Csha>`) for the current head: `gh pr list --state open --json number,title,isDraft,headRefOid,body`, then `gh pr view \u003Cn> --comments` (`tea` on Gitea). One candidate: review it and say which. Zero or several: ask which PR to review, then stop.\n\n## 2. State the Problem and Your Own Approach\n\nRead the PR description and the issue it closes or addresses. State the problem in one sentence. Before opening the diff, decide how you would solve it: the files you would touch, the shape of the change, and what you would not build. The diff must not anchor you.\n\n## 3. Review\n\nCheck out the PR head detached at `.worktrees\u002F\u003Cagent>-review-pr-\u003Cn>` (`git worktree add --detach .worktrees\u002F\u003Cagent>-review-pr-\u003Cn> \u003Chead-sha>`), never in the author's worktree. When a host launch already started you in that checkout at the head, use it. Read the complete base-to-head diff and the callers, tests, fixtures, and configuration it touches. Compare it with your approach: a difference is a finding only when the PR's choice is worse. Pragmatic, idiomatic, simple yet thorough code beats complex or clever code (the Ponytail ladder). For each finding, try to refute it, then report the failure mechanism, location, minimal correction, and how to verify. On a code PR, run `task verify` in the checkout and record the result verbatim.\n\n## 4. Post the Record\n\nPost one PR comment in the contract grammar (`gh pr comment \u003Cn> --body-file \u003Cfile>`):\n\n```text\nreviewed-by: \u003Cagent> (\u003Cmodel>, \u003Ceffort>)\nReviewed at \u003Chead-sha>\nVerdict: APPROVE | REQUEST CHANGES\n\u003Cfindings, checks run, unavailable evidence, limitations>\n```\n\nName your provider, model as `.agents\u002Freview-policy.json` lists it (for example `opus`), and reasoning effort. Remove the review checkout (`git worktree remove .worktrees\u002F\u003Cagent>-review-pr-\u003Cn>`) once the comment is posted. No sync of yours delivers the record: each checkout keeps its own `.ateam\u002Fstate.json`, and the record reaches the developer when their checkout runs `ateam state sync`. When the launch spec gave you a `return_to`, run `ateam review notify --record \u003Cfile> --return-to \u003Cid> \u003Cn>`: it sends only `review record for PR #\u003Cn> landed at \u003Csha>; run ateam state sync, then ateam state pickup`, or prints the host tool to call, never your findings. End your conclusion with 1–2 lines naming what you skipped or did not check and any residual risk.\n\n## 5. Clear the Merge Check\n\nWhere `Merge check` runs from ateam's `merge-check.yml`, a probe skips it while a code PR has no `reviewed-by:` description line and no passing `Merge check` already stands at its head, whether or not a record exists. GitHub shows a skipped job under its raw `name:` expression, never as `Merge check`, so until the line is written the required check is absent, not red (where the gate runs without that probe, it failed when the PR was marked ready). Once the line exists, or a pass stands at the head, every run judges in full. After either verdict, refresh the check and confirm its result at the commit you reviewed; if you cannot edit the description or rerun the check, say so instead of reporting that it changed.\n\n- After a first `Verdict: REQUEST CHANGES`, add no line and stop: the gate passes only a latest record with exactly one `Verdict: APPROVE` line, so the PR cannot merge, and while it has no line and no pass at its head the probe skips `Merge check`, so the required check stays absent, not red.\n- After `Verdict: APPROVE`, the gate also needs your `reviewed-by: \u003Cagent> (\u003Cmodel>, \u003Ceffort>)` line in the PR description: add it if it is missing (`gh pr view \u003Cn> --json body -q .body`, then `gh pr edit \u003Cn> --body-file \u003Cfile>`). Where `Merge check` runs on the `edited` event, that edit, made after the record comment, runs it at the head.\n- When nothing is edited, because the description already carried your line or because your `Verdict: REQUEST CHANGES` follows an earlier approval at the same head, a comment starts no run and the earlier result stands. Rerun the whole latest run for the head, not `--failed`, which skips a run that passed; the probe and the check read the forge when they run, so the rerun judges your new record: `gh run list --branch \u003Chead-branch> --workflow merge-check.yml --limit 1 --json databaseId,headSha`, confirm its `headSha` is the commit you reviewed, wait for it (`gh run watch \u003Crun> --exit-status || true`), then `gh run rerun \u003Crun>` and `gh run watch \u003Crun> --exit-status`. After a rejection it must fail; an earlier pass is no evidence the rejection was applied. In a repository that runs the gate inside `ci.yml`, rerun that run's merge-check job (`gh run rerun --job \u003Cjob-id>`). On Gitea, rerun it from the Actions page, and say so in your reply.\n\nDo not update the branch to clear it.\n","# Review a Pull Request\n\nRead [the reviewer contract](..\u002F..\u002Fcontracts\u002Freviewer.md) first; it names the protocol sections a review needs. Review in a separate run that wrote none of the change. The deliverable stays read-only; the author makes corrections.\n\n## 1. Pick the PR\n\nUse the PR the user named. Otherwise list the open, non-draft PRs whose `implemented-by:` line does not name you and whose comments hold no record (`reviewed-by:` with `Reviewed at \u003Csha>`) for the current head: `gh pr list --state open --json number,title,isDraft,headRefOid,body`, then `gh pr view \u003Cn> --comments` (`tea` on Gitea). One candidate: review it and say which. Zero or several: ask which PR to review, then stop.\n\n## 2. State the Problem and Your Own Approach\n\nRead the PR description and the issue it closes or addresses. State the problem in one sentence. Before opening the diff, decide how you would solve it: the files you would touch, the shape of the change, and what you would not build. The diff must not anchor you.\n\n## 3. Review\n\nCheck out the PR head detached at `.worktrees\u002F\u003Cagent>-review-pr-\u003Cn>` (`git worktree add --detach .worktrees\u002F\u003Cagent>-review-pr-\u003Cn> \u003Chead-sha>`), never in the author's worktree. When a host launch already started you in that checkout at the head, use it. Read the complete base-to-head diff and the callers, tests, fixtures, and configuration it touches. Compare it with your approach: a difference is a finding only when the PR's choice is worse. Pragmatic, idiomatic, simple yet thorough code beats complex or clever code (the Ponytail ladder). For each finding, try to refute it, then report the failure mechanism, location, minimal correction, and how to verify. On a code PR, run `task verify` in the checkout and record the result verbatim.\n\n## 4. Post the Record\n\nPost one PR comment in the contract grammar (`gh pr comment \u003Cn> --body-file \u003Cfile>`):\n\n```text\nreviewed-by: \u003Cagent> (\u003Cmodel>, \u003Ceffort>)\nReviewed at \u003Chead-sha>\nVerdict: APPROVE | REQUEST CHANGES\n\u003Cfindings, checks run, unavailable evidence, limitations>\n```\n\nName your provider, model as `.agents\u002Freview-policy.json` lists it (for example `opus`), and reasoning effort. Remove the review checkout (`git worktree remove .worktrees\u002F\u003Cagent>-review-pr-\u003Cn>`) once the comment is posted. No sync of yours delivers the record: each checkout keeps its own `.ateam\u002Fstate.json`, and the record reaches the developer when their checkout runs `ateam state sync`. When the launch spec gave you a `return_to`, run `ateam review notify --record \u003Cfile> --return-to \u003Cid> \u003Cn>`: it sends only `review record for PR #\u003Cn> landed at \u003Csha>; run ateam state sync, then ateam state pickup`, or prints the host tool to call, never your findings. End your conclusion with 1–2 lines naming what you skipped or did not check and any residual risk.\n\n## 5. Clear the Merge Check\n\nWhere `Merge check` runs from ateam's `merge-check.yml`, a probe skips it while a code PR has no `reviewed-by:` description line and no passing `Merge check` already stands at its head, whether or not a record exists. GitHub shows a skipped job under its raw `name:` expression, never as `Merge check`, so until the line is written the required check is absent, not red (where the gate runs without that probe, it failed when the PR was marked ready). Once the line exists, or a pass stands at the head, every run judges in full. After either verdict, refresh the check and confirm its result at the commit you reviewed; if you cannot edit the description or rerun the check, say so instead of reporting that it changed.\n\n- After a first `Verdict: REQUEST CHANGES`, add no line and stop: the gate passes only a latest record with exactly one `Verdict: APPROVE` line, so the PR cannot merge, and while it has no line and no pass at its head the probe skips `Merge check`, so the required check stays absent, not red.\n- After `Verdict: APPROVE`, the gate also needs your `reviewed-by: \u003Cagent> (\u003Cmodel>, \u003Ceffort>)` line in the PR description: add it if it is missing (`gh pr view \u003Cn> --json body -q .body`, then `gh pr edit \u003Cn> --body-file \u003Cfile>`). Where `Merge check` runs on the `edited` event, that edit, made after the record comment, runs it at the head.\n- When nothing is edited, because the description already carried your line or because your `Verdict: REQUEST CHANGES` follows an earlier approval at the same head, a comment starts no run and the earlier result stands. Rerun the whole latest run for the head, not `--failed`, which skips a run that passed; the probe and the check read the forge when they run, so the rerun judges your new record: `gh run list --branch \u003Chead-branch> --workflow merge-check.yml --limit 1 --json databaseId,headSha`, confirm its `headSha` is the commit you reviewed, wait for it (`gh run watch \u003Crun> --exit-status || true`), then `gh run rerun \u003Crun>` and `gh run watch \u003Crun> --exit-status`. After a rejection it must fail; an earlier pass is no evidence the rejection was applied. In a repository that runs the gate inside `ci.yml`, rerun that run's merge-check job (`gh run rerun --job \u003Cjob-id>`). On Gitea, rerun it from the Actions page, and say so in your reply.\n\nDo not update the branch to clear it.\n",{"name":5,"description":7},"main","4df44ae877d0c711f769ec6b48b88100dbb267d1",".agents\u002Fskills\u002Freview-pr","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams","https:\u002F\u002Fc360studio.github.io","https:\u002F\u002Fgithub.com\u002FC360Studio","2026-11-11 01:13:46",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add C360Studio\u002Fsemteams --skill review-pr",{"tool":56,"command":57},"bunx","bunx skills add C360Studio\u002Fsemteams --skill review-pr",{"tool":59,"command":60},"pnpm","pnpm dlx skills add C360Studio\u002Fsemteams --skill review-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview-pr\u002FSKILL.md",true,[],[65,88,109,143,150,169],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":38},"01M6NQEE3V8S4HEVMFVFW7SEQ4","store-pattern","Choose the right state management approach for a use case. Decide between component-local state, derived state, runes-based stores, SvelteKit load, or URL state.","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002Fui\u002F.claude\u002Fskills\u002Fstore-pattern\u002FSKILL.md",[],[72,73,74,75,76,32,77,78,79,80,81,82,83,84,85,86,87],"store pattern","store","pattern","URL","load","managed","case","component","local","use","state management","state","sveltekit","choose","decide","management",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":38},"01M6NQE4Z802R8B8PBE23JRR5W","new-component","Step-by-step checklist for adding a new Svelte 5 component with proper patterns, tests, and TypeScript types. Use when creating new UI components.","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002Fui\u002F.claude\u002Fskills\u002Fnew-component\u002FSKILL.md",[],[79,95,96,97,98,99,100,101,81,102,103,104,105,106,107,32,108],"new component","new","svelte","types","patterns","checklist","svelte 5","ui","components","typescript","tests","ui components","with","when",{"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":125,"publishedAt":38},"01M6NQDYRKF89279J9A2D9Q892","backend-integration","Connect the UI to semstreams backend APIs. Covers proxy routing, fetch patterns, SSR considerations, and real-time data. Use when adding new backend integrations or debugging API issues.","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002Fui\u002F.claude\u002Fskills\u002Fbackend-integration\u002FSKILL.md",[115,120],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[126,127,128,96,129,130,131,132,99,81,133,134,135,136,108,102,137,138,139,140,141,142],"backend integration","backend","integration","api endpoint","data","backend integrations","time","fetch","integrations","api","real-time","proxy","issues","routing","connect","debugging","ssr",{"skillNo":144,"name":5,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":38},"01M6NQDW39CHJMCCQZA696N1Y7","Adapter for review-pr.","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview-pr\u002FSKILL.md",[],[21,19,20,149,32,5],"adapter",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":159,"publishedAt":38},"01M6NQD8CX3BCRHN8BRFTVJJ01","query-pattern","Choose the right query access pattern (GraphQL, MCP, NATS Direct) for a use case. Use when designing query APIs, adding new access points, or choosing between gateway types.","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fquery-pattern\u002FSKILL.md",[156],{"categoryNo":157,"categoryName":158,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发",[160,74,161,81,96,108,32,98,78,162,163,85,164,165,166,167,168],"query pattern","query","scenario","nats","direct","access","GraphQL","gateway","MCP",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":38},"01M6NQD73AJADQC2G9005KPNPN","preflight","Adapter for preflight.","https:\u002F\u002Fgithub.com\u002FC360Studio\u002Fsemteams\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fpreflight\u002FSKILL.md",[],[171,32,149]]