[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JNZWM2PZMBVV9WZX7F72AH":3,"skill-same:01M6JNZWM2PZMBVV9WZX7F72AH":83},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6JNZWM2PZMBVV9WZX7F72AH","deployment-checklist",null,"Pre-deploy verification and release safety checks — config, migrations, monitoring, rollback readiness, comms. Triggers: deployment checklist, ready to deploy, pre-deploy, release checklist, go-live, ship checklist, deploy safety, is this safe to ship, release readiness.","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\u002Fplugins\u002Fbackend\u002Fskills\u002Fdeployment-checklist\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"deployment","deployment checklist","checklist","ready","release readiness","comms","release checklist","readiness","triggers","live","migrations","safe","rollback","ship","Safety","monitoring","verification","release","config","go","2026-11-10 10:12:30",false,"---\nname: deployment-checklist\ndescription: \"Pre-deploy verification and release safety checks — config, migrations, monitoring, rollback readiness, comms. Triggers: deployment checklist, ready to deploy, pre-deploy, release checklist, go-live, ship checklist, deploy safety, is this safe to ship, release readiness.\"\n---\n\n# Deployment Checklist\n\nEnsure code is production-ready before deploying. This skill runs through a structured verification process that catches common deployment failures before they reach users.\n\n## ⛔ The Iron Law\n\n**Don't check a box you haven't verified.**\n\nEvery checked item is backed by evidence — a command you ran in this session or code you read — not memory or assumption. \"Should be fine\" is not a verification. A blocked deploy is far cheaper than a production incident, so when a gate fails, stop and fix it before proceeding.\n\n## Workflow\n\n### Step 1: Assess the Change\n\nUnderstand the scope and risk of what's being deployed:\n\n- **What changed?** Review the diff against the deployment target branch\n- **Change type?** Feature \u002F bugfix \u002F hotfix \u002F infrastructure \u002F dependency update\n- **Risk level?** Low (cosmetic), Medium (logic change), High (data migration, auth, payments)\n- **Rollback plan?** Can this be reverted with a simple deploy, or does it require data migration reversal?\n\n### Step 2: Run the Checklist\n\nWalk through each section. Check items by reading code, running commands, and verifying artifacts.\n\n#### Code Quality\n- [ ] All tests pass (`npm test`, `pytest`, or project-specific command)\n- [ ] No linting errors or warnings\n- [ ] No `TODO` or `FIXME` items related to this change left unaddressed\n- [ ] No debugging code (console.log, debugger, print statements) left in\n- [ ] No commented-out code blocks\n\n#### Testing\n- [ ] New behavior has corresponding tests\n- [ ] Edge cases and error paths are tested\n- [ ] Integration tests pass against a clean environment\n- [ ] If applicable: manual testing completed on staging\n\n#### Security\n- [ ] No hardcoded secrets, API keys, or credentials\n- [ ] No new endpoints without authentication\u002Fauthorization\n- [ ] User input is validated and sanitized\n- [ ] Dependencies have no known critical vulnerabilities (`npm audit`, `pip audit`)\n\n#### Database & Data\n- [ ] Migrations are forwards-compatible (old code works with new schema)\n- [ ] Migrations are reversible\n- [ ] Large data changes have been tested on production-sized data\n- [ ] No destructive operations without confirmation (DROP, DELETE without WHERE)\n- [ ] Backfill scripts are idempotent (safe to run multiple times)\n\nThis checklist **verifies** a migration; it does not design one. When a box above fails —\na rename with no forwards-compatible path, an irreversible migration, a change that cannot\nbe split across deploys — the answer is an expand-contract migration strategy, and that is\n`data-modeling`'s work. Say so rather than green-lighting a redesign from the checklist.\n\n#### Configuration & Environment\n- [ ] New environment variables are documented and set in all target environments\n- [ ] Feature flags are in the correct state for this release\n- [ ] No environment-specific hardcoding (localhost URLs, test credentials)\n\n#### Observability\n- [ ] Errors are logged with sufficient context for debugging\n- [ ] New endpoints\u002Foperations have appropriate metrics or monitoring\n- [ ] Alert thresholds are reviewed for new functionality\n\n#### Documentation\n- [ ] README updated if setup steps changed\n- [ ] API documentation updated for new\u002Fchanged endpoints\n- [ ] Release cut correctly, if this deploy ships one — version, changelog, tag consistent (see `release-management`)\n- [ ] Breaking changes are clearly communicated\n\n### Step 3: Report\n\nSummarize the checklist results:\n\n- **Ready to deploy**: All checks pass\n- **Needs attention**: List specific items that need fixing\n- **Blocked**: Critical issues that must be resolved (data loss risk, security gap, failing tests)\n\n### Step 4: Deploy Safely\n\nBased on the change risk level:\n\n- **Low risk**: Deploy directly, monitor for 15 minutes\n- **Medium risk**: Deploy to staging first, verify, then production. Monitor for 1 hour\n- **High risk**: Deploy behind a feature flag, canary to a small percentage, monitor, then roll out gradually\n\n## Quick Reference\n\nFor urgent hotfixes where the full checklist feels heavy, run at minimum:\n1. Tests pass\n2. No secrets in code\n3. Migrations are reversible\n4. Rollback plan exists\n\nEverything else can be addressed in a follow-up, but these four prevent the worst outcomes.\n\n## Principles Applied\n\n- **KISS**: The simplest deploy that can safely reach production. Avoid adding complexity (new flags, new services) in the same deployment as the feature.\n- **Defense in depth**: Validate at every gate — tests, staging, canary — not just once. Each gate catches a different class of failure.\n- **Fail fast**: If a check fails, stop and fix before proceeding. A blocked deploy is far cheaper than a production incident.\n- **YAGNI**: Don't deploy speculative configuration or unused feature flags. Unused config is future confusion.\n\nSee [references\u002Fpre-deploy-gates.md](references\u002Fpre-deploy-gates.md) for environment-specific checklists, schema migration safety, and rollback trigger criteria.\n\n## Rationalizations to reject\n\n| Excuse | Reality |\n|--------|---------|\n| \"Tests passed in CI yesterday\" | Verify against the exact commit being deployed, now — not a stale run. |\n| \"It's a tiny change, skip the checklist\" | Tiny changes cause outages too. Run at least the four-item minimum. |\n| \"Migrations are probably reversible\" | \"Probably\" is not verified. Confirm the down-path exists and runs. |\n| \"We'll add monitoring after launch\" | You can't observe an incident you never instrumented. |\n| \"No time for staging\" | Skipping staging on a high-risk change is how data-loss incidents start. |\n\n## Red flags — stop and correct course\n\n- Marking items complete from memory rather than checking.\n- \"Should be fine\" \u002F \"probably works\" language about any gate.\n- Deploying a High-risk change with no rollback plan.\n- Bundling a risky migration and a feature in the same deploy.\n\n## Cross-Skill References\n\n- `data-modeling` — **name this handoff whenever a migration fails a Database & Data box.** This skill decides whether a migration is safe to ship; that one designs the expand-contract sequence (add, backfill, dual-write, cut over, drop) that makes it safe.\n- `release-management` — cutting the versioned release (semver, changelog, tag, publish) that this checklist deploys\n- `rollback-strategy` — design the rollback plan before deploying (required for High-risk changes)\n- `configuration-strategy` — verify all environment variables and feature flags are configured correctly\n- `incident-response` — use if the deployment causes a production incident\n- `verification-before-completion` — the evidence gate behind every checked box\n","# Deployment Checklist\n\nEnsure code is production-ready before deploying. This skill runs through a structured verification process that catches common deployment failures before they reach users.\n\n## ⛔ The Iron Law\n\n**Don't check a box you haven't verified.**\n\nEvery checked item is backed by evidence — a command you ran in this session or code you read — not memory or assumption. \"Should be fine\" is not a verification. A blocked deploy is far cheaper than a production incident, so when a gate fails, stop and fix it before proceeding.\n\n## Workflow\n\n### Step 1: Assess the Change\n\nUnderstand the scope and risk of what's being deployed:\n\n- **What changed?** Review the diff against the deployment target branch\n- **Change type?** Feature \u002F bugfix \u002F hotfix \u002F infrastructure \u002F dependency update\n- **Risk level?** Low (cosmetic), Medium (logic change), High (data migration, auth, payments)\n- **Rollback plan?** Can this be reverted with a simple deploy, or does it require data migration reversal?\n\n### Step 2: Run the Checklist\n\nWalk through each section. Check items by reading code, running commands, and verifying artifacts.\n\n#### Code Quality\n- [ ] All tests pass (`npm test`, `pytest`, or project-specific command)\n- [ ] No linting errors or warnings\n- [ ] No `TODO` or `FIXME` items related to this change left unaddressed\n- [ ] No debugging code (console.log, debugger, print statements) left in\n- [ ] No commented-out code blocks\n\n#### Testing\n- [ ] New behavior has corresponding tests\n- [ ] Edge cases and error paths are tested\n- [ ] Integration tests pass against a clean environment\n- [ ] If applicable: manual testing completed on staging\n\n#### Security\n- [ ] No hardcoded secrets, API keys, or credentials\n- [ ] No new endpoints without authentication\u002Fauthorization\n- [ ] User input is validated and sanitized\n- [ ] Dependencies have no known critical vulnerabilities (`npm audit`, `pip audit`)\n\n#### Database & Data\n- [ ] Migrations are forwards-compatible (old code works with new schema)\n- [ ] Migrations are reversible\n- [ ] Large data changes have been tested on production-sized data\n- [ ] No destructive operations without confirmation (DROP, DELETE without WHERE)\n- [ ] Backfill scripts are idempotent (safe to run multiple times)\n\nThis checklist **verifies** a migration; it does not design one. When a box above fails —\na rename with no forwards-compatible path, an irreversible migration, a change that cannot\nbe split across deploys — the answer is an expand-contract migration strategy, and that is\n`data-modeling`'s work. Say so rather than green-lighting a redesign from the checklist.\n\n#### Configuration & Environment\n- [ ] New environment variables are documented and set in all target environments\n- [ ] Feature flags are in the correct state for this release\n- [ ] No environment-specific hardcoding (localhost URLs, test credentials)\n\n#### Observability\n- [ ] Errors are logged with sufficient context for debugging\n- [ ] New endpoints\u002Foperations have appropriate metrics or monitoring\n- [ ] Alert thresholds are reviewed for new functionality\n\n#### Documentation\n- [ ] README updated if setup steps changed\n- [ ] API documentation updated for new\u002Fchanged endpoints\n- [ ] Release cut correctly, if this deploy ships one — version, changelog, tag consistent (see `release-management`)\n- [ ] Breaking changes are clearly communicated\n\n### Step 3: Report\n\nSummarize the checklist results:\n\n- **Ready to deploy**: All checks pass\n- **Needs attention**: List specific items that need fixing\n- **Blocked**: Critical issues that must be resolved (data loss risk, security gap, failing tests)\n\n### Step 4: Deploy Safely\n\nBased on the change risk level:\n\n- **Low risk**: Deploy directly, monitor for 15 minutes\n- **Medium risk**: Deploy to staging first, verify, then production. Monitor for 1 hour\n- **High risk**: Deploy behind a feature flag, canary to a small percentage, monitor, then roll out gradually\n\n## Quick Reference\n\nFor urgent hotfixes where the full checklist feels heavy, run at minimum:\n1. Tests pass\n2. No secrets in code\n3. Migrations are reversible\n4. Rollback plan exists\n\nEverything else can be addressed in a follow-up, but these four prevent the worst outcomes.\n\n## Principles Applied\n\n- **KISS**: The simplest deploy that can safely reach production. Avoid adding complexity (new flags, new services) in the same deployment as the feature.\n- **Defense in depth**: Validate at every gate — tests, staging, canary — not just once. Each gate catches a different class of failure.\n- **Fail fast**: If a check fails, stop and fix before proceeding. A blocked deploy is far cheaper than a production incident.\n- **YAGNI**: Don't deploy speculative configuration or unused feature flags. Unused config is future confusion.\n\nSee [references\u002Fpre-deploy-gates.md](references\u002Fpre-deploy-gates.md) for environment-specific checklists, schema migration safety, and rollback trigger criteria.\n\n## Rationalizations to reject\n\n| Excuse | Reality |\n|--------|---------|\n| \"Tests passed in CI yesterday\" | Verify against the exact commit being deployed, now — not a stale run. |\n| \"It's a tiny change, skip the checklist\" | Tiny changes cause outages too. Run at least the four-item minimum. |\n| \"Migrations are probably reversible\" | \"Probably\" is not verified. Confirm the down-path exists and runs. |\n| \"We'll add monitoring after launch\" | You can't observe an incident you never instrumented. |\n| \"No time for staging\" | Skipping staging on a high-risk change is how data-loss incidents start. |\n\n## Red flags — stop and correct course\n\n- Marking items complete from memory rather than checking.\n- \"Should be fine\" \u002F \"probably works\" language about any gate.\n- Deploying a High-risk change with no rollback plan.\n- Bundling a risky migration and a feature in the same deploy.\n\n## Cross-Skill References\n\n- `data-modeling` — **name this handoff whenever a migration fails a Database & Data box.** This skill decides whether a migration is safe to ship; that one designs the expand-contract sequence (add, backfill, dual-write, cut over, drop) that makes it safe.\n- `release-management` — cutting the versioned release (semver, changelog, tag, publish) that this checklist deploys\n- `rollback-strategy` — design the rollback plan before deploying (required for High-risk changes)\n- `configuration-strategy` — verify all environment variables and feature flags are configured correctly\n- `incident-response` — use if the deployment causes a production incident\n- `verification-before-completion` — the evidence gate behind every checked box\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fbackend\u002Fskills\u002Fdeployment-checklist","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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill deployment-checklist",{"tool":65,"command":66},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill deployment-checklist",{"tool":68,"command":69},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill deployment-checklist","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fbackend\u002Fskills\u002Fdeployment-checklist\u002FSKILL.md",true,[73,79],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"evals\u002Fevals.json","REFERENCE","参考文档",3458,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fbackend\u002Fskills\u002Fdeployment-checklist\u002Fevals\u002Fevals.json",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fpre-deploy-gates.md",3767,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fbackend\u002Fskills\u002Fdeployment-checklist\u002Freferences\u002Fpre-deploy-gates.md",[84,125,151,171,204,232],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":105,"publishedAt":47},"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",[90,93,96,97,102],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":103,"categoryName":104,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000040","财务",[106,107,108,109,110,111,112,113,114,115,116,117,35,118,119,120,121,122,123,124],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":47},"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",[131],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[133,134,135,136,137,138,139,140,141,142,143,144,145,146,36,147,148,149,35,150],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","do","README","session","routines",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":47},"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",[157],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[43,159,160,30,161,162,106,163,136,164,165,166,139,167,143,168,44,169,170,40],"verification before completion","brief","fix","claim","workflow","commit","text","route","message","merge","git","act",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":184,"publishedAt":47},"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",[177,180,181],{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":182,"categoryName":183,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000032","设计师",[185,186,187,188,189,190,191,192,193,194,195,196,141,197,198,199,200,201,202,203],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":214,"publishedAt":47},"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",[210,211],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000030","开发工程师",[215,216,217,218,219,220,185,221,222,223,224,225,226,227,228,229,45,46,230,231],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","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":47},"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":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":100,"taxonomyTypeDesc":101},{"categoryNo":182,"categoryName":183,"taxonomyType":100,"taxonomyTypeDesc":101},[185,244,245,246,247,248,108,249,250,163,224,251,252,110,253,254,147,255,256,35],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]