[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQBZ7G3PF00VG223BAX2RB":3,"skill-same:01M6JQBZ7G3PF00VG223BAX2RB":80},{"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":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6JQBZ7G3PF00VG223BAX2RB","release-management",null,"Cut and publish software releases right-sized to the project — semver decisions, changelogs, tagging, automated version bumps (release-please, changesets, semantic-release), publishing gates, npm\u002FPyPI\u002Fcontainer registry publishing, pre-release channels, monorepo versioning. Triggers: cut a release, release this, publish to npm, publish to PyPI, publish this package, version bump, what version should this be, semver, changelog, tag a release, release notes, GitHub release, prerelease, release automation, release PR. Deploy-time safety → deployment-checklist; commit\u002FPR hygiene → git-workflow.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-management\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],"release","release management","management","software","workflow","cut","please","project","changesets","time","releases","bump","monorepo","versioning","Safety","publish","changelog","release notes","notes","commit","2026-11-10 10:12:30",false,"---\nname: release-management\ndescription: \"Cut and publish software releases right-sized to the project — semver decisions, changelogs, tagging, automated version bumps (release-please, changesets, semantic-release), publishing gates, npm\u002FPyPI\u002Fcontainer registry publishing, pre-release channels, monorepo versioning. Triggers: cut a release, release this, publish to npm, publish to PyPI, publish this package, version bump, what version should this be, semver, changelog, tag a release, release notes, GitHub release, prerelease, release automation, release PR. Deploy-time safety → deployment-checklist; commit\u002FPR hygiene → git-workflow.\"\n---\n\n# Release Management\n\nReleasing turns committed work into a versioned, consumable artifact — a tag, a package, an image — with a truthful version number and a record of what changed. It is not deploying (that's `deployment-checklist`): a release can exist without a deploy, and vice versa.\n\n## ⛔ The Iron Law\n\n**Never publish without a fresh verification gate — and never impose more release process than the project warrants.**\n\nRegistry publishes are effectively irreversible: a version number, once published, is burned even if you yank it, and whatever shipped inside it is already on users' machines. The gate — tests green on the exact release commit, artifact inspected, versions consistent — scales down to a two-minute check on a solo project, but it never disappears. Ceremony scales with the project; the gate doesn't.\n\n## Scope boundary: \"is it safe to ship?\" is not a release question\n\nDeploy safety — migrations, downtime, rollback readiness, whether today is the\nday — belongs to `deployment-checklist`, with `rollback-strategy` for the\nreversal plan. A release produces the artifact; the deploy decides whether it\nruns in production, and the two are asked about in the same breath constantly.\n\nWhen the question is about deploying rather than versioning, name the owning\nskill and hand off **without** answering in release terms as well. Semver,\nchangelogs, tagging, and registry publishing are not a useful partial answer to\n\"we have two pending migrations and it's Friday\" — they are this skill's\nvocabulary applied to a question that didn't ask for it, and they bury the part\nthat mattered.\n\n## Step 1: Detect Existing Conventions — Never Assume Greenfield\n\nBefore proposing anything, find what the project already does:\n\n- **Release config**: `.changeset\u002F`, `release-please-config.json`, `.releaserc*` \u002F `release` key in package.json, `cliff.toml`, `.goreleaser.yml`\n- **Docs**: `RELEASING.md`, release sections in `CONTRIBUTING.md`\n- **CI**: publish\u002Frelease jobs in workflow files (tag triggers, `npm publish`, `twine upload`)\n- **History**: `git tag --list` (scheme and cadence), `CHANGELOG.md` format, commit-message style\n\nIf conventions exist, follow them for this release; propose improvements as a separate change. An org's release process usually encodes constraints you can't see from the repo.\n\n## Step 2: Right-Size the Process\n\n| Tier | Signals | Process |\n|---|---|---|\n| **Solo \u002F personal** | One maintainer, few users, irregular cadence | Manual: bump version, changelog entry (or `gh release create --generate-notes`), annotated tag, GitHub release. **No automation tooling.** |\n| **Team \u002F published package** | Multiple contributors, external consumers, regular cadence | Conventional commits feeding **one** automation tool (release-please \u002F changesets \u002F semantic-release), generated changelog, publish gate as a CI stage |\n| **Org \u002F platform \u002F monorepo** | Many packages, coordinated versions, compliance needs | Release PRs, protected release branches, provenance \u002F trusted publishing, pre-release channels, coordinated monorepo versioning |\n\nUnder-processing breaks consumers; over-processing kills a small project's momentum. State which tier applies and why. **Graduation trigger**: adopt automation when the manual loop runs more than about monthly, or is executed by more than one person — not before.\n\n**The table is how you choose, not what you deliver.** Name the tier, then work in\nthat tier only. Walking a solo maintainer through release trains, protected release\nbranches, and provenance infrastructure — even as context, even as \"what you'd do\nlater\" — is the over-processing the Iron Law forbids, and it buries the four steps\nthey actually need. The graduation trigger is what replaces the tour: one line on\nwhat would move them up, not a preview of the tier above.\n\n## Step 3: Decide the Version\n\n- **Something with consumers of a versioned contract (library, CLI, API)** → SemVer: breaking → MAJOR, feature → MINOR, fix → PATCH. Pre-1.0, MINOR is the breaking-change lever — and don't promise 1.0 stability until you mean it.\n- **A deployed app or service nobody installs by version** → CalVer or a build number is fine; don't cargo-cult SemVer where there is no consumer contract.\n- The version lives in **one source of truth**; every other occurrence (manifests, generated files) is stamped from it. Grep for the old version before tagging — drift here is the classic broken release.\n- Never inflate (\"bump minor to be safe\"): the version is communication to consumers, not marketing. Inflating it lies about compatibility.\n\n## Step 4: Prepare the Release\n\n- **Changelog** from commits, in [Keep a Changelog](https:\u002F\u002Fkeepachangelog.com\u002F) form. Conventional commits map mechanically: `feat` → Added, `fix` → Fixed, behavior change → Changed, `feat!` \u002F `BREAKING CHANGE:` → MAJOR.\n- **Release notes ≠ changelog**: notes lead with highlights and breaking changes plus their upgrade steps — what a consumer must know before upgrading, not a commit list.\n- Bump the source-of-truth version, regenerate anything stamped from it, and settle the changelog — promote `[Unreleased]` if the file is hand-maintained; if a tool generates it, don't hand-curate alongside (a generated changelog plus a hand-written `[Unreleased]` is how the two silently diverge — the tool prepends and never folds). There, fix the commit subject, not the file.\n\n## Step 5: Gate, Then Publish\n\nRun the gate on the **exact commit being released** (including the version-bump commit):\n\n1. Clean working tree, correct branch — `git status`.\n2. Tests and build green **on this commit**, not \"they passed yesterday on main\".\n3. Inspect the artifact users will get: `npm pack --dry-run` \u002F `python -m build` + `twine check` \u002F image build — check the file list, not just the exit code.\n4. Version consistency: manifest(s), changelog heading, and the tag you're about to create all agree.\n\nThen, in order: annotated tag (`vX.Y.Z`) → publish → **post-publish smoke test** (install the *published* artifact in a clean directory and exercise it) → GitHub release with the notes. If the smoke test fails, the fix is a new patch version — which is exactly why the gate runs first.\n\n## Step 6: Automate What Repeats (Tier 2+)\n\nPick **one** tool — they solve the same problem and fight each other:\n\n- **release-please** — release PRs that accumulate changes; GitHub-centric; good monorepo support; a human merge is the final gate.\n- **changesets** — contributors declare intent per change; the standard for JS\u002FTS monorepos with independent package versions.\n- **semantic-release** — fully automated publish on merge; no human gate, so the CI gate must be airtight.\n\nSelection detail, trusted publishing\u002Fprovenance, pre-release channels and dist-tags, monorepo fixed-vs-independent versioning, and hotfix\u002Fbackport flows: [references\u002Frelease-tooling.md](references\u002Frelease-tooling.md).\n\n## Rationalizations to Reject\n\n| Excuse | Reality |\n|---|---|\n| \"It's a one-line fix — publish now, run tests after\" | Published versions can't be overwritten. Start the tests, prep in parallel, publish when green; if consumers truly can't wait, publish to a `next` dist-tag, not `latest`. |\n| \"Small project — tags and changelogs are overkill\" | The lightweight tier costs minutes and buys bisect, rollback, and consumer trust. Skipping versioning is not right-sizing. |\n| \"Let's set up semantic-release\" (solo repo, three releases a year) | Below regular cadence, automation costs more than it saves. Right-sizing cuts both ways. |\n| \"Tests passed yesterday on main\" | The gate runs on the exact release commit — the version bump and changelog commit included. |\n| \"We'll fix the notes after publishing\" | Notes and changelog are part of the artifact; consumers read them at upgrade time, which is now. |\n| \"They asked about shipping, so some release guidance is still useful\" | They asked about deploy safety. Versioning advice alongside it reads as the answer and displaces the migration and rollback questions that actually decide it. Hand off and stop. |\n\n## Red Flags — Stop and Correct Course\n\n- Publishing from a dirty tree, an unpushed branch, or a commit CI never saw.\n- The manifest, the tag, and the changelog disagree on the version.\n- Two release-automation tools active in the same repo.\n- \"Misc fixes and improvements\" as the entire changelog entry for a consumer-facing release.\n- A release procedure that requires hand-editing generated files.\n\n## Cross-Skill References\n\n- `git-workflow` — the conventional commits that feed automated bumps\n- `cicd-pipeline` — implementing the publish gate as a pipeline stage\n- `deployment-checklist` \u002F `rollback-strategy` — deploying the released artifact safely\n- `project-documentation` — changelog upkeep between releases\n- `verification-before-completion` — the evidence discipline the gate is built on\n","# Release Management\n\nReleasing turns committed work into a versioned, consumable artifact — a tag, a package, an image — with a truthful version number and a record of what changed. It is not deploying (that's `deployment-checklist`): a release can exist without a deploy, and vice versa.\n\n## ⛔ The Iron Law\n\n**Never publish without a fresh verification gate — and never impose more release process than the project warrants.**\n\nRegistry publishes are effectively irreversible: a version number, once published, is burned even if you yank it, and whatever shipped inside it is already on users' machines. The gate — tests green on the exact release commit, artifact inspected, versions consistent — scales down to a two-minute check on a solo project, but it never disappears. Ceremony scales with the project; the gate doesn't.\n\n## Scope boundary: \"is it safe to ship?\" is not a release question\n\nDeploy safety — migrations, downtime, rollback readiness, whether today is the\nday — belongs to `deployment-checklist`, with `rollback-strategy` for the\nreversal plan. A release produces the artifact; the deploy decides whether it\nruns in production, and the two are asked about in the same breath constantly.\n\nWhen the question is about deploying rather than versioning, name the owning\nskill and hand off **without** answering in release terms as well. Semver,\nchangelogs, tagging, and registry publishing are not a useful partial answer to\n\"we have two pending migrations and it's Friday\" — they are this skill's\nvocabulary applied to a question that didn't ask for it, and they bury the part\nthat mattered.\n\n## Step 1: Detect Existing Conventions — Never Assume Greenfield\n\nBefore proposing anything, find what the project already does:\n\n- **Release config**: `.changeset\u002F`, `release-please-config.json`, `.releaserc*` \u002F `release` key in package.json, `cliff.toml`, `.goreleaser.yml`\n- **Docs**: `RELEASING.md`, release sections in `CONTRIBUTING.md`\n- **CI**: publish\u002Frelease jobs in workflow files (tag triggers, `npm publish`, `twine upload`)\n- **History**: `git tag --list` (scheme and cadence), `CHANGELOG.md` format, commit-message style\n\nIf conventions exist, follow them for this release; propose improvements as a separate change. An org's release process usually encodes constraints you can't see from the repo.\n\n## Step 2: Right-Size the Process\n\n| Tier | Signals | Process |\n|---|---|---|\n| **Solo \u002F personal** | One maintainer, few users, irregular cadence | Manual: bump version, changelog entry (or `gh release create --generate-notes`), annotated tag, GitHub release. **No automation tooling.** |\n| **Team \u002F published package** | Multiple contributors, external consumers, regular cadence | Conventional commits feeding **one** automation tool (release-please \u002F changesets \u002F semantic-release), generated changelog, publish gate as a CI stage |\n| **Org \u002F platform \u002F monorepo** | Many packages, coordinated versions, compliance needs | Release PRs, protected release branches, provenance \u002F trusted publishing, pre-release channels, coordinated monorepo versioning |\n\nUnder-processing breaks consumers; over-processing kills a small project's momentum. State which tier applies and why. **Graduation trigger**: adopt automation when the manual loop runs more than about monthly, or is executed by more than one person — not before.\n\n**The table is how you choose, not what you deliver.** Name the tier, then work in\nthat tier only. Walking a solo maintainer through release trains, protected release\nbranches, and provenance infrastructure — even as context, even as \"what you'd do\nlater\" — is the over-processing the Iron Law forbids, and it buries the four steps\nthey actually need. The graduation trigger is what replaces the tour: one line on\nwhat would move them up, not a preview of the tier above.\n\n## Step 3: Decide the Version\n\n- **Something with consumers of a versioned contract (library, CLI, API)** → SemVer: breaking → MAJOR, feature → MINOR, fix → PATCH. Pre-1.0, MINOR is the breaking-change lever — and don't promise 1.0 stability until you mean it.\n- **A deployed app or service nobody installs by version** → CalVer or a build number is fine; don't cargo-cult SemVer where there is no consumer contract.\n- The version lives in **one source of truth**; every other occurrence (manifests, generated files) is stamped from it. Grep for the old version before tagging — drift here is the classic broken release.\n- Never inflate (\"bump minor to be safe\"): the version is communication to consumers, not marketing. Inflating it lies about compatibility.\n\n## Step 4: Prepare the Release\n\n- **Changelog** from commits, in [Keep a Changelog](https:\u002F\u002Fkeepachangelog.com\u002F) form. Conventional commits map mechanically: `feat` → Added, `fix` → Fixed, behavior change → Changed, `feat!` \u002F `BREAKING CHANGE:` → MAJOR.\n- **Release notes ≠ changelog**: notes lead with highlights and breaking changes plus their upgrade steps — what a consumer must know before upgrading, not a commit list.\n- Bump the source-of-truth version, regenerate anything stamped from it, and settle the changelog — promote `[Unreleased]` if the file is hand-maintained; if a tool generates it, don't hand-curate alongside (a generated changelog plus a hand-written `[Unreleased]` is how the two silently diverge — the tool prepends and never folds). There, fix the commit subject, not the file.\n\n## Step 5: Gate, Then Publish\n\nRun the gate on the **exact commit being released** (including the version-bump commit):\n\n1. Clean working tree, correct branch — `git status`.\n2. Tests and build green **on this commit**, not \"they passed yesterday on main\".\n3. Inspect the artifact users will get: `npm pack --dry-run` \u002F `python -m build` + `twine check` \u002F image build — check the file list, not just the exit code.\n4. Version consistency: manifest(s), changelog heading, and the tag you're about to create all agree.\n\nThen, in order: annotated tag (`vX.Y.Z`) → publish → **post-publish smoke test** (install the *published* artifact in a clean directory and exercise it) → GitHub release with the notes. If the smoke test fails, the fix is a new patch version — which is exactly why the gate runs first.\n\n## Step 6: Automate What Repeats (Tier 2+)\n\nPick **one** tool — they solve the same problem and fight each other:\n\n- **release-please** — release PRs that accumulate changes; GitHub-centric; good monorepo support; a human merge is the final gate.\n- **changesets** — contributors declare intent per change; the standard for JS\u002FTS monorepos with independent package versions.\n- **semantic-release** — fully automated publish on merge; no human gate, so the CI gate must be airtight.\n\nSelection detail, trusted publishing\u002Fprovenance, pre-release channels and dist-tags, monorepo fixed-vs-independent versioning, and hotfix\u002Fbackport flows: [references\u002Frelease-tooling.md](references\u002Frelease-tooling.md).\n\n## Rationalizations to Reject\n\n| Excuse | Reality |\n|---|---|\n| \"It's a one-line fix — publish now, run tests after\" | Published versions can't be overwritten. Start the tests, prep in parallel, publish when green; if consumers truly can't wait, publish to a `next` dist-tag, not `latest`. |\n| \"Small project — tags and changelogs are overkill\" | The lightweight tier costs minutes and buys bisect, rollback, and consumer trust. Skipping versioning is not right-sizing. |\n| \"Let's set up semantic-release\" (solo repo, three releases a year) | Below regular cadence, automation costs more than it saves. Right-sizing cuts both ways. |\n| \"Tests passed yesterday on main\" | The gate runs on the exact release commit — the version bump and changelog commit included. |\n| \"We'll fix the notes after publishing\" | Notes and changelog are part of the artifact; consumers read them at upgrade time, which is now. |\n| \"They asked about shipping, so some release guidance is still useful\" | They asked about deploy safety. Versioning advice alongside it reads as the answer and displaces the migration and rollback questions that actually decide it. Hand off and stop. |\n\n## Red Flags — Stop and Correct Course\n\n- Publishing from a dirty tree, an unpushed branch, or a commit CI never saw.\n- The manifest, the tag, and the changelog disagree on the version.\n- Two release-automation tools active in the same repo.\n- \"Misc fixes and improvements\" as the entire changelog entry for a consumer-facing release.\n- A release procedure that requires hand-editing generated files.\n\n## Cross-Skill References\n\n- `git-workflow` — the conventional commits that feed automated bumps\n- `cicd-pipeline` — implementing the publish gate as a pipeline stage\n- `deployment-checklist` \u002F `rollback-strategy` — deploying the released artifact safely\n- `project-documentation` — changelog upkeep between releases\n- `verification-before-completion` — the evidence discipline the gate is built on\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","skills\u002Frelease-management","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill release-management",{"tool":62,"command":63},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill release-management",{"tool":65,"command":66},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill release-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-management\u002FSKILL.md",true,[70,76],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"evals\u002Fevals.json","REFERENCE","参考文档",4754,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-management\u002Fevals\u002Fevals.json",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Frelease-tooling.md",5792,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-management\u002Freferences\u002Frelease-tooling.md",[81,123,149,170,203,232],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":102,"publishedAt":44},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[87,90,93,94,99],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":100,"categoryName":101,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000040","财务",[103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","triggers","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":44},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[129],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[131,31,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,115,148],"working agreement","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":44},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[155],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[157,158,159,160,161,162,103,28,133,43,163,164,136,165,140,166,24,167,168,169],"verification","verification before completion","brief","ready","fix","claim","text","route","message","merge","git","act","ship",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":183,"publishedAt":44},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[176,179,180],{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":181,"categoryName":182,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000032","设计师",[184,185,186,187,188,189,190,191,192,193,194,195,138,196,197,198,199,200,201,202],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":213,"publishedAt":44},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[209,210],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":211,"categoryName":212,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000030","开发工程师",[214,215,216,217,33,218,184,219,220,221,222,223,224,225,226,227,228,229,230,231],"modeling","threat modeling","threat","model","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":243,"publishedAt":44},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[238,239,240,241,242],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":211,"categoryName":212,"taxonomyType":97,"taxonomyTypeDesc":98},{"categoryNo":181,"categoryName":182,"taxonomyType":97,"taxonomyTypeDesc":98},[184,244,245,246,247,248,105,249,250,28,222,251,252,107,253,254,145,255,256,115],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]