[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQCTJBTE9S8VBWDMV3DXTN":3,"skill-same:01M6JQCTJBTE9S8VBWDMV3DXTN":87},{"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},"01M6JQCTJBTE9S8VBWDMV3DXTN","rollback-strategy",null,"Design safe rollback plans before deploying — identify irreversible changes, classify rollback complexity, create tested undo procedures. Triggers: rollback plan, rollback strategy, how do I undo this, can we revert, what if the deploy fails, safe to deploy, feature flag rollout, blue-green, database migration rollback, irreversible change.","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\u002Frollback-strategy\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","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],"rollback strategy","rollback","strategy","rollout","blue-green","rollback plan","triggers","classify","feature","green","do","complexity","design","plan","how","database migration","database","create","change","safe","2026-11-10 10:12:30",false,"---\nname: rollback-strategy\ndescription: \"Design safe rollback plans before deploying — identify irreversible changes, classify rollback complexity, create tested undo procedures. Triggers: rollback plan, rollback strategy, how do I undo this, can we revert, what if the deploy fails, safe to deploy, feature flag rollout, blue-green, database migration rollback, irreversible change.\"\n---\n\n# Rollback Strategy\n\nDesign the undo plan before deploying — not during a production incident. A deployment without a rollback plan is a bet that nothing will go wrong.\n\n## ⛔ The Iron Law\n\n**If you can't undo it, don't ship it yet.**\n\nEvery change is classified by rollback complexity before deploy, and every non-Simple change has a written rollback procedure that has been *tested* — not just imagined. Decide rollback before the incident, never during it: the minutes you'd spend designing an undo mid-incident are the minutes users are down.\n\n## Step 1: Analyze the Deployment\n\nList every change being deployed:\n\n- **Code changes**: Which services, which endpoints, what behavior changes?\n- **Schema changes**: New tables, columns, indexes, constraints, dropped columns?\n- **Data migrations**: Backfills, transformations, deletes?\n- **Configuration changes**: New env vars, feature flag states, infrastructure config?\n- **Dependency updates**: Library upgrades, external service version changes?\n\nFor each change, ask: **If this change caused a production incident 30 minutes after deploy, what would rollback look like?**\n\n**When the deploy has already happened and users are affected now**, this is an\nactive incident, not planning. Lead with the fastest safe undo — revert the deploy or\nturn the flag off — as exact steps, and name `incident-response` as the workflow\nfor the rest of the incident. Keep the rollback-plan template (owner, estimated time,\nstaging rehearsal) out of this answer; it belongs in the post-incident review.\n\n## Step 2: Classify by Rollback Complexity\n\nAssign each change a rollback complexity:\n\n| Complexity | Definition | Examples |\n|-----------|-----------|---------|\n| **Simple** | Revert the code deploy, no other steps | Logic change, UI change, new feature behind a flag |\n| **Coordinated** | Code revert + one other step | New env var (remove it), new index (drop it), additive column (leave it, no harm) |\n| **Complex** | Requires data migration reversal or multi-step coordination | Column rename (requires data migration), data backfill (must un-backfill) |\n| **Irreversible** | Cannot be fully undone | Destructive data operations, sent emails\u002Fnotifications, external API calls with side effects |\n\n**If any change is Irreversible**: explicitly document what partial rollback looks like and get sign-off before deploying.\n\nSee [references\u002Frollback-patterns.md](references\u002Frollback-patterns.md) for detailed patterns per component type.\n\n## Step 3: Design the Rollback Procedure\n\nFor each non-Simple change, write the explicit rollback steps:\n\n**Database schema rollback:**\n- Additive columns (new nullable column): safe to leave after rollback — old code ignores them\n- Non-additive changes (rename, type change, NOT NULL constraint): require a reverse migration\n- Dropped columns: need to be re-added and re-populated (use `git bisect` to find the data state)\n\n**Feature flag rollback:**\n- Define the \"off\" state before deploying\n- Test the \"off\" state in staging before deploying to production\n- Know which percentage to roll back to if doing a canary rollout\n\n**Data migration rollback:**\n- Write the reverse migration before deploying the forward migration\n- Test both on a copy of production data\n- If the migration is too large to reverse quickly, plan for an emergency read-only mode instead\n\n**Configuration rollback:**\n- Document the previous value of every env var being changed\n- For secrets rotation: keep the old secret valid for 24 hours after switching\n\n## Step 4: Document and Test the Plan\n\nWrite the rollback plan in the deployment PR or deployment runbook:\n\n```\nRollback Plan:\n1. [Step]: [Command or action]\n2. [Step]: [Command or action]\n3. Verify: [How to confirm rollback succeeded]\nEstimated rollback time: [X minutes]\nRollback owner: [Who executes this during an incident]\n```\n\n**Test it before you need it:**\n- Run the rollback steps in staging before production deploy\n- Confirm the rollback takes the expected time (important during incidents)\n- Verify application health after rollback completes\n\nUse [templates\u002Frollback-plan.md](templates\u002Frollback-plan.md) for the full plan format.\n\n## Principles Applied\n\n- **KISS**: Prefer feature flags over complex rollback procedures. The simplest rollback is turning a flag off.\n- **YAGNI**: Don't deploy a change you can't roll back without a documented, tested plan. If you can't undo it, don't ship it yet.\n- **Defense in depth**: Multiple rollback options (flag → revert → data migration reversal) provide fallbacks when the first option isn't enough.\n- **Fail fast**: Define rollback triggers before deploying (see `deployment-checklist`). Waiting until an incident to decide when to rollback wastes critical time.\n\n## Rationalizations to reject\n\n| Excuse | Reality |\n|--------|---------|\n| \"We'll figure out rollback if it breaks\" | Designing rollback mid-incident wastes the minutes that matter most. |\n| \"The migration is reversible, trust me\" | Reversible in theory ≠ tested. Run the reverse on production-sized data first. |\n| \"It's behind a flag, that's enough\" | Only if the off-state was defined and tested before deploy. |\n| \"Rollback is unlikely, skip the plan\" | A rollback plan is insurance — you write it before you need it, not after. |\n| \"Additive column, no rollback needed\" | Confirm old code ignores it and document the no-op explicitly. |\n\n## Red flags — stop and correct course\n\n- An Irreversible change with no documented partial-rollback and no sign-off.\n- A reverse migration that has never actually been executed.\n- A feature flag whose off-state was never tested in staging.\n- The estimated rollback time is unknown.\n\n## Cross-Skill References\n\n- `deployment-checklist` — run before every deploy; rollback plan is a required gate\n- `incident-response` — execute the rollback plan when an incident occurs\n- `configuration-strategy` — design feature flags as part of config strategy (reduces rollback complexity)\n","# Rollback Strategy\n\nDesign the undo plan before deploying — not during a production incident. A deployment without a rollback plan is a bet that nothing will go wrong.\n\n## ⛔ The Iron Law\n\n**If you can't undo it, don't ship it yet.**\n\nEvery change is classified by rollback complexity before deploy, and every non-Simple change has a written rollback procedure that has been *tested* — not just imagined. Decide rollback before the incident, never during it: the minutes you'd spend designing an undo mid-incident are the minutes users are down.\n\n## Step 1: Analyze the Deployment\n\nList every change being deployed:\n\n- **Code changes**: Which services, which endpoints, what behavior changes?\n- **Schema changes**: New tables, columns, indexes, constraints, dropped columns?\n- **Data migrations**: Backfills, transformations, deletes?\n- **Configuration changes**: New env vars, feature flag states, infrastructure config?\n- **Dependency updates**: Library upgrades, external service version changes?\n\nFor each change, ask: **If this change caused a production incident 30 minutes after deploy, what would rollback look like?**\n\n**When the deploy has already happened and users are affected now**, this is an\nactive incident, not planning. Lead with the fastest safe undo — revert the deploy or\nturn the flag off — as exact steps, and name `incident-response` as the workflow\nfor the rest of the incident. Keep the rollback-plan template (owner, estimated time,\nstaging rehearsal) out of this answer; it belongs in the post-incident review.\n\n## Step 2: Classify by Rollback Complexity\n\nAssign each change a rollback complexity:\n\n| Complexity | Definition | Examples |\n|-----------|-----------|---------|\n| **Simple** | Revert the code deploy, no other steps | Logic change, UI change, new feature behind a flag |\n| **Coordinated** | Code revert + one other step | New env var (remove it), new index (drop it), additive column (leave it, no harm) |\n| **Complex** | Requires data migration reversal or multi-step coordination | Column rename (requires data migration), data backfill (must un-backfill) |\n| **Irreversible** | Cannot be fully undone | Destructive data operations, sent emails\u002Fnotifications, external API calls with side effects |\n\n**If any change is Irreversible**: explicitly document what partial rollback looks like and get sign-off before deploying.\n\nSee [references\u002Frollback-patterns.md](references\u002Frollback-patterns.md) for detailed patterns per component type.\n\n## Step 3: Design the Rollback Procedure\n\nFor each non-Simple change, write the explicit rollback steps:\n\n**Database schema rollback:**\n- Additive columns (new nullable column): safe to leave after rollback — old code ignores them\n- Non-additive changes (rename, type change, NOT NULL constraint): require a reverse migration\n- Dropped columns: need to be re-added and re-populated (use `git bisect` to find the data state)\n\n**Feature flag rollback:**\n- Define the \"off\" state before deploying\n- Test the \"off\" state in staging before deploying to production\n- Know which percentage to roll back to if doing a canary rollout\n\n**Data migration rollback:**\n- Write the reverse migration before deploying the forward migration\n- Test both on a copy of production data\n- If the migration is too large to reverse quickly, plan for an emergency read-only mode instead\n\n**Configuration rollback:**\n- Document the previous value of every env var being changed\n- For secrets rotation: keep the old secret valid for 24 hours after switching\n\n## Step 4: Document and Test the Plan\n\nWrite the rollback plan in the deployment PR or deployment runbook:\n\n```\nRollback Plan:\n1. [Step]: [Command or action]\n2. [Step]: [Command or action]\n3. Verify: [How to confirm rollback succeeded]\nEstimated rollback time: [X minutes]\nRollback owner: [Who executes this during an incident]\n```\n\n**Test it before you need it:**\n- Run the rollback steps in staging before production deploy\n- Confirm the rollback takes the expected time (important during incidents)\n- Verify application health after rollback completes\n\nUse [templates\u002Frollback-plan.md](templates\u002Frollback-plan.md) for the full plan format.\n\n## Principles Applied\n\n- **KISS**: Prefer feature flags over complex rollback procedures. The simplest rollback is turning a flag off.\n- **YAGNI**: Don't deploy a change you can't roll back without a documented, tested plan. If you can't undo it, don't ship it yet.\n- **Defense in depth**: Multiple rollback options (flag → revert → data migration reversal) provide fallbacks when the first option isn't enough.\n- **Fail fast**: Define rollback triggers before deploying (see `deployment-checklist`). Waiting until an incident to decide when to rollback wastes critical time.\n\n## Rationalizations to reject\n\n| Excuse | Reality |\n|--------|---------|\n| \"We'll figure out rollback if it breaks\" | Designing rollback mid-incident wastes the minutes that matter most. |\n| \"The migration is reversible, trust me\" | Reversible in theory ≠ tested. Run the reverse on production-sized data first. |\n| \"It's behind a flag, that's enough\" | Only if the off-state was defined and tested before deploy. |\n| \"Rollback is unlikely, skip the plan\" | A rollback plan is insurance — you write it before you need it, not after. |\n| \"Additive column, no rollback needed\" | Confirm old code ignores it and document the no-op explicitly. |\n\n## Red flags — stop and correct course\n\n- An Irreversible change with no documented partial-rollback and no sign-off.\n- A reverse migration that has never actually been executed.\n- A feature flag whose off-state was never tested in staging.\n- The estimated rollback time is unknown.\n\n## Cross-Skill References\n\n- `deployment-checklist` — run before every deploy; rollback plan is a required gate\n- `incident-response` — execute the rollback plan when an incident occurs\n- `configuration-strategy` — design feature flags as part of config strategy (reduces rollback complexity)\n",{"name":5,"description":7},"main","46d93a06e399e44d3802aaebecc09255de0d28dd","skills\u002Frollback-strategy","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 rollback-strategy",{"tool":65,"command":66},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill rollback-strategy",{"tool":68,"command":69},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill rollback-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frollback-strategy\u002FSKILL.md",true,[73,79,83],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"evals\u002Fevals.json","REFERENCE","参考文档",5154,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frollback-strategy\u002Fevals\u002Fevals.json",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Frollback-patterns.md",5439,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frollback-strategy\u002Freferences\u002Frollback-patterns.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"templates\u002Frollback-plan.md",1441,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Frollback-strategy\u002Ftemplates\u002Frollback-plan.md",[88,129,154,178,208,238],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":109,"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",[94,97,100,101,106],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":107,"categoryName":108,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000040","财务",[110,111,112,113,114,115,116,117,118,119,120,121,33,122,123,124,125,126,127,128],"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":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"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",[135],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[137,138,139,140,141,142,143,144,41,145,146,147,148,149,150,37,151,152,33,153],"working agreement","project","definition of done","done","milestone","documentation","work","progress","contributing","close","run","sync","status","live","README","session","routines",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":161,"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",[160],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[162,163,164,165,166,167,110,168,140,169,170,171,143,172,146,173,174,175,176,177],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":189,"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",[184,185,186],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":187,"categoryName":188,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000032","设计师",[39,190,191,192,193,194,195,196,197,198,199,200,41,201,202,203,204,205,206,207],"ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":218,"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",[214,215],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":216,"categoryName":217,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000030","开发工程师",[219,220,221,222,223,224,39,225,226,227,228,229,230,231,232,233,234,235,236,237],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":239,"name":240,"nameZh":6,"description":241,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":242,"categories":243,"keywords":249,"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",[244,245,246,247,248],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":216,"categoryName":217,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":187,"categoryName":188,"taxonomyType":104,"taxonomyTypeDesc":105},[39,250,251,252,253,254,112,255,256,168,228,257,40,114,258,259,37,260,261,33],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","add","infrastructure","test plan","for"]