[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQ4YVJR8WAFY3EQDC19306":3,"skill-same:01M6JQ4YVJR8WAFY3EQDC19306":82},{"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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6JQ4YVJR8WAFY3EQDC19306","configuration-strategy",null,"Design environment configuration, secrets management, and feature-flag hierarchy for a service or feature. Triggers: config strategy, environment variables, .env, secrets management, feature flag, config hierarchy, config precedence, twelve-factor config, environment-specific settings.","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\u002Fconfiguration-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],"configuration strategy","strategy","configuration","service","for","twelve-factor","Variables","environment variables","factor","env","triggers","feature","design","environment","management","settings","secrets","secrets management","config","2026-11-10 10:12:30",false,"---\nname: configuration-strategy\ndescription: \"Design environment configuration, secrets management, and feature-flag hierarchy for a service or feature. Triggers: config strategy, environment variables, .env, secrets management, feature flag, config hierarchy, config precedence, twelve-factor config, environment-specific settings.\"\n---\n\n# Configuration Strategy\n\nDesign configuration that is safe, auditable, and easy to change. Most configuration problems (hardcoded secrets, production config in dev, feature flags with no off-switch) come from not designing the system upfront.\n\n## Step 0: Inventory What Already Exists\n\nBefore introducing a new environment variable, secret, feature flag, or\nconstant, establish what the project already defines. Inspect the current state\n**directly** — grep the tree; don't infer it from the requirements or memory.\n\nCover both:\n\n- **Artifacts** — existing key names *and* the values themselves. Search for the\n  literal value, not just the name: the same timeout or limit is often already\n  hardcoded in two places, and adding a third is the common failure.\n- **Written decisions** — config conventions, naming schemes, `.env.example`,\n  and prior audit findings that already govern where things live.\n\n**Exit condition** — one line, then keep going in the same response:\n*\"`\u003Cexisting key>` already carries `\u003Cvalue>`; it does \u002F does not serve this\nbecause `\u003Creason>`.\"*\n\n**This step is not a gate on delivering.** Greenfield — nothing configured yet,\nor nothing you can reach — closes it in one line: say so and go straight to\nStep 1. When you can't inspect, name what you would check and continue under\nstated assumptions. Never answer with inventory and questions alone; produce the\nconfiguration design in the same reply.\n\nThis constrains the input, not the choice. A new key is a fine outcome; an\nunexamined one isn't — and a duplicated value will drift.\n\n## Step 1: Identify All Configuration Needed\n\nList every piece of configuration the feature or service requires:\n\n- **Service endpoints**: URLs for external APIs, internal services, databases\n- **Credentials and secrets**: API keys, database passwords, signing keys, certificates\n- **Behavior toggles**: Feature flags, A\u002FB test parameters, rate limits, timeouts\n- **Static config**: Timeouts, retry counts, pagination defaults, log levels\n- **Environment-specific values**: Different database URLs for dev\u002Fstaging\u002Fprod\n\nDon't leave any implicit. \"We'll hard-code the staging URL for now\" is the start of a production incident.\n\n## Step 2: Classify Each Configuration Item\n\nFor each item, determine:\n\n**Sensitivity:**\n- **Secret**: Must never appear in logs, code, or non-encrypted storage (API keys, passwords, tokens)\n- **Sensitive**: Not a secret but not public (internal service URLs, customer IDs)\n- **Non-sensitive**: Safe to log, safe in version control (log levels, timeouts, feature flag names)\n\n**Mutability:**\n- **Static**: Set at deploy time, doesn't change without a redeploy (database schema version, service name)\n- **Runtime-mutable**: Can change without redeploy (feature flags, rate limits, A\u002FB test parameters)\n\n**Scope:**\n- **Global**: Same value in all environments (timeout constants, algorithm parameters)\n- **Environment-specific**: Different per env (database URLs, API endpoints, log levels)\n- **Per-tenant\u002Fper-user**: Different per customer (feature entitlements, custom limits)\n\n## Step 3: Design the Configuration Hierarchy\n\nBased on classification, assign each item to the right storage:\n\n| Storage | For | Examples |\n|---------|-----|---------|\n| Environment variables | Environment-specific non-secrets | DATABASE_URL, SERVICE_ENV, LOG_LEVEL |\n| Secrets manager | All secrets | Database passwords, API keys, signing keys |\n| Feature flag service | Runtime-mutable toggles | Feature flags, A\u002FB variants, rollout percentages |\n| Config file in repo | Non-sensitive static config | Timeout constants, retry policies, allowed values |\n| Database (config table) | Per-tenant\u002Fper-user config | Customer-specific rate limits, feature entitlements |\n\n**Hierarchy principle**: More specific overrides less specific. Per-tenant overrides environment which overrides global default.\n\nSee [references\u002Fconfig-patterns.md](references\u002Fconfig-patterns.md) for feature flag design patterns and secrets management tool guidance.\n\n## Step 4: Plan Safe Config Rollout\n\nConfiguration changes can cause outages just like code changes. Plan rollout for each type:\n\n**Secrets rotation:**\n1. Generate new secret while old one remains valid\n2. Deploy application with new secret\n3. Verify application uses new secret correctly\n4. Revoke old secret (after 24-hour overlap window)\n\n**Feature flag rollout:**\n1. Start at 0% — verify flag infrastructure works\n2. Enable for internal users — catch obvious breakage\n3. Enable for small percentage (5-10%) — monitor metrics\n4. Ramp up gradually — verify metrics hold at each step\n5. Full rollout — verify, then clean up the flag\n\n**Environment variable changes:**\n- New variables: set in target environment *before* deploying code that reads them\n- Changed values: consider backward compatibility with old code during rolling deploys\n- Removed variables: remove from code *before* removing from environment config\n\n## Step 5: Audit Existing Code for Anti-patterns\n\nReview the codebase for common configuration mistakes:\n\n**Hardcoded values to find and fix:**\n- IP addresses, hostnames, port numbers (search: `localhost`, `127.0.0.1`, regex for IP patterns)\n- Credentials (search: `password`, `secret`, `api_key`, `token` in string literals)\n- Environment-specific constants (search for strings that differ between environments)\n- Magic numbers that should be configurable (search for hardcoded timeouts, limits, batch sizes)\n\n**Config anti-patterns:**\n- Feature flags that have been \"on\" everywhere for 6+ months (dead code risk — remove the flag)\n- Config values read but never validated (add startup validation that fails fast on missing config)\n- Different config loading paths for test vs production (leads to \"works in tests but not prod\")\n- Secrets passed via command-line arguments (visible in process lists)\n\n## Principles Applied\n\n- **DRY**: Single source of truth for each config value. If the same value appears in multiple places, it will drift.\n- **KISS**: Flat config beats deeply nested config. Environment variables beat custom config DSLs.\n- **Least privilege**: Services should only have access to the secrets they need. Database credentials shouldn't be shared across services.\n- **YAGNI**: Don't create config variables for things that will never change. Hard-code what's truly constant.\n- **Fail fast**: Validate all required config on startup. A crash at startup is better than a mysterious failure 10 minutes in.\n\n## Cross-Skill References\n\n- `feature-planning` — decide which behaviors will be feature-flagged during planning, before implementation\n- `security-audit` — review secrets handling and access control as part of security review\n- `deployment-checklist` — verify all config is set before deploying\n- `rollback-strategy` — feature flags are the simplest rollback mechanism; design them accordingly\n","# Configuration Strategy\n\nDesign configuration that is safe, auditable, and easy to change. Most configuration problems (hardcoded secrets, production config in dev, feature flags with no off-switch) come from not designing the system upfront.\n\n## Step 0: Inventory What Already Exists\n\nBefore introducing a new environment variable, secret, feature flag, or\nconstant, establish what the project already defines. Inspect the current state\n**directly** — grep the tree; don't infer it from the requirements or memory.\n\nCover both:\n\n- **Artifacts** — existing key names *and* the values themselves. Search for the\n  literal value, not just the name: the same timeout or limit is often already\n  hardcoded in two places, and adding a third is the common failure.\n- **Written decisions** — config conventions, naming schemes, `.env.example`,\n  and prior audit findings that already govern where things live.\n\n**Exit condition** — one line, then keep going in the same response:\n*\"`\u003Cexisting key>` already carries `\u003Cvalue>`; it does \u002F does not serve this\nbecause `\u003Creason>`.\"*\n\n**This step is not a gate on delivering.** Greenfield — nothing configured yet,\nor nothing you can reach — closes it in one line: say so and go straight to\nStep 1. When you can't inspect, name what you would check and continue under\nstated assumptions. Never answer with inventory and questions alone; produce the\nconfiguration design in the same reply.\n\nThis constrains the input, not the choice. A new key is a fine outcome; an\nunexamined one isn't — and a duplicated value will drift.\n\n## Step 1: Identify All Configuration Needed\n\nList every piece of configuration the feature or service requires:\n\n- **Service endpoints**: URLs for external APIs, internal services, databases\n- **Credentials and secrets**: API keys, database passwords, signing keys, certificates\n- **Behavior toggles**: Feature flags, A\u002FB test parameters, rate limits, timeouts\n- **Static config**: Timeouts, retry counts, pagination defaults, log levels\n- **Environment-specific values**: Different database URLs for dev\u002Fstaging\u002Fprod\n\nDon't leave any implicit. \"We'll hard-code the staging URL for now\" is the start of a production incident.\n\n## Step 2: Classify Each Configuration Item\n\nFor each item, determine:\n\n**Sensitivity:**\n- **Secret**: Must never appear in logs, code, or non-encrypted storage (API keys, passwords, tokens)\n- **Sensitive**: Not a secret but not public (internal service URLs, customer IDs)\n- **Non-sensitive**: Safe to log, safe in version control (log levels, timeouts, feature flag names)\n\n**Mutability:**\n- **Static**: Set at deploy time, doesn't change without a redeploy (database schema version, service name)\n- **Runtime-mutable**: Can change without redeploy (feature flags, rate limits, A\u002FB test parameters)\n\n**Scope:**\n- **Global**: Same value in all environments (timeout constants, algorithm parameters)\n- **Environment-specific**: Different per env (database URLs, API endpoints, log levels)\n- **Per-tenant\u002Fper-user**: Different per customer (feature entitlements, custom limits)\n\n## Step 3: Design the Configuration Hierarchy\n\nBased on classification, assign each item to the right storage:\n\n| Storage | For | Examples |\n|---------|-----|---------|\n| Environment variables | Environment-specific non-secrets | DATABASE_URL, SERVICE_ENV, LOG_LEVEL |\n| Secrets manager | All secrets | Database passwords, API keys, signing keys |\n| Feature flag service | Runtime-mutable toggles | Feature flags, A\u002FB variants, rollout percentages |\n| Config file in repo | Non-sensitive static config | Timeout constants, retry policies, allowed values |\n| Database (config table) | Per-tenant\u002Fper-user config | Customer-specific rate limits, feature entitlements |\n\n**Hierarchy principle**: More specific overrides less specific. Per-tenant overrides environment which overrides global default.\n\nSee [references\u002Fconfig-patterns.md](references\u002Fconfig-patterns.md) for feature flag design patterns and secrets management tool guidance.\n\n## Step 4: Plan Safe Config Rollout\n\nConfiguration changes can cause outages just like code changes. Plan rollout for each type:\n\n**Secrets rotation:**\n1. Generate new secret while old one remains valid\n2. Deploy application with new secret\n3. Verify application uses new secret correctly\n4. Revoke old secret (after 24-hour overlap window)\n\n**Feature flag rollout:**\n1. Start at 0% — verify flag infrastructure works\n2. Enable for internal users — catch obvious breakage\n3. Enable for small percentage (5-10%) — monitor metrics\n4. Ramp up gradually — verify metrics hold at each step\n5. Full rollout — verify, then clean up the flag\n\n**Environment variable changes:**\n- New variables: set in target environment *before* deploying code that reads them\n- Changed values: consider backward compatibility with old code during rolling deploys\n- Removed variables: remove from code *before* removing from environment config\n\n## Step 5: Audit Existing Code for Anti-patterns\n\nReview the codebase for common configuration mistakes:\n\n**Hardcoded values to find and fix:**\n- IP addresses, hostnames, port numbers (search: `localhost`, `127.0.0.1`, regex for IP patterns)\n- Credentials (search: `password`, `secret`, `api_key`, `token` in string literals)\n- Environment-specific constants (search for strings that differ between environments)\n- Magic numbers that should be configurable (search for hardcoded timeouts, limits, batch sizes)\n\n**Config anti-patterns:**\n- Feature flags that have been \"on\" everywhere for 6+ months (dead code risk — remove the flag)\n- Config values read but never validated (add startup validation that fails fast on missing config)\n- Different config loading paths for test vs production (leads to \"works in tests but not prod\")\n- Secrets passed via command-line arguments (visible in process lists)\n\n## Principles Applied\n\n- **DRY**: Single source of truth for each config value. If the same value appears in multiple places, it will drift.\n- **KISS**: Flat config beats deeply nested config. Environment variables beat custom config DSLs.\n- **Least privilege**: Services should only have access to the secrets they need. Database credentials shouldn't be shared across services.\n- **YAGNI**: Don't create config variables for things that will never change. Hard-code what's truly constant.\n- **Fail fast**: Validate all required config on startup. A crash at startup is better than a mysterious failure 10 minutes in.\n\n## Cross-Skill References\n\n- `feature-planning` — decide which behaviors will be feature-flagged during planning, before implementation\n- `security-audit` — review secrets handling and access control as part of security review\n- `deployment-checklist` — verify all config is set before deploying\n- `rollback-strategy` — feature flags are the simplest rollback mechanism; design them accordingly\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","skills\u002Fconfiguration-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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill configuration-strategy",{"tool":64,"command":65},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill configuration-strategy",{"tool":67,"command":68},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill configuration-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfiguration-strategy\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"evals\u002Fevals.json","REFERENCE","参考文档",2982,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfiguration-strategy\u002Fevals\u002Fevals.json",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fconfig-patterns.md",5696,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfiguration-strategy\u002Freferences\u002Fconfig-patterns.md",[83,124,151,175,205,234],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":104,"publishedAt":46},"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",[89,92,95,96,101],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":102,"categoryName":103,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000040","财务",[105,106,107,108,109,110,111,112,113,114,115,116,37,117,118,119,120,121,122,123],"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":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":46},"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",[130],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,37,150],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","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":46},"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},[159,160,161,162,163,164,105,165,135,166,167,168,138,169,142,170,171,172,173,174],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":186,"publishedAt":46},"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",[181,182,183],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000032","设计师",[39,187,188,189,190,191,192,193,194,195,196,197,140,198,199,200,201,202,203,204],"ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":215,"publishedAt":46},"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",[211,212],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":213,"categoryName":214,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000030","开发工程师",[216,217,218,219,220,221,39,222,223,224,225,226,227,228,229,230,45,231,232,233],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","go","security","trust",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":245,"publishedAt":46},"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",[240,241,242,243,244],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":213,"categoryName":214,"taxonomyType":99,"taxonomyTypeDesc":100},{"categoryNo":184,"categoryName":185,"taxonomyType":99,"taxonomyTypeDesc":100},[39,246,247,248,249,250,107,251,252,165,225,253,254,109,255,256,147,257,31,37],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan"]