[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72VQZTWRZDF7AMVADTNGV2K":3,"skill-same:01M72VQZTWRZDF7AMVADTNGV2K":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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":33,"ownerDescription":6,"updatedAt":34,"install":35,"resources":47},"01M72VQZTWRZDF7AMVADTNGV2K","release-publishing",null,"Use when preparing, testing, tagging, or publishing beta and stable releases of the Meteor agent-skills plugin for Codex and Claude Code.","meteor\u002Fagent-skills","meteor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F789528?v=4","01M72VQVFCJ72XHP7ZKS3774NA","Meteor","01M72VQVG5VZ0X5VCQYM0MCK1Q",11,"MIT","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frelease-publishing\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: release-publishing\ndescription: Use when preparing, testing, tagging, or publishing beta and stable releases of the Meteor agent-skills plugin for Codex and Claude Code.\nmetadata:\n  internal: true\n---\n\n# Publish Meteor agent skills\n\nPrepare one catalog version for Codex, Claude Code, GitHub release assets, and\ndirect skill installation. Read [`RELEASING.md`](..\u002F..\u002F..\u002FRELEASING.md) before\nchanging release state.\n\n## Choose the release stage\n\n| Stage | Repository visibility | Version and tag | Purpose |\n|---|---|---|---|\n| Working-tree test | Private or public | No new tag required | Validate local manifests and behavior. |\n| Public beta | Public | `X.Y.Z-beta.N` and `vX.Y.Z-beta.N` | Test the exact remote installation path. |\n| Stable | Public | `X.Y.Z` and `vX.Y.Z` | Publish the accepted catalog and submit it to directories. |\n\nA GitHub repository does not need to be public for local working-tree tests.\nIt must be public before testing installation through\n`meteor\u002Fagent-skills@\u003Ctag>` or submitting to public directories.\n\nCatalog releases may be published independently for skill additions, corrections,\nevaluation improvements, packaging changes, or other catalog maintenance. For an\nindependent release, follow the normal beta or stable flow without requiring a Meteor\nrelease audit, compatibility mapping, or Meteor artifact gates. Apply the coordinated\nrules below only when the catalog is intentionally paired with a Meteor release.\n\n## Preserve the release branch\n\nFor a beta or a catalog paired with a Meteor beta\u002FRC, publish from the existing\nrelease PR branch. Record its repository, branch, PR and freshly fetched head SHA.\nKeep preparation, audits and post-publication records on that same branch\u002FPR.\nLeave the PR open and the branch unmerged after publication; do not merge, close\nor delete either project's release branch\u002FPR just to publish or finish cleanup.\nPublication approval is not merge approval. A merge requires a separate explicit\nuser request, including during stable promotion.\n\nUse the clean reviewed PR head as the beta candidate, not `main` or a synthetic\nPR merge commit. Green CI must cover that exact content; default-branch CI alone\nis insufficient. For stable publication, retain the reviewed, merged default-branch\ncandidate gate, but ask for merge authorization if it is not already granted.\nFor beta\u002FRC, if the PR is already merged\u002Fclosed or its branch is missing, ask which\nbranch to use; do not silently create a replacement PR or rewrite history.\n\n## Coordinate with a Meteor release\n\nWhen Meteor's release process requests a paired catalog, record the Meteor version,\nrelease commit, Agent Skills audit report, audited Agent Skills revision, publish\ncommit, and exact catalog tag. Catalog semver is independent from Meteor semver. Do\nnot derive one version from the other.\n\n| Meteor stage | Agent Skills stage |\n|---|---|\n| Beta | Public beta, `X.Y.Z-beta.N` |\n| RC | Public beta, `X.Y.Z-beta.N` |\n| Official | Stable, `X.Y.Z` |\n\nThe documented catalog stages are public beta and stable, so a Meteor RC remains paired\nwith an Agent Skills beta unless the repository adopts a separate RC policy.\n\nBefore preparing the catalog version:\n\n1. Require a completed release audit against the final Meteor release commit and a\n   clean Agent Skills candidate from the freshly fetched release PR branch for\n   beta\u002FRC, or default branch for stable. If an earlier audit used uncommitted\n   documentation or a different Agent Skills revision, require a new incremental\n   report and preserve the earlier committed record.\n2. Confirm every authorized release-blocking finding is implemented and its affected\n   manual cases pass.\n3. Confirm CI is green on the candidate commit. Beta\u002FRC PRs remain open; only\n   stable publication requires the authorized merge into the default branch.\n4. Select the catalog version explicitly. A user may approve a new beta snapshot with\n   no distributable skill change when the purpose is to record tested compatibility\n   with a Meteor candidate.\n\nLoad this publishing skill from the same clean checkout and revision selected for the\nrelease candidate. Record that commit as `AGENT_SKILLS_CANDIDATE_SHA`. If the selected\nremote branch advances before version preparation, report the drift and explicitly\nchoose whether to keep the reviewed candidate or update it. Updating requires a new\naudit of every affected catalog claim and another validation pass.\n\nPublish the Agent Skills tag only after the paired Meteor packages, tool builds, and\nbootstrap tarballs are live. A stable catalog must be based on a tagged beta that\npassed local checks, remote installation tests, and affected behavioral cases. If its\nguidance changed afterward, publish and test another beta before stable promotion.\n\nAfter publication, record the exact Meteor-to-catalog mapping and live GitHub release\nURL in the release handoff. Request Meteor's dedicated Agent Skills changelog section\nonly when this is a newly published paired tag and its remote installation tests pass;\notherwise the section must be omitted, not filled with `N\u002FA`. Independent catalog\nreleases never create that Meteor changelog section.\n\nUse the concise client-neutral changelog shape in `RELEASING.md`: the verified\nrelease link and generic `npx skills add 'meteor\u002Fagent-skills#\u003Ctag>'`\ncommand must use the same exact tag. Test that command remotely and compare\ninstalled files with the tag. Link to the official\n[Meteor Agent Skills guide](https:\u002F\u002Fdocs.meteor.com\u002Fai\u002Fagent-skills); keep\nclient-specific commands in the catalog's release notes. Put the current\nSkills CLI Node requirement beside the short command and keep the older-Node\ninstaller pin in separate compatibility guidance.\n\n## Prepare the version\n\nInspect the worktree first and preserve unrelated changes. Set the same global\nversion in both plugin manifests with:\n\n```bash\npnpm release:bump 1.0.0-beta.1\n```\n\nUse a stable version only after its beta has passed local and tagged remote\ninstallation tests:\n\n```bash\npnpm release:bump 1.0.0\n```\n\nDo not add versions to `package.json` or individual `SKILL.md` files. The\nrepository tag identifies the complete catalog snapshot.\n\n## Verify\n\nRun the checks in `RELEASING.md`. The tag workflow rejects a tag that does not\nmatch both manifests. Before publishing guidance for an official Meteor\nrelease, complete [stable consolidation](references\u002Fverification-and-handoff.md#stable-consolidation).\nFor every release, use the same reference for complete-plugin packaging,\nisolated installation\u002Fupdate checks and post-publication report retention.\n\nTest from the working tree before making the repository public. After pushing a\nbeta tag, repeat the Codex, Claude Code, and individual-skill installations\nfrom that exact tag.\n\nFor changes to release decisions, run the affected\n[acceptance cases](references\u002Feval-cases.md) in read-only fresh conversations.\n\n## Publish\n\nTreat preparation and publication as separate operations.\n\n- A request to prepare a release authorizes local version changes and checks.\n- A request to publish a release authorizes the requested commit, tag, push,\n  and GitHub release flow on the selected branch, not a PR merge or closure.\n- Marketplace submissions require the publisher account, approved listing\n  details, and explicit authorization for that submission.\n\nWhen publication is authorized, commit the verified preparation on the selected\nbranch and resolve it as `AGENT_SKILLS_PUBLISH_SHA`. Show the diff from\n`$AGENT_SKILLS_CANDIDATE_SHA` and require it to contain only the approved maintenance\nand deterministic release preparation. Run the release checks from that clean exact\ncommit, tag that commit with the matching `v` prefix, and push the tag. Do not load the\npublishing skill from one revision and tag another.\n\nFor beta\u002FRC, push preparation to the existing PR and confirm its head SHA and CI\nbefore tagging. Add verified installation links and results to that same PR branch\nafter publication. These documentation commits do not move the published tag.\n\nThe GitHub workflow validates the version again, builds skill ZIPs, and creates the\nGitHub release. Beta tags are marked as prereleases. Confirm the release succeeds\nbefore testing remote installation.\n\nDo not reuse or move a published tag. Prepare a new beta number or patch\nversion when a tagged release needs a correction.\n","# Publish Meteor agent skills\n\nPrepare one catalog version for Codex, Claude Code, GitHub release assets, and\ndirect skill installation. Read [`RELEASING.md`](..\u002F..\u002F..\u002FRELEASING.md) before\nchanging release state.\n\n## Choose the release stage\n\n| Stage | Repository visibility | Version and tag | Purpose |\n|---|---|---|---|\n| Working-tree test | Private or public | No new tag required | Validate local manifests and behavior. |\n| Public beta | Public | `X.Y.Z-beta.N` and `vX.Y.Z-beta.N` | Test the exact remote installation path. |\n| Stable | Public | `X.Y.Z` and `vX.Y.Z` | Publish the accepted catalog and submit it to directories. |\n\nA GitHub repository does not need to be public for local working-tree tests.\nIt must be public before testing installation through\n`meteor\u002Fagent-skills@\u003Ctag>` or submitting to public directories.\n\nCatalog releases may be published independently for skill additions, corrections,\nevaluation improvements, packaging changes, or other catalog maintenance. For an\nindependent release, follow the normal beta or stable flow without requiring a Meteor\nrelease audit, compatibility mapping, or Meteor artifact gates. Apply the coordinated\nrules below only when the catalog is intentionally paired with a Meteor release.\n\n## Preserve the release branch\n\nFor a beta or a catalog paired with a Meteor beta\u002FRC, publish from the existing\nrelease PR branch. Record its repository, branch, PR and freshly fetched head SHA.\nKeep preparation, audits and post-publication records on that same branch\u002FPR.\nLeave the PR open and the branch unmerged after publication; do not merge, close\nor delete either project's release branch\u002FPR just to publish or finish cleanup.\nPublication approval is not merge approval. A merge requires a separate explicit\nuser request, including during stable promotion.\n\nUse the clean reviewed PR head as the beta candidate, not `main` or a synthetic\nPR merge commit. Green CI must cover that exact content; default-branch CI alone\nis insufficient. For stable publication, retain the reviewed, merged default-branch\ncandidate gate, but ask for merge authorization if it is not already granted.\nFor beta\u002FRC, if the PR is already merged\u002Fclosed or its branch is missing, ask which\nbranch to use; do not silently create a replacement PR or rewrite history.\n\n## Coordinate with a Meteor release\n\nWhen Meteor's release process requests a paired catalog, record the Meteor version,\nrelease commit, Agent Skills audit report, audited Agent Skills revision, publish\ncommit, and exact catalog tag. Catalog semver is independent from Meteor semver. Do\nnot derive one version from the other.\n\n| Meteor stage | Agent Skills stage |\n|---|---|\n| Beta | Public beta, `X.Y.Z-beta.N` |\n| RC | Public beta, `X.Y.Z-beta.N` |\n| Official | Stable, `X.Y.Z` |\n\nThe documented catalog stages are public beta and stable, so a Meteor RC remains paired\nwith an Agent Skills beta unless the repository adopts a separate RC policy.\n\nBefore preparing the catalog version:\n\n1. Require a completed release audit against the final Meteor release commit and a\n   clean Agent Skills candidate from the freshly fetched release PR branch for\n   beta\u002FRC, or default branch for stable. If an earlier audit used uncommitted\n   documentation or a different Agent Skills revision, require a new incremental\n   report and preserve the earlier committed record.\n2. Confirm every authorized release-blocking finding is implemented and its affected\n   manual cases pass.\n3. Confirm CI is green on the candidate commit. Beta\u002FRC PRs remain open; only\n   stable publication requires the authorized merge into the default branch.\n4. Select the catalog version explicitly. A user may approve a new beta snapshot with\n   no distributable skill change when the purpose is to record tested compatibility\n   with a Meteor candidate.\n\nLoad this publishing skill from the same clean checkout and revision selected for the\nrelease candidate. Record that commit as `AGENT_SKILLS_CANDIDATE_SHA`. If the selected\nremote branch advances before version preparation, report the drift and explicitly\nchoose whether to keep the reviewed candidate or update it. Updating requires a new\naudit of every affected catalog claim and another validation pass.\n\nPublish the Agent Skills tag only after the paired Meteor packages, tool builds, and\nbootstrap tarballs are live. A stable catalog must be based on a tagged beta that\npassed local checks, remote installation tests, and affected behavioral cases. If its\nguidance changed afterward, publish and test another beta before stable promotion.\n\nAfter publication, record the exact Meteor-to-catalog mapping and live GitHub release\nURL in the release handoff. Request Meteor's dedicated Agent Skills changelog section\nonly when this is a newly published paired tag and its remote installation tests pass;\notherwise the section must be omitted, not filled with `N\u002FA`. Independent catalog\nreleases never create that Meteor changelog section.\n\nUse the concise client-neutral changelog shape in `RELEASING.md`: the verified\nrelease link and generic `npx skills add 'meteor\u002Fagent-skills#\u003Ctag>'`\ncommand must use the same exact tag. Test that command remotely and compare\ninstalled files with the tag. Link to the official\n[Meteor Agent Skills guide](https:\u002F\u002Fdocs.meteor.com\u002Fai\u002Fagent-skills); keep\nclient-specific commands in the catalog's release notes. Put the current\nSkills CLI Node requirement beside the short command and keep the older-Node\ninstaller pin in separate compatibility guidance.\n\n## Prepare the version\n\nInspect the worktree first and preserve unrelated changes. Set the same global\nversion in both plugin manifests with:\n\n```bash\npnpm release:bump 1.0.0-beta.1\n```\n\nUse a stable version only after its beta has passed local and tagged remote\ninstallation tests:\n\n```bash\npnpm release:bump 1.0.0\n```\n\nDo not add versions to `package.json` or individual `SKILL.md` files. The\nrepository tag identifies the complete catalog snapshot.\n\n## Verify\n\nRun the checks in `RELEASING.md`. The tag workflow rejects a tag that does not\nmatch both manifests. Before publishing guidance for an official Meteor\nrelease, complete [stable consolidation](references\u002Fverification-and-handoff.md#stable-consolidation).\nFor every release, use the same reference for complete-plugin packaging,\nisolated installation\u002Fupdate checks and post-publication report retention.\n\nTest from the working tree before making the repository public. After pushing a\nbeta tag, repeat the Codex, Claude Code, and individual-skill installations\nfrom that exact tag.\n\nFor changes to release decisions, run the affected\n[acceptance cases](references\u002Feval-cases.md) in read-only fresh conversations.\n\n## Publish\n\nTreat preparation and publication as separate operations.\n\n- A request to prepare a release authorizes local version changes and checks.\n- A request to publish a release authorizes the requested commit, tag, push,\n  and GitHub release flow on the selected branch, not a PR merge or closure.\n- Marketplace submissions require the publisher account, approved listing\n  details, and explicit authorization for that submission.\n\nWhen publication is authorized, commit the verified preparation on the selected\nbranch and resolve it as `AGENT_SKILLS_PUBLISH_SHA`. Show the diff from\n`$AGENT_SKILLS_CANDIDATE_SHA` and require it to contain only the approved maintenance\nand deterministic release preparation. Run the release checks from that clean exact\ncommit, tag that commit with the matching `v` prefix, and push the tag. Do not load the\npublishing skill from one revision and tag another.\n\nFor beta\u002FRC, push preparation to the existing PR and confirm its head SHA and CI\nbefore tagging. Add verified installation links and results to that same PR branch\nafter publication. These documentation commits do not move the published tag.\n\nThe GitHub workflow validates the version again, builds skill ZIPs, and creates the\nGitHub release. Beta tags are marked as prereleases. Confirm the release succeeds\nbefore testing remote installation.\n\nDo not reuse or move a published tag. Prepare a new beta number or patch\nversion when a tagged release needs a correction.\n",{"name":5,"metadata":24,"description":7},{"internal":25},true,"main","0b022e17f4fcd7753440de79bd512603cf832de3",".github\u002Fskills\u002Frelease-publishing",3,"https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills","https:\u002F\u002Fdocs.meteor.com\u002F","https:\u002F\u002Fgithub.com\u002Fmeteor","https:\u002F\u002Fmeteor.com\u002F","2026-11-12 03:34:42",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":25},[37,40,43],{"tool":38,"command":39},"npx","npx skills add meteor\u002Fagent-skills --skill release-publishing",{"tool":41,"command":42},"bunx","bunx skills add meteor\u002Fagent-skills --skill release-publishing",{"tool":44,"command":45},"pnpm","pnpm dlx skills add meteor\u002Fagent-skills --skill release-publishing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frelease-publishing\u002FSKILL.md",[48,54,58],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Feval-cases.md","REFERENCE","参考文档",7597,"https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frelease-publishing\u002Freferences\u002Feval-cases.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Fverification-and-handoff.md",6072,"https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frelease-publishing\u002Freferences\u002Fverification-and-handoff.md",{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"scripts\u002Fplugin-version.mjs","SCRIPT","脚本",1920,"https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frelease-publishing\u002Fscripts\u002Fplugin-version.mjs",[65,72,79,86,93,100],{"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":19},"01M72VTT678CAVGTRHSCCZMNSN","migrate-to-rspack","Use when migrating an existing Meteor app to Rspack (Meteor 3.4+), or upgrading Rspack 1 to 2 on Meteor 3.6. Triggers on nested imports, mainModule entry points, server-only apps, replacing fourseven:scss \u002F meteor\u002Fless \u002F coffeescript \u002F jorgenvatle:vite \u002F zodern:melte with loaders, Svelte\u002FTypeScript preprocessing or Lingui SWC plugin failures after upgrade, CommonJS default-import interop, module.exports in client graphs, Node built-ins in browser code, _build \u002F build-assets \u002F build-chunks, .meteorignore hiding handoff files, dynamic chunks under ROOT_URL, meteor.modules for CSS\u002FHTML, resolve.symlinks or resolve.alias migration, automatic dependency updates and immutable CI\u002FDocker builds. Use this skill when the user asks about migration compatibility or a build plugin's Rspack replacement. For new-app setup and rspack.config.js helpers, use meteor-modern-build-stack instead.","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmigrate-to-rspack\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M72VTMKP4FEEE8KPTBW0TS0Y","migrate-to-meteor-3","Use when migrating a Meteor 2.x application to Meteor 3.x. Triggers on callAsync, *Async Mongo, removed Fibers, implicit-global ReferenceError, lost Blaze reactivity, a publish function returning a Promise, a scheduler dropping a Promise, a read API receiving update modifiers, async allow\u002Fdeny, an Iron Router controller not running, \"Method stub took too long\", Atmosphere resolution, Express 5 WebApp handlers, lost async context, rawCollection callbacks, TypeScript declaration failures during upgrades, useTracker, and useSubscribe. Use this skill when the user asks about upgrading Meteor, async caller propagation, iterators with await, or replacing and forking packages. Standalone declarations and type-checking belong to meteor-typescript.","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmigrate-to-meteor-3\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M72VTEG9AB229C97SRKZ2FFG","meteor-typescript","Use when setting up or repairing Meteor application declarations, TypeScript configuration, JavaScript IntelliSense, or local and CI type-checking. Triggers on meteor types, meteor\u002F* imports resolving to any, missing declarations, duplicate Meteor identifiers, zodern:types, @types\u002Fmeteor, .meteor\u002Ftypes, tsconfig.json, jsconfig.json, and tsc --noEmit in a Meteor app. Use this skill when choosing or migrating declaration providers without changing the app's runtime or bundler. For a Meteor 2-to-3 runtime migration use migrate-to-meteor-3 first; for SWC\u002FRspack compilation use meteor-modern-build-stack or migrate-to-rspack. General TypeScript language questions and Atmosphere declaration publishing are outside this app scope.","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmeteor-typescript\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M72VT9PART27QBM306JC3PGN","meteor-testing","Use when setting up, designing, writing, or repairing tests and test harnesses in a Meteor 3 app. Triggers on meteortesting:mocha, --driver-package, TEST_WATCH, TEST_BROWSER_DRIVER, MOCHA_GREP, meteor.testModule, focused tests, .only, Meteor.server.method_handlers, Meteor.server.publish_handlers, DDP.connect, --full-app integration mode, sinon, async test signatures, Playwright\u002FCypress E2E. Use this skill when the user asks about test runners, asks about testing publications, or asks about Jest vs Mocha in Meteor. For a failing, hanging, or flaky test whose failing layer or root cause is unknown, use meteor-debugging before changing the test or app.","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmeteor-testing\u002FSKILL.md",[],[],{"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":99,"publishedAt":19},"01M72VT4X6FMW8YDG4GNR8FKNJ","meteor-security","Use when auditing or hardening a Meteor 3 application. Triggers on missing check() on method arguments, missing this.userId guards on publications, browser-policy CSP, DDPRateLimiter rules, oauth-encryption via Accounts.config oauthSecretKey, audit-argument-checks, allow\u002Fdeny legacy patterns, BrowserPolicy.content.disallowInlineScripts, BrowserPolicy.framing.disallow. Use this skill when the user asks about hardening, asks about a security review, or asks about CSP for a third-party script (Stripe, Google Maps, fonts).","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmeteor-security\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":19},"01M72VSY34AX3TF3AF68E5M4K9","meteor-react","Use when building or debugging React interfaces in Meteor 3: meteor create --react, createRoot, JSX or TSX entry points, Rspack React detection, Fast Refresh, react-meteor-data, useTracker, useSubscribe, useFind, withTracker, Suspense, and Tracker.withComputation. Triggers on isLoading being treated as a boolean, useFind receiving fetch(), stale closure inputs, duplicate tracker side effects, unstable Suspense keys, lost reactivity after await, state reset after refresh, or React tests leaking computations. Use this skill when the user asks about a React skeleton, React Compiler, React-specific rspack.config rules, reactive data hooks, or classic versus Suspense integration. Route general bundler configuration to meteor-modern-build-stack and Meteor 2 upgrades to migrate-to-meteor-3.","https:\u002F\u002Fgithub.com\u002Fmeteor\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmeteor-react\u002FSKILL.md",[],[]]