[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPZ18MP2JXNF9NGF42HC4K":3,"skill-same:01M6JPZ18MP2JXNF9NGF42HC4K":84},{"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},"01M6JPZ18MP2JXNF9NGF42HC4K","feature-planning",null,"Break features into well-scoped tasks with acceptance criteria, risk assessment, and dependency mapping. Triggers: plan this, break this down, scope this feature, create tasks for, sprint planning, how should I implement this feature, user stories, acceptance criteria, dependency mapping, feature breakdown. Creates the plan — executing an already-approved plan checkpoint by checkpoint → plan-execution.","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\u002Fsecurity\u002Fskills\u002Ffeature-planning\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],"planning","feature planning","feature","plan-execution","risk assessment","features","break","user stories","mapping","Feature Breakdown","sprint","scope","dependency","plan","how","risk","acceptance","create","tasks","assessment","2026-11-10 10:12:30",false,"---\nname: feature-planning\ndescription: \"Break features into well-scoped tasks with acceptance criteria, risk assessment, and dependency mapping. Triggers: plan this, break this down, scope this feature, create tasks for, sprint planning, how should I implement this feature, user stories, acceptance criteria, dependency mapping, feature breakdown. Creates the plan — executing an already-approved plan checkpoint by checkpoint → plan-execution.\"\n---\n\n# Feature Planning\n\nGuide the user through transforming a feature idea or requirement into a structured, actionable implementation plan. The goal is a plan that a developer (or Claude Code) can pick up and execute with minimal ambiguity.\n\n## Workflow\n\n### Step 1: Understand the Feature\n\nAsk clarifying questions to close knowledge gaps. Focus on:\n\n- **What problem does this solve?** (user pain, business value)\n- **Who is the user?** (persona, role, access level)\n- **What exists today?** (current behavior, workarounds)\n- **What are the constraints?** (timeline, tech stack, backwards compatibility)\n- **What's out of scope?** (explicitly define boundaries)\n- **How will we know it works?** (what verification and test coverage this needs)\n\n**This step is not a gate on delivering.** Whether you draft now or ask first is\na condition, not a preference. Apply this test:\n\n> Can you write at least one Given\u002FWhen\u002FThen acceptance criterion **without\n> inventing the feature's core behavior?**\n\n- **Yes → draft now.** The remaining unknowns are assumptions, not blockers:\n  state them and carry the full plan **in the same response**. A draft the user\n  corrects beats a question they must answer. (\"Email and in-app notifications\n  when someone comments on their posts\" passes — the behavior is given.)\n- **No → ask first**, and say what you'd need to start drafting. A named stack\n  plus a feature label is not enough on its own: \"add dark mode to our Vue app\"\n  and \"add authentication\" both fail the test, because the core behavior\n  (persistence? system-preference default? which auth methods, which protected\n  resources, which roles?) would have to be invented rather than planned.\n\n**Exit condition for the draft branch** — one line, then keep going in the same\nresponse: *\"Planning under these assumptions: `\u003C…>` — correct any and I'll\nrevise.\"*\n\nNever answer a planning request with questions alone when the draft branch\napplies. Unanswered questions belong in Step 5's open-questions list, not in\nplace of the plan.\n\n### Step 2: Define Acceptance Criteria\n\nFor each user-facing behavior, write acceptance criteria using the Given\u002FWhen\u002FThen format:\n\n```\nGiven [precondition]\nWhen [action]\nThen [expected outcome]\n```\n\nAim for 3-7 acceptance criteria per feature. Each criterion should be independently testable.\n\n### Step 3: Break Down into Tasks\n\nDecompose the feature into implementation tasks. Each task should:\n\n- Be completable in one focused session (roughly 1-4 hours of work) — state each task's estimate on the task itself, so granularity is visible rather than asserted\n- Have a single clear deliverable (a file, a test, a migration, etc.)\n- Follow dependency order (what must exist before this task can start)\n- Be independently verifiable\n\nUse this structure for each task — see [templates\u002Ftask.md](templates\u002Ftask.md).\n\nWhen a task adds a library, run `dependency-management`'s Step 1 on it before writing the task, including a library an RFC, ADR or issue already names, and put the verdict in the plan's **New dependencies** section: own module, adopt, or a question for the user. A plan that lists a library with only a check that it exists hasn't done this, and neither has one that schedules the check as a later task.\n\n### Step 4: Map Dependencies\n\nIdentify and visualize dependencies between tasks:\n\n- **Hard dependencies**: Task B literally cannot start until Task A is done\n- **Soft dependencies**: Task B benefits from Task A but could start in parallel\n- **External dependencies**: Waiting on APIs, design assets, or decisions\n\nPresent dependencies as an ordered list or ASCII diagram showing the critical path.\n\n### Step 5: Identify Risks and Open Questions\n\nFlag anything that could derail the plan:\n\n- **Technical risks**: Unproven technology, complex integration, performance concerns\n- **Scope risks**: Feature creep indicators, ambiguous requirements\n- **Dependency risks**: External team blockers, API availability\n\nFor each risk, suggest a mitigation strategy or a spike task to reduce uncertainty.\n\n### Step 6: Produce the Plan\n\nOutput the complete plan using the template at [templates\u002Fplan.md](templates\u002Fplan.md) — in the reply itself, not as a promise to produce one. Offer to save it as a markdown file in the project (e.g., `docs\u002Fplans\u002Ffeature-name.md`); saving is a convenience, not the deliverable.\n\nIf the plan spans several sessions or milestones, fill its **Tracking** field from the project's working agreement (where task status will live). When the project has none, say so and hand off to `working-agreement` so status has a home before execution starts.\n\n## Principles Applied\n\n- **YAGNI**: Only plan what's needed now. Flag nice-to-haves separately.\n- **KISS**: Prefer the simplest approach that meets acceptance criteria.\n- **Functional Independence**: Each task should touch a single concern when possible.\n- **Testability**: Every task should specify how to verify it's done.\n\n## When to Go Deeper\n\nIf the feature involves architectural decisions (new services, database changes, API design), suggest using the `architecture-design` skill before finalizing the plan.\n\nIf the feature requires data model changes, suggest using the `data-modeling` skill for that portion.\n\nIf the idea itself is still fuzzy — the user is exploring what to build rather than how — run `brainstorming` first; this skill converges, that one diverges.\n\nOnce the plan is approved and execution begins, the `plan-execution` skill takes over: checkpointed batches, verification evidence per checkpoint, and drift-triggered re-planning (which loops back here).\n","# Feature Planning\n\nGuide the user through transforming a feature idea or requirement into a structured, actionable implementation plan. The goal is a plan that a developer (or Claude Code) can pick up and execute with minimal ambiguity.\n\n## Workflow\n\n### Step 1: Understand the Feature\n\nAsk clarifying questions to close knowledge gaps. Focus on:\n\n- **What problem does this solve?** (user pain, business value)\n- **Who is the user?** (persona, role, access level)\n- **What exists today?** (current behavior, workarounds)\n- **What are the constraints?** (timeline, tech stack, backwards compatibility)\n- **What's out of scope?** (explicitly define boundaries)\n- **How will we know it works?** (what verification and test coverage this needs)\n\n**This step is not a gate on delivering.** Whether you draft now or ask first is\na condition, not a preference. Apply this test:\n\n> Can you write at least one Given\u002FWhen\u002FThen acceptance criterion **without\n> inventing the feature's core behavior?**\n\n- **Yes → draft now.** The remaining unknowns are assumptions, not blockers:\n  state them and carry the full plan **in the same response**. A draft the user\n  corrects beats a question they must answer. (\"Email and in-app notifications\n  when someone comments on their posts\" passes — the behavior is given.)\n- **No → ask first**, and say what you'd need to start drafting. A named stack\n  plus a feature label is not enough on its own: \"add dark mode to our Vue app\"\n  and \"add authentication\" both fail the test, because the core behavior\n  (persistence? system-preference default? which auth methods, which protected\n  resources, which roles?) would have to be invented rather than planned.\n\n**Exit condition for the draft branch** — one line, then keep going in the same\nresponse: *\"Planning under these assumptions: `\u003C…>` — correct any and I'll\nrevise.\"*\n\nNever answer a planning request with questions alone when the draft branch\napplies. Unanswered questions belong in Step 5's open-questions list, not in\nplace of the plan.\n\n### Step 2: Define Acceptance Criteria\n\nFor each user-facing behavior, write acceptance criteria using the Given\u002FWhen\u002FThen format:\n\n```\nGiven [precondition]\nWhen [action]\nThen [expected outcome]\n```\n\nAim for 3-7 acceptance criteria per feature. Each criterion should be independently testable.\n\n### Step 3: Break Down into Tasks\n\nDecompose the feature into implementation tasks. Each task should:\n\n- Be completable in one focused session (roughly 1-4 hours of work) — state each task's estimate on the task itself, so granularity is visible rather than asserted\n- Have a single clear deliverable (a file, a test, a migration, etc.)\n- Follow dependency order (what must exist before this task can start)\n- Be independently verifiable\n\nUse this structure for each task — see [templates\u002Ftask.md](templates\u002Ftask.md).\n\nWhen a task adds a library, run `dependency-management`'s Step 1 on it before writing the task, including a library an RFC, ADR or issue already names, and put the verdict in the plan's **New dependencies** section: own module, adopt, or a question for the user. A plan that lists a library with only a check that it exists hasn't done this, and neither has one that schedules the check as a later task.\n\n### Step 4: Map Dependencies\n\nIdentify and visualize dependencies between tasks:\n\n- **Hard dependencies**: Task B literally cannot start until Task A is done\n- **Soft dependencies**: Task B benefits from Task A but could start in parallel\n- **External dependencies**: Waiting on APIs, design assets, or decisions\n\nPresent dependencies as an ordered list or ASCII diagram showing the critical path.\n\n### Step 5: Identify Risks and Open Questions\n\nFlag anything that could derail the plan:\n\n- **Technical risks**: Unproven technology, complex integration, performance concerns\n- **Scope risks**: Feature creep indicators, ambiguous requirements\n- **Dependency risks**: External team blockers, API availability\n\nFor each risk, suggest a mitigation strategy or a spike task to reduce uncertainty.\n\n### Step 6: Produce the Plan\n\nOutput the complete plan using the template at [templates\u002Fplan.md](templates\u002Fplan.md) — in the reply itself, not as a promise to produce one. Offer to save it as a markdown file in the project (e.g., `docs\u002Fplans\u002Ffeature-name.md`); saving is a convenience, not the deliverable.\n\nIf the plan spans several sessions or milestones, fill its **Tracking** field from the project's working agreement (where task status will live). When the project has none, say so and hand off to `working-agreement` so status has a home before execution starts.\n\n## Principles Applied\n\n- **YAGNI**: Only plan what's needed now. Flag nice-to-haves separately.\n- **KISS**: Prefer the simplest approach that meets acceptance criteria.\n- **Functional Independence**: Each task should touch a single concern when possible.\n- **Testability**: Every task should specify how to verify it's done.\n\n## When to Go Deeper\n\nIf the feature involves architectural decisions (new services, database changes, API design), suggest using the `architecture-design` skill before finalizing the plan.\n\nIf the feature requires data model changes, suggest using the `data-modeling` skill for that portion.\n\nIf the idea itself is still fuzzy — the user is exploring what to build rather than how — run `brainstorming` first; this skill converges, that one diverges.\n\nOnce the plan is approved and execution begins, the `plan-execution` skill takes over: checkpointed batches, verification evidence per checkpoint, and drift-triggered re-planning (which loops back here).\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fsecurity\u002Fskills\u002Ffeature-planning","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 feature-planning",{"tool":62,"command":63},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill feature-planning",{"tool":65,"command":66},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill feature-planning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Ffeature-planning\u002FSKILL.md",true,[70,76,80],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"evals\u002Fevals.json","REFERENCE","参考文档",4714,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Ffeature-planning\u002Fevals\u002Fevals.json",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"templates\u002Fplan.md",1659,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Ffeature-planning\u002Ftemplates\u002Fplan.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"templates\u002Ftask.md",611,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fsecurity\u002Fskills\u002Ffeature-planning\u002Ftemplates\u002Ftask.md",[85,127,153,177,210,240],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":106,"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",[91,94,97,98,103],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":104,"categoryName":105,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000040","财务",[107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126],"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":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":134,"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",[133],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[135,136,137,138,139,140,141,142,38,143,144,145,146,147,148,149,150,151,119,152],"working agreement","project","definition of done","done","milestone","documentation","work","progress","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"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",[159],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[161,162,163,164,165,166,107,167,138,168,169,170,141,171,144,172,173,174,175,176],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":190,"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",[183,186,187],{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":188,"categoryName":189,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000032","设计师",[191,192,193,194,195,196,197,198,199,200,201,202,38,203,204,205,206,207,208,209],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":220,"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",[216,217],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":218,"categoryName":219,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000030","开发工程师",[221,222,223,224,225,226,191,227,228,229,230,231,232,233,234,235,236,237,238,239],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":244,"categories":245,"keywords":251,"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",[246,247,248,249,250],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":218,"categoryName":219,"taxonomyType":101,"taxonomyTypeDesc":102},{"categoryNo":188,"categoryName":189,"taxonomyType":101,"taxonomyTypeDesc":102},[191,252,253,254,255,256,109,257,258,167,230,259,37,111,260,261,149,262,263,119],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","add","infrastructure","test plan","for"]