[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7136YV7NFBDFNXZ7GKZFKVF":3,"skill-same:01M7136YV7NFBDFNXZ7GKZFKVF":206},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M7136YV7NFBDFNXZ7GKZFKVF","github-desktop-release",null,"Qualify Windows desktop installers in GitHub Actions and promote verified Windows\u002FmacOS assets from one frozen SHA. Use for cloud packaging, installer failures, GitHub Release publication, when a cloud qualification run serves as acceptance evidence for a fix, or when a release gate such as windows-cloud-build-test or release-win-verify fails intermittently; not local packaging or macOS qualification.","EthanYoQ\u002FSkill-hub","EthanYoQ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257484394?v=4","01M70C9QKWR1YS0S7V26DNB18H","Ethan","01M70C9QMER047R5ANZZA6KC2P",11,"MIT","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"github desktop release","github","desktop","release","as","windows","github release","Publication","macos","verified","run","when","acceptance","github actions","local","fix","actions","packaging","qualify","promote","2026-11-10 10:12:30",false,"---\nname: github-desktop-release\ndescription: \"Qualify Windows desktop installers in GitHub Actions and promote verified Windows\u002FmacOS assets from one frozen SHA. Use for cloud packaging, installer failures, GitHub Release publication, when a cloud qualification run serves as acceptance evidence for a fix, or when a release gate such as windows-cloud-build-test or release-win-verify fails intermittently; not local packaging or macOS qualification.\"\n---\n\n# GitHub Desktop Release\n\nTreat a desktop release as a state machine, not a build command. Keep application implementation, platform qualification, artifact identity, and public GitHub Release state as separate evidence boundaries.\n\n`electron-development` owns Electron macOS build and qualification. This Skill may validate a macOS qualification artifact before promotion, but does not take over that platform's build work.\n\n## Pick the smallest justified cloud path\n\nClassify the request before spending runner time. Do not turn a past infrastructure failure into a permanent requirement for every release.\n\n- **Compatibility preflight**: a read-only or non-promotable check that proves each requested platform can receive the frozen source: runner label availability, locked-install viability, expected architecture\u002Fnative binding load, and resolved asset plan. It produces no installer and cannot justify publication.\n- **Standard Windows qualification**: the default for ordinary application-source releases when the Windows installer, upgrade path, Electron\u002FNode ABI, signing policy, and installer configuration are unchanged. It builds one installer and proves core installability.\n- **Deep Windows acceptance**: adds upgrade-data, native-ABI, and project-specific migration\u002Finstaller checks. Use it only when its trigger is present or the user explicitly requests it.\n- **Promotion\u002Freadback**: consumes already-qualified bytes. It never builds, installs, or substitutes an artifact.\n\nFor a multi-platform release, choose between a staged canary and a parallel formal matrix from the release-risk delta. Ask `electron-development` to own macOS preflight and qualification work. A staged canary protects expensive minutes when release infrastructure changed; a parallel matrix protects elapsed time when that infrastructure is already proven.\n\n## Establish scope\n\n1. Read the repository's `AGENTS.md`, domain docs, packaging configuration, workflows, release scripts, and tests. Use CodeGraph first when the project is indexed.\n2. Record the repository, default branch, full source SHA, tag, version, requested platforms\u002Farchitectures, signing policy, expected assets, and authorization boundary.\n3. Keep project facts in a repository release profile, not in this Skill. Read [references\u002Frelease-profile.md](references\u002Frelease-profile.md), then validate the selected profile:\n\n   ```text\n   node \u003Cskill-root>\u002Fscripts\u002Fvalidate-release-profile.mjs --profile \u003Cproject-profile.json>\n   ```\n\n   A project may keep separate committed standard and deep profiles. Select one before qualification and pass the same `profile_path` through qualification and promotion; never alter it to fit a completed run.\n4. If Windows is in scope, run the read-only adapter scan without `-OutputPath`, then read [references\u002Fstack-adapters.md](references\u002Fstack-adapters.md) and the selected adapter:\n\n   ```powershell\n   & \"\u003Cskill-root>\\scripts\\preflight-windows-release.ps1\" -ProjectRoot \"\u003Cproject-root>\"\n   ```\n\n5. If macOS is in scope, require a qualification artifact produced under `electron-development` from the same frozen SHA. Read [references\u002Fmacos-qualification.md](references\u002Fmacos-qualification.md) only to validate the artifact contract used by shared promotion; do not dispatch or own the macOS build\u002Fqualification job from this Skill.\n\nStop at a read-only plan when repository writes, workflow dispatch, tag creation, or Release publication are not authorized.\n\n## Choose the cloud execution strategy\n\nRead [references\u002Fcloud-execution-strategy.md](references\u002Fcloud-execution-strategy.md) before dispatching a qualification matrix, retrying a failed run, or changing release workflows.\n\n- Use a **staged canary** when packaging, native runtime, runner, smoke, evidence, verifier, profile, or promotion infrastructure changed, or the failure class is unresolved.\n- Use a **parallel formal matrix** for an application-only release when those boundaries and the requested runner\u002Ftoolchains have current green evidence.\n- Run platform-neutral source validation once per SHA and bind its receipt to the exact command\u002Ftoolchain. Keep Windows-native and installer acceptance on Windows; do not convert shared gating into missing platform coverage.\n\nCompatibility probes remain non-promotable. A source or contract change requires fresh formal qualifications from the new SHA even when its canaries pass.\n\n## Freeze formal qualification\n\nRead [references\u002Frelease-contract.md](references\u002Frelease-contract.md) and [references\u002Fevidence-contract.md](references\u002Fevidence-contract.md). Before the first release qualification:\n\n1. Freeze the source SHA, tag\u002Fversion, runner labels, application toolchains, workflow identities, selected profile, exact artifact set, acceptance receipts, normalization rules, and promotion inputs.\n2. 在 install、build 或 acceptance 前冻结并 hash contract。Link the immutable contract hash to every platform ledger and run.\n3. Replay real platform receipts through the final consumer when changing an evidence producer\u002Fwriter, receipt verifier, shared promotion consumer, qualification workflow\u002Fadapter, or release-contract schema:\n\n   ```text\n   node \u003Cskill-root>\u002Fscripts\u002Freplay-release-evidence.mjs --profile \u003Cproject-profile.json> --evidence-root \u003Creal-fixtures>\n   ```\n\n4. Use real platform-produced bytes as positive fixtures. Build negative fixtures independently from the verifier. Read [references\u002Freceipt-replay.md](references\u002Freceipt-replay.md). A source-only release may reuse a previously verified adapter; do not make replay a per-release cloud-dispatch blocker.\n5. For first-time Windows infrastructure with no real fixtures, allow at most one non-publishing Windows canary to collect receipts. Freeze those bytes, add them to the replay set, fix locally, and only then start formal qualification. Any missing macOS canary belongs to `electron-development`.\n\nThe formal dispatch gate is complete when the profile and contract are valid, the selected execution strategy's early gates are green, and the receipt semantics are known. No source gate or compatibility canary is a qualification result.\n\n## Qualify Windows artifacts\n\nDispatch Windows qualification only after the release inputs are bound to the frozen SHA and contract meaning, and the early gates required by the selected cloud strategy are green. A low-risk parallel matrix does not acquire an extra serial compatibility canary merely because multiple platforms are requested. Build the installer once, then use those exact bytes for acceptance, hashing, upload, and later promotion. When macOS is also requested, `electron-development` owns that platform's qualification against the same frozen SHA.\n\nFor Windows qualification:\n\n1. Checkout the full frozen SHA with read-only permissions and `persist-credentials: false`.\n2. Verify the runner image and application toolchain against the frozen contract.\n3. 执行 stack 专属的 locked install, then the project build\u002Fpackage command. Preserve a project-required Windows-native test receipt, but avoid re-running a proven same-SHA suite.\n4. 对 installer 做真实安装、launch\u002Fmount, quiet\u002Ferror observation, installed smoke, and quiet uninstall\u002Feject acceptance where the platform\u002Fpackage supports those operations. Keep the bounded quiet window and product-scoped residual checks. Record an unsupported core operation as blocked scope, not silent success.\n5. Record signing or notarization status, validation result, and unsigned\u002Funnotarized distribution impact.\n6. Upload only the exact contract asset set plus contract, ledger, manifest, checksums, required receipts, and sanitized diagnostics.\n\nThe **standard** Windows profile normally contains core receipts such as `install`, `launch`, `quiet-window`, `error-dialogs`, `packaged-smoke`, `uninstall`, and `signing`. It must not silently claim upgrade or native-ABI coverage it did not run.\n\nRequire **deep** Windows acceptance when any of these applies:\n\n- first public qualification for the installer path, or a change to NSIS\u002Felectron-builder configuration, app ID, install scope\u002Fpath, silent parameters, custom installer hooks, signing, update channel, or updater format;\n- a change to persistent-data format, migration, user-data location, or upgrade\u002Fdowngrade behavior;\n- a change to Electron, Node, a release-critical native module, its rebuild process, or its target architecture;\n- an explicit project policy or user request for upgrade\u002Fnative verification.\n\nDeep acceptance adds the project-specific upgrade-data and native-ABI checks, plus any directly affected test. It does not justify deleting the core installer checks or substituting a different platform. Conversely, ordinary source-only changes do not automatically require an upgrade fixture or a separate ABI rebuild test when the relevant packaging boundary is unchanged.\n\nWindows Electron\u002FNSIS qualification must follow [references\u002Felectron-nsis.md](references\u002Felectron-nsis.md). A macOS qualification artifact is an external input owned by `electron-development`; validate it against [references\u002Fmacos-qualification.md](references\u002Fmacos-qualification.md) before promotion. Qualification success proves an Actions artifact, not a public Release.\n\nUse [assets\u002Felectron-nsis-qualification.yml](assets\u002Felectron-nsis-qualification.yml) as the fail-closed Windows qualification starting point (entity `windows`, architecture `x64`). The bundled [assets\u002Fmacos-arm64-qualification.yml](assets\u002Fmacos-arm64-qualification.yml) and [assets\u002Fmacos-x64-qualification.yml](assets\u002Fmacos-x64-qualification.yml) are contract-compatible handoff templates for `electron-development`, one workflow per macOS entity (`macos-arm64`, `macos-x64`); copy each to the path its profile entity names in `qualificationWorkflow`. Using them does not transfer macOS execution ownership to this Skill.\n\nAll three templates freeze the common contract and the entity run ledger through [scripts\u002Ffreeze-release-contract.mjs](scripts\u002Ffreeze-release-contract.mjs) before install, so the evidence carries the identity promotion requires: contract `frozen.qualificationEntities`, ledger and manifest `platform`\u002F`architecture`. Copy that script verbatim to `.release\u002Fscripts\u002F` next to the two promotion scripts. Its `--tag-format` and `--version-file` arguments are project-convention adapters (the templates pass `v{version}` and `package.json`); change or drop them when the project differs.\n\nPromotion is shared infrastructure, not a project adapter. Reuse [scripts\u002Fgithub-desktop-promotion.mjs](scripts\u002Fgithub-desktop-promotion.mjs), [scripts\u002Fvalidate-release-profile.mjs](scripts\u002Fvalidate-release-profile.mjs), and [assets\u002Fgithub-desktop-release-promotion.yml](assets\u002Fgithub-desktop-release-promotion.yml) rather than reimplementing profile validation, artifact selection, same-SHA\u002Fcontract binding, manifest hashing, resume, upload, channel, or readback logic per project. A project-specific workflow wrapper may adapt invocation, but it must preserve the verified consumer contract.\n\nCopy `github-desktop-promotion.mjs`, `validate-release-profile.mjs`, and `freeze-release-contract.mjs` verbatim to the project's `.release\u002Fscripts\u002F`; do not edit them per project. After copying, the project must follow the naming rule the copied validator enforces: every macOS release asset name contains `-mac-\u003Carch>-` for its entity (`-mac-arm64-` for `macos-arm64`, `-mac-x64-` for `macos-x64`), for example `App-mac-arm64-{version}.dmg`. A profile that breaks it is rejected before qualification, and the macOS templates check it again on the built asset names.\n\nRun the shared offline tests after changing those scripts or the qualification templates:\n\n```text\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-github-desktop-promotion.mjs\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-freeze-release-contract.mjs\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-qualification-evidence-e2e.mjs\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-release-tools.mjs\npwsh -NoProfile -File \u003Cskill-root>\u002Fscripts\u002Ftest-workflow-assets.ps1\n```\n\n## Diagnose without cloud trial-and-error\n\nRead [references\u002Ffailure-classification.md](references\u002Ffailure-classification.md) and [references\u002Ffailure-playbook.md](references\u002Ffailure-playbook.md).\n\n1. Classify every failure as `product`, `build`, `acceptance`, `gate-false-positive`, or `promotion` before deciding whether a rebuild is justified.\n2. Preserve the run URL\u002FID, attempt, head SHA, runner\u002Ftoolchain, failing stage, contract, manifest, receipts, and the smallest sanitized log excerpt.\n3. Change one falsifiable hypothesis at a time. For a preflight failure, re-run only that preflight after the fix; for a formal failure, use local or non-promotable replay before another full qualification.\n4. After two consecutive failures in the same stage, stop. Do not start a third run until a unified root cause, ranked alternatives, and local red-to-green replay exist.\n5. Keep binary identity and normalized semantics separate: installer\u002FDMG\u002FZIP\u002Fblockmap bytes use raw SHA-256; eligible UTF-8 text may additionally use newline-canonical SHA-256. Never compare cross-OS text raw hashes as semantic identity.\n\nWhen a fix changes the SHA, cancel in-flight runs for the superseded SHA and forward-audit every remaining stage before dispatching the new formal matrix. Do not discover package-smoke, evidence-finalization, and promotion prerequisites one expensive run at a time. A local promotion-tool failure with unchanged qualified bytes is not a reason to rebuild.\n\nDo not restart a full Windows gate merely because another platform has already exposed a known compatibility blocker. Once the repaired source SHA is ready, every requested platform still receives a clean, same-SHA formal qualification.\n\n## Promote the qualified bytes\n\nRead [references\u002Fgithub-release-state-machine.md](references\u002Fgithub-release-state-machine.md).\n\nBefore downloading large qualification artifacts, run the zero-side-effect local checks in [references\u002Fpromotion-preflight.md](references\u002Fpromotion-preflight.md). A missing archive tool, wrong authenticated account, invalid profile, unwritable output plan, or insufficient disk is a local promotion blocker; repair it and resume from the same immutable run identities without rebuilding.\n\n1. Accept only unique, unexpired qualification artifacts whose workflow, run ID, attempt, head SHA, contract, manifest, and platform all match.\n2. Require every requested platform to qualify the same source SHA. Promotion may download and verify artifacts; it must not install, build, or substitute a same-named artifact.\n3. Pass `qualification_runs_json` as an exact platform mapping of positive integer `runId`, `attempt`, and `artifactId`. Platform keys are qualification entities: `windows`, `macos-arm64`, and `macos-x64`; a generic `macos` key is rejected. The shared script verifies the profile's workflow and artifact name in addition to those immutable identities.\n4. Require every schema-v2 manifest and run ledger to record its `platform` and `architecture` equal to the profile entity and its single declared architecture, and `release-contract.json` to list that entity in `frozen.qualificationEntities`. Require every schema-v2 manifest and run ledger to bind `contractRawBytesSha256` and `profileRawBytesSha256`. `release-contract.json` and `signing.evidencePath` must be members of the exact manifest\u002Fchecksum set; every required platform must carry identical contract\u002Fprofile raw-byte hashes, and the latter must equal the profile file used for promotion.\n5. Verify the exact asset set, raw byte hashes, signing disclosures, tag availability, default-branch ancestry, and existing draft\u002Ftag\u002Fassets in a read-only job. `--repository` is the release repository; `--qualification-repository` optionally names a separate repository that ran qualification (default: the release repository). The contract and ledger `repository` must equal the qualification repository, and publish rejects a verified plan whose qualification repository, release repository, SHA, tag, or version differs.\n   Pass `--release-notes \u003Crepository-relative .md>` to both verify and publish. The notes are required, non-empty, UTF-8 without BOM, at most 64 KiB, and are placed before the generated provenance in the Release body.\n6. Grant `contents: write` only to the final publish job. Resume a partial draft only when its provenance is exact and every already uploaded asset is an exact subset by name, size, state, and GitHub `sha256:` digest; upload only the missing assets. Never overwrite or delete a mismatch.\n7. After the final mutation, perform bounded authoritative readback of tag target, Release state, draft\u002Fprerelease\u002Flatest flags against the profile's release-channel policy, exact assets, uploaded state, platform digests, release notes, signing\u002Fnotarization disclosures, and URL. A verified draft reports `draftVerified: true` and `publicationVerified: false`; only a verified non-draft public state may report publication success.\n\nWorkflow success is not publication success. A missing or unverifiable readback leaves the release incomplete.\n\n### 发布说明怎么写\n\n读回只能证明说明已经挂上去，证明不了说明写得对。说明是给用户看的承诺，写错了用户会按错的行为去用，所以在起草时就按下面三条约束内容：\n\n1. **范围**：从上一个已发布（非草稿）的 tag 到本次发版 SHA。用 `git log \u003C上一个 tag>..\u003C发版 SHA>` 列出合并的 PR，逐个核对，不要凭记忆或沿用上一版草稿。\n2. **每条行为附出处**：写明对应的 PR 号，以及验证该行为的测试名或截图。找不到验证出处的条目，先去验证再写，验证不了就删掉或改成不承诺具体行为的说法。\n3. **数字附测量条件**：性能、体积、时长之类的数字，写明测量条件（机器或 runner、平台、数据规模、样本数）和出处。没有测量出处的数字不写。\n\n起草完、发布前，按 PR 实际改动逐条复核一遍说明，确认每条描述的都是该 PR 真正的行为。\n\n## Report evidence states\n\nReport `mode`, `qualification tier`, `frozen inputs`, `preflight by platform`, `source-validation receipt`, `qualification by platform`, `failure classification`, `signing\u002Fnotarization`, `promotion identity`, `authoritative readback`, `unverified\u002Fblocked`, and `next action`.\n\nUse only these completion claims:\n\n- `build-success`: packaging command produced an artifact.\n- `qualification-success`: a platform artifact passed its frozen acceptance contract.\n- `promotion-success`: qualified bytes were promoted without rebuilding.\n- `publication-success`: authoritative GitHub readback matches the full release contract and the Release is not a draft.\n","# GitHub Desktop Release\n\nTreat a desktop release as a state machine, not a build command. Keep application implementation, platform qualification, artifact identity, and public GitHub Release state as separate evidence boundaries.\n\n`electron-development` owns Electron macOS build and qualification. This Skill may validate a macOS qualification artifact before promotion, but does not take over that platform's build work.\n\n## Pick the smallest justified cloud path\n\nClassify the request before spending runner time. Do not turn a past infrastructure failure into a permanent requirement for every release.\n\n- **Compatibility preflight**: a read-only or non-promotable check that proves each requested platform can receive the frozen source: runner label availability, locked-install viability, expected architecture\u002Fnative binding load, and resolved asset plan. It produces no installer and cannot justify publication.\n- **Standard Windows qualification**: the default for ordinary application-source releases when the Windows installer, upgrade path, Electron\u002FNode ABI, signing policy, and installer configuration are unchanged. It builds one installer and proves core installability.\n- **Deep Windows acceptance**: adds upgrade-data, native-ABI, and project-specific migration\u002Finstaller checks. Use it only when its trigger is present or the user explicitly requests it.\n- **Promotion\u002Freadback**: consumes already-qualified bytes. It never builds, installs, or substitutes an artifact.\n\nFor a multi-platform release, choose between a staged canary and a parallel formal matrix from the release-risk delta. Ask `electron-development` to own macOS preflight and qualification work. A staged canary protects expensive minutes when release infrastructure changed; a parallel matrix protects elapsed time when that infrastructure is already proven.\n\n## Establish scope\n\n1. Read the repository's `AGENTS.md`, domain docs, packaging configuration, workflows, release scripts, and tests. Use CodeGraph first when the project is indexed.\n2. Record the repository, default branch, full source SHA, tag, version, requested platforms\u002Farchitectures, signing policy, expected assets, and authorization boundary.\n3. Keep project facts in a repository release profile, not in this Skill. Read [references\u002Frelease-profile.md](references\u002Frelease-profile.md), then validate the selected profile:\n\n   ```text\n   node \u003Cskill-root>\u002Fscripts\u002Fvalidate-release-profile.mjs --profile \u003Cproject-profile.json>\n   ```\n\n   A project may keep separate committed standard and deep profiles. Select one before qualification and pass the same `profile_path` through qualification and promotion; never alter it to fit a completed run.\n4. If Windows is in scope, run the read-only adapter scan without `-OutputPath`, then read [references\u002Fstack-adapters.md](references\u002Fstack-adapters.md) and the selected adapter:\n\n   ```powershell\n   & \"\u003Cskill-root>\\scripts\\preflight-windows-release.ps1\" -ProjectRoot \"\u003Cproject-root>\"\n   ```\n\n5. If macOS is in scope, require a qualification artifact produced under `electron-development` from the same frozen SHA. Read [references\u002Fmacos-qualification.md](references\u002Fmacos-qualification.md) only to validate the artifact contract used by shared promotion; do not dispatch or own the macOS build\u002Fqualification job from this Skill.\n\nStop at a read-only plan when repository writes, workflow dispatch, tag creation, or Release publication are not authorized.\n\n## Choose the cloud execution strategy\n\nRead [references\u002Fcloud-execution-strategy.md](references\u002Fcloud-execution-strategy.md) before dispatching a qualification matrix, retrying a failed run, or changing release workflows.\n\n- Use a **staged canary** when packaging, native runtime, runner, smoke, evidence, verifier, profile, or promotion infrastructure changed, or the failure class is unresolved.\n- Use a **parallel formal matrix** for an application-only release when those boundaries and the requested runner\u002Ftoolchains have current green evidence.\n- Run platform-neutral source validation once per SHA and bind its receipt to the exact command\u002Ftoolchain. Keep Windows-native and installer acceptance on Windows; do not convert shared gating into missing platform coverage.\n\nCompatibility probes remain non-promotable. A source or contract change requires fresh formal qualifications from the new SHA even when its canaries pass.\n\n## Freeze formal qualification\n\nRead [references\u002Frelease-contract.md](references\u002Frelease-contract.md) and [references\u002Fevidence-contract.md](references\u002Fevidence-contract.md). Before the first release qualification:\n\n1. Freeze the source SHA, tag\u002Fversion, runner labels, application toolchains, workflow identities, selected profile, exact artifact set, acceptance receipts, normalization rules, and promotion inputs.\n2. 在 install、build 或 acceptance 前冻结并 hash contract。Link the immutable contract hash to every platform ledger and run.\n3. Replay real platform receipts through the final consumer when changing an evidence producer\u002Fwriter, receipt verifier, shared promotion consumer, qualification workflow\u002Fadapter, or release-contract schema:\n\n   ```text\n   node \u003Cskill-root>\u002Fscripts\u002Freplay-release-evidence.mjs --profile \u003Cproject-profile.json> --evidence-root \u003Creal-fixtures>\n   ```\n\n4. Use real platform-produced bytes as positive fixtures. Build negative fixtures independently from the verifier. Read [references\u002Freceipt-replay.md](references\u002Freceipt-replay.md). A source-only release may reuse a previously verified adapter; do not make replay a per-release cloud-dispatch blocker.\n5. For first-time Windows infrastructure with no real fixtures, allow at most one non-publishing Windows canary to collect receipts. Freeze those bytes, add them to the replay set, fix locally, and only then start formal qualification. Any missing macOS canary belongs to `electron-development`.\n\nThe formal dispatch gate is complete when the profile and contract are valid, the selected execution strategy's early gates are green, and the receipt semantics are known. No source gate or compatibility canary is a qualification result.\n\n## Qualify Windows artifacts\n\nDispatch Windows qualification only after the release inputs are bound to the frozen SHA and contract meaning, and the early gates required by the selected cloud strategy are green. A low-risk parallel matrix does not acquire an extra serial compatibility canary merely because multiple platforms are requested. Build the installer once, then use those exact bytes for acceptance, hashing, upload, and later promotion. When macOS is also requested, `electron-development` owns that platform's qualification against the same frozen SHA.\n\nFor Windows qualification:\n\n1. Checkout the full frozen SHA with read-only permissions and `persist-credentials: false`.\n2. Verify the runner image and application toolchain against the frozen contract.\n3. 执行 stack 专属的 locked install, then the project build\u002Fpackage command. Preserve a project-required Windows-native test receipt, but avoid re-running a proven same-SHA suite.\n4. 对 installer 做真实安装、launch\u002Fmount, quiet\u002Ferror observation, installed smoke, and quiet uninstall\u002Feject acceptance where the platform\u002Fpackage supports those operations. Keep the bounded quiet window and product-scoped residual checks. Record an unsupported core operation as blocked scope, not silent success.\n5. Record signing or notarization status, validation result, and unsigned\u002Funnotarized distribution impact.\n6. Upload only the exact contract asset set plus contract, ledger, manifest, checksums, required receipts, and sanitized diagnostics.\n\nThe **standard** Windows profile normally contains core receipts such as `install`, `launch`, `quiet-window`, `error-dialogs`, `packaged-smoke`, `uninstall`, and `signing`. It must not silently claim upgrade or native-ABI coverage it did not run.\n\nRequire **deep** Windows acceptance when any of these applies:\n\n- first public qualification for the installer path, or a change to NSIS\u002Felectron-builder configuration, app ID, install scope\u002Fpath, silent parameters, custom installer hooks, signing, update channel, or updater format;\n- a change to persistent-data format, migration, user-data location, or upgrade\u002Fdowngrade behavior;\n- a change to Electron, Node, a release-critical native module, its rebuild process, or its target architecture;\n- an explicit project policy or user request for upgrade\u002Fnative verification.\n\nDeep acceptance adds the project-specific upgrade-data and native-ABI checks, plus any directly affected test. It does not justify deleting the core installer checks or substituting a different platform. Conversely, ordinary source-only changes do not automatically require an upgrade fixture or a separate ABI rebuild test when the relevant packaging boundary is unchanged.\n\nWindows Electron\u002FNSIS qualification must follow [references\u002Felectron-nsis.md](references\u002Felectron-nsis.md). A macOS qualification artifact is an external input owned by `electron-development`; validate it against [references\u002Fmacos-qualification.md](references\u002Fmacos-qualification.md) before promotion. Qualification success proves an Actions artifact, not a public Release.\n\nUse [assets\u002Felectron-nsis-qualification.yml](assets\u002Felectron-nsis-qualification.yml) as the fail-closed Windows qualification starting point (entity `windows`, architecture `x64`). The bundled [assets\u002Fmacos-arm64-qualification.yml](assets\u002Fmacos-arm64-qualification.yml) and [assets\u002Fmacos-x64-qualification.yml](assets\u002Fmacos-x64-qualification.yml) are contract-compatible handoff templates for `electron-development`, one workflow per macOS entity (`macos-arm64`, `macos-x64`); copy each to the path its profile entity names in `qualificationWorkflow`. Using them does not transfer macOS execution ownership to this Skill.\n\nAll three templates freeze the common contract and the entity run ledger through [scripts\u002Ffreeze-release-contract.mjs](scripts\u002Ffreeze-release-contract.mjs) before install, so the evidence carries the identity promotion requires: contract `frozen.qualificationEntities`, ledger and manifest `platform`\u002F`architecture`. Copy that script verbatim to `.release\u002Fscripts\u002F` next to the two promotion scripts. Its `--tag-format` and `--version-file` arguments are project-convention adapters (the templates pass `v{version}` and `package.json`); change or drop them when the project differs.\n\nPromotion is shared infrastructure, not a project adapter. Reuse [scripts\u002Fgithub-desktop-promotion.mjs](scripts\u002Fgithub-desktop-promotion.mjs), [scripts\u002Fvalidate-release-profile.mjs](scripts\u002Fvalidate-release-profile.mjs), and [assets\u002Fgithub-desktop-release-promotion.yml](assets\u002Fgithub-desktop-release-promotion.yml) rather than reimplementing profile validation, artifact selection, same-SHA\u002Fcontract binding, manifest hashing, resume, upload, channel, or readback logic per project. A project-specific workflow wrapper may adapt invocation, but it must preserve the verified consumer contract.\n\nCopy `github-desktop-promotion.mjs`, `validate-release-profile.mjs`, and `freeze-release-contract.mjs` verbatim to the project's `.release\u002Fscripts\u002F`; do not edit them per project. After copying, the project must follow the naming rule the copied validator enforces: every macOS release asset name contains `-mac-\u003Carch>-` for its entity (`-mac-arm64-` for `macos-arm64`, `-mac-x64-` for `macos-x64`), for example `App-mac-arm64-{version}.dmg`. A profile that breaks it is rejected before qualification, and the macOS templates check it again on the built asset names.\n\nRun the shared offline tests after changing those scripts or the qualification templates:\n\n```text\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-github-desktop-promotion.mjs\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-freeze-release-contract.mjs\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-qualification-evidence-e2e.mjs\nnode \u003Cskill-root>\u002Fscripts\u002Ftest-release-tools.mjs\npwsh -NoProfile -File \u003Cskill-root>\u002Fscripts\u002Ftest-workflow-assets.ps1\n```\n\n## Diagnose without cloud trial-and-error\n\nRead [references\u002Ffailure-classification.md](references\u002Ffailure-classification.md) and [references\u002Ffailure-playbook.md](references\u002Ffailure-playbook.md).\n\n1. Classify every failure as `product`, `build`, `acceptance`, `gate-false-positive`, or `promotion` before deciding whether a rebuild is justified.\n2. Preserve the run URL\u002FID, attempt, head SHA, runner\u002Ftoolchain, failing stage, contract, manifest, receipts, and the smallest sanitized log excerpt.\n3. Change one falsifiable hypothesis at a time. For a preflight failure, re-run only that preflight after the fix; for a formal failure, use local or non-promotable replay before another full qualification.\n4. After two consecutive failures in the same stage, stop. Do not start a third run until a unified root cause, ranked alternatives, and local red-to-green replay exist.\n5. Keep binary identity and normalized semantics separate: installer\u002FDMG\u002FZIP\u002Fblockmap bytes use raw SHA-256; eligible UTF-8 text may additionally use newline-canonical SHA-256. Never compare cross-OS text raw hashes as semantic identity.\n\nWhen a fix changes the SHA, cancel in-flight runs for the superseded SHA and forward-audit every remaining stage before dispatching the new formal matrix. Do not discover package-smoke, evidence-finalization, and promotion prerequisites one expensive run at a time. A local promotion-tool failure with unchanged qualified bytes is not a reason to rebuild.\n\nDo not restart a full Windows gate merely because another platform has already exposed a known compatibility blocker. Once the repaired source SHA is ready, every requested platform still receives a clean, same-SHA formal qualification.\n\n## Promote the qualified bytes\n\nRead [references\u002Fgithub-release-state-machine.md](references\u002Fgithub-release-state-machine.md).\n\nBefore downloading large qualification artifacts, run the zero-side-effect local checks in [references\u002Fpromotion-preflight.md](references\u002Fpromotion-preflight.md). A missing archive tool, wrong authenticated account, invalid profile, unwritable output plan, or insufficient disk is a local promotion blocker; repair it and resume from the same immutable run identities without rebuilding.\n\n1. Accept only unique, unexpired qualification artifacts whose workflow, run ID, attempt, head SHA, contract, manifest, and platform all match.\n2. Require every requested platform to qualify the same source SHA. Promotion may download and verify artifacts; it must not install, build, or substitute a same-named artifact.\n3. Pass `qualification_runs_json` as an exact platform mapping of positive integer `runId`, `attempt`, and `artifactId`. Platform keys are qualification entities: `windows`, `macos-arm64`, and `macos-x64`; a generic `macos` key is rejected. The shared script verifies the profile's workflow and artifact name in addition to those immutable identities.\n4. Require every schema-v2 manifest and run ledger to record its `platform` and `architecture` equal to the profile entity and its single declared architecture, and `release-contract.json` to list that entity in `frozen.qualificationEntities`. Require every schema-v2 manifest and run ledger to bind `contractRawBytesSha256` and `profileRawBytesSha256`. `release-contract.json` and `signing.evidencePath` must be members of the exact manifest\u002Fchecksum set; every required platform must carry identical contract\u002Fprofile raw-byte hashes, and the latter must equal the profile file used for promotion.\n5. Verify the exact asset set, raw byte hashes, signing disclosures, tag availability, default-branch ancestry, and existing draft\u002Ftag\u002Fassets in a read-only job. `--repository` is the release repository; `--qualification-repository` optionally names a separate repository that ran qualification (default: the release repository). The contract and ledger `repository` must equal the qualification repository, and publish rejects a verified plan whose qualification repository, release repository, SHA, tag, or version differs.\n   Pass `--release-notes \u003Crepository-relative .md>` to both verify and publish. The notes are required, non-empty, UTF-8 without BOM, at most 64 KiB, and are placed before the generated provenance in the Release body.\n6. Grant `contents: write` only to the final publish job. Resume a partial draft only when its provenance is exact and every already uploaded asset is an exact subset by name, size, state, and GitHub `sha256:` digest; upload only the missing assets. Never overwrite or delete a mismatch.\n7. After the final mutation, perform bounded authoritative readback of tag target, Release state, draft\u002Fprerelease\u002Flatest flags against the profile's release-channel policy, exact assets, uploaded state, platform digests, release notes, signing\u002Fnotarization disclosures, and URL. A verified draft reports `draftVerified: true` and `publicationVerified: false`; only a verified non-draft public state may report publication success.\n\nWorkflow success is not publication success. A missing or unverifiable readback leaves the release incomplete.\n\n### 发布说明怎么写\n\n读回只能证明说明已经挂上去，证明不了说明写得对。说明是给用户看的承诺，写错了用户会按错的行为去用，所以在起草时就按下面三条约束内容：\n\n1. **范围**：从上一个已发布（非草稿）的 tag 到本次发版 SHA。用 `git log \u003C上一个 tag>..\u003C发版 SHA>` 列出合并的 PR，逐个核对，不要凭记忆或沿用上一版草稿。\n2. **每条行为附出处**：写明对应的 PR 号，以及验证该行为的测试名或截图。找不到验证出处的条目，先去验证再写，验证不了就删掉或改成不承诺具体行为的说法。\n3. **数字附测量条件**：性能、体积、时长之类的数字，写明测量条件（机器或 runner、平台、数据规模、样本数）和出处。没有测量出处的数字不写。\n\n起草完、发布前，按 PR 实际改动逐条复核一遍说明，确认每条描述的都是该 PR 真正的行为。\n\n## Report evidence states\n\nReport `mode`, `qualification tier`, `frozen inputs`, `preflight by platform`, `source-validation receipt`, `qualification by platform`, `failure classification`, `signing\u002Fnotarization`, `promotion identity`, `authoritative readback`, `unverified\u002Fblocked`, and `next action`.\n\nUse only these completion claims:\n\n- `build-success`: packaging command produced an artifact.\n- `qualification-success`: a platform artifact passed its frozen acceptance contract.\n- `promotion-success`: qualified bytes were promoted without rebuilding.\n- `publication-success`: authoritative GitHub readback matches the full release contract and the Release is not a draft.\n",{"name":5,"description":7},"mine","1e7390741dffd3d5041fca4ebc056071ee3ba137","skills\u002F01-agent-engineering\u002Fgithub-desktop-release",5,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub","https:\u002F\u002Fgithub.com\u002FEthanYoQ","www.orz.md","Part Marketer, Part AI Explorer.","2026-11-07 14:52:29",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add EthanYoQ\u002FSkill-hub --skill github-desktop-release",{"tool":64,"command":65},"bunx","bunx skills add EthanYoQ\u002FSkill-hub --skill github-desktop-release",{"tool":67,"command":68},"pnpm","pnpm dlx skills add EthanYoQ\u002FSkill-hub --skill github-desktop-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002FSKILL.md",true,[72,78,84,88,92,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,162,166,170,174,178,182,186,190,194,198,202],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml","REFERENCE","参考文档",339,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fagents\u002Fopenai.yaml",{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"assets\u002Felectron-nsis-qualification.yml","ASSET","资产文件",41291,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fassets\u002Felectron-nsis-qualification.yml",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"assets\u002Fgithub-desktop-release-promotion.yml",5985,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fassets\u002Fgithub-desktop-release-promotion.yml",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":90,"sourceHtmlUrl":91},"assets\u002Fmacos-arm64-qualification.yml",20129,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fassets\u002Fmacos-arm64-qualification.yml",{"path":93,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":94,"sourceHtmlUrl":95},"assets\u002Fmacos-x64-qualification.yml",20124,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fassets\u002Fmacos-x64-qualification.yml",{"path":97,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":98,"sourceHtmlUrl":99},"assets\u002Frelease-profile.schema.json",4967,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fassets\u002Frelease-profile.schema.json",{"path":101,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":102,"sourceHtmlUrl":103},"evals\u002Fevals.json",9521,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fevals\u002Fevals.json",{"path":105,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fagent-orchestration.md",1445,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fagent-orchestration.md",{"path":109,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fcloud-execution-strategy.md",6483,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fcloud-execution-strategy.md",{"path":113,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Felectron-nsis.md",7683,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Felectron-nsis.md",{"path":117,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fevidence-contract.md",9430,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fevidence-contract.md",{"path":121,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Ffailure-classification.md",2349,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Ffailure-classification.md",{"path":125,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":126,"sourceHtmlUrl":127},"references\u002Ffailure-playbook.md",4614,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Ffailure-playbook.md",{"path":129,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":130,"sourceHtmlUrl":131},"references\u002Fgithub-release-state-machine.md",7277,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fgithub-release-state-machine.md",{"path":133,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":134,"sourceHtmlUrl":135},"references\u002Fmacos-qualification.md",3422,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fmacos-qualification.md",{"path":137,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":138,"sourceHtmlUrl":139},"references\u002Fpromotion-preflight.md",2738,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fpromotion-preflight.md",{"path":141,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":142,"sourceHtmlUrl":143},"references\u002Freceipt-replay.md",2722,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Freceipt-replay.md",{"path":145,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":146,"sourceHtmlUrl":147},"references\u002Frelease-contract.md",5009,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Frelease-contract.md",{"path":149,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":150,"sourceHtmlUrl":151},"references\u002Frelease-profile.md",6321,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Frelease-profile.md",{"path":153,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":154,"sourceHtmlUrl":155},"references\u002Fstack-adapters.md",4503,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Freferences\u002Fstack-adapters.md",{"path":157,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":160,"sourceHtmlUrl":161},"scripts\u002Fclassify-actions-failure.mjs","SCRIPT","脚本",2640,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Fclassify-actions-failure.mjs",{"path":163,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":164,"sourceHtmlUrl":165},"scripts\u002Ffreeze-release-contract.mjs",8339,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ffreeze-release-contract.mjs",{"path":167,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":168,"sourceHtmlUrl":169},"scripts\u002Fgithub-desktop-promotion.mjs",43544,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Fgithub-desktop-promotion.mjs",{"path":171,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":172,"sourceHtmlUrl":173},"scripts\u002Fpreflight-windows-release.ps1",15774,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Fpreflight-windows-release.ps1",{"path":175,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":176,"sourceHtmlUrl":177},"scripts\u002Freplay-release-evidence.mjs",5855,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Freplay-release-evidence.mjs",{"path":179,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":180,"sourceHtmlUrl":181},"scripts\u002Ftest-freeze-release-contract.mjs",12202,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ftest-freeze-release-contract.mjs",{"path":183,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":184,"sourceHtmlUrl":185},"scripts\u002Ftest-github-desktop-promotion.mjs",24551,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ftest-github-desktop-promotion.mjs",{"path":187,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":188,"sourceHtmlUrl":189},"scripts\u002Ftest-preflight.ps1",12677,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ftest-preflight.ps1",{"path":191,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":192,"sourceHtmlUrl":193},"scripts\u002Ftest-qualification-evidence-e2e.mjs",20465,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ftest-qualification-evidence-e2e.mjs",{"path":195,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":196,"sourceHtmlUrl":197},"scripts\u002Ftest-release-tools.mjs",11332,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ftest-release-tools.mjs",{"path":199,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":200,"sourceHtmlUrl":201},"scripts\u002Ftest-workflow-assets.ps1",34998,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Ftest-workflow-assets.ps1",{"path":203,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":204,"sourceHtmlUrl":205},"scripts\u002Fvalidate-release-profile.mjs",12351,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F01-agent-engineering\u002Fgithub-desktop-release\u002Fscripts\u002Fvalidate-release-profile.mjs",[207,233,264,288,305,320],{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":214,"publishedAt":44},"01M713CBDSYARG4PXFXK2R2NNN","xhs-pharma-social-listening","Run evidence-disciplined Xiaohongshu social listening for foreign pharma employee pain points. Use when the user asks to collect and analyze notes\u002Fcomments about pharma companies, aliases, roles, compliance, medical affairs, or AI topics, then produce a cited and scored sampled-insight report. Includes independent-evidence counting, MediaCrawler batch collection, and CAPTCHA\u002F461 fallback to Agent Reach\u002FOpenCLI.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fxhs-pharma-social-listening\u002FSKILL.md",[213],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[215,216,217,218,219,220,35,221,222,223,224,34,225,226,227,228,229,230,231,232],"social","xhs pharma social listening","social listening","xhs","medical","counting","collection","batch","analyze","notes","opencli","fallback","captcha","agent reach","evidence","for","collect","produce",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":245,"publishedAt":44},"01M713C8Q76ZP0WXXBRAFKS6EE","healthcare-phi-compliance","Protected Health Information (PHI) and Personally Identifiable Information (PII) compliance patterns for healthcare applications. Covers data classification, access control, audit trails, encryption, and common leak vectors. Use when code touches PHI or PII in a healthcare system, or when auditing access control, audit trails, or leak vectors.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-phi-compliance\u002FSKILL.md",[239,240],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":241,"categoryName":242,"taxonomyType":243,"taxonomyTypeDesc":244},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[246,247,248,249,250,251,252,253,35,254,255,256,257,258,259,260,230,261,262,263],"healthcare","phi","compliance","healthcare phi compliance","pii","compliance patterns","information","access","encryption","code","common","audit","data","patterns","Access Control","system","applications","Auditing Access Control",{"skillNo":265,"name":266,"nameZh":6,"description":267,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":268,"categories":269,"keywords":271,"publishedAt":44},"01M713C5R2GE43X45T2K75TB76","healthcare-eval-harness","Patient safety evaluation harness for healthcare application deployments. Automated test suites for CDSS accuracy, PHI exposure, clinical workflow integrity, and integration compliance. Blocks deployments on safety failures. Use when a healthcare deployment must be gated on patient-safety tests for CDSS accuracy, PHI exposure, and workflow integrity.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-eval-harness\u002FSKILL.md",[270],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[246,272,273,274,275,276,277,35,278,279,280,281,247,230,282,283,284,285,286,287],"eval","harness","healthcare eval harness","eval harness","clinical","patient","workflow","Evaluation","Safety","integrity","deployment","accuracy","tests","deployments","use","super",{"skillNo":289,"name":290,"nameZh":6,"description":291,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":292,"categories":293,"keywords":295,"publishedAt":44},"01M713C2J17S91VYR7A8M696VR","healthcare-emr-patterns","EMR\u002FEHR development patterns for healthcare applications. Clinical safety, encounter workflows, prescription generation, clinical decision support integration, and accessibility-first UI for medical data entry. Use when building EMR or EHR features such as encounter workflows, prescription generation, or clinical data entry UI.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-emr-patterns\u002FSKILL.md",[294],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[246,296,259,297,298,219,276,299,35,300,301,302,280,258,303,28,304,230,262,286],"EMR","healthcare emr patterns","decision","workflows","support","clinical decision support","features","ui","development",{"skillNo":306,"name":307,"nameZh":6,"description":308,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":309,"categories":310,"keywords":312,"publishedAt":44},"01M713BZERTXV0N8X6SW9DDVWZ","healthcare-cdss-patterns","Clinical Decision Support System (CDSS) development patterns. Drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), alert severity classification, and integration into EMR workflows. Use when building clinical decision support — drug interaction checks, dose validation, clinical scoring, or alert severity.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-cdss-patterns\u002FSKILL.md",[311],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[246,259,313,298,276,296,299,35,314,315,300,301,316,304,261,317,286,318,287,319],"healthcare cdss patterns","scoring","interaction","severity","classification","alert","decision support",{"skillNo":321,"name":322,"nameZh":6,"description":323,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":324,"categories":325,"keywords":327,"publishedAt":44},"01M713BVK3PQR7V4ZKYGMWMXJD","dxy-task-clarify","用户的请求含糊、缺背景、缺资料说明、缺读者或用途时使用。先用少量带选项的追问把任务问清楚，写成任务卡，用户确认后再执行。尤其适用于医生、科研人员和药企各岗位的工作，例如「帮我分析一下这些数据」「帮我准备明天的拜访」「写个总结」「做个 PPT」「回一下这封邮件」「整理一下会议纪要」「整理一下这些文献」「帮我准备下周的讲课」「写个病例汇报」「帮我写个提示词」。用户说「先问我」「帮我理清需求」「我不知道怎么描述」「我不会问 AI」时也使用。用途、资料、读者都已说清的请求，纯翻译，以及写代码、改代码，不使用。","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fdxy-task-clarify\u002FSKILL.md",[326],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[328,329,330,331,332,333,334,335],"clarify","dxy task clarify","task","pptx","整理","翻译","数据","总结"]