[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GXHH3DMZD272RVH4800C67":3,"skill-same:01M6GXHH3DMZD272RVH4800C67":72},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6GXHH3DMZD272RVH4800C67","Test Conventions",null,"Testing patterns and conventions for code review. Covers naming, AAA structure, boundary testing, mock vs real dependencies, and coverage expectations.","malayvuong\u002Fagent-orchestra","malayvuong","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13240975?v=4","01M6GXCDVPB2VPZMDZK1KF98M0","Nguyen Minh Vuong","01M6GXCE176VDX3XV4Z4KNR33J",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftest-conventions\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[27,28,5,29,30,31,32,33,34,35,36,37,38,39,40],"test","conventions","code review","testing","review","code","testing patterns","boundary","coverage","patterns","dependencies","structure","mock","naming","2026-11-10 10:12:30",false,"---\nname: Test Conventions\ndescription: Testing patterns and conventions for code review. Covers naming, AAA structure, boundary testing, mock vs real dependencies, and coverage expectations.\nversion: 2026.3.1\nlicense: MIT\ntriggers:\n  lenses:\n    - testing\n---\n\nWhen reviewing test code, apply the following conventions to assess quality and completeness.\n\n## Test Naming\n\nTest names must be readable as documentation. Use the pattern: `\u003Cunit> should \u003Cbehavior> when \u003Ccondition>`. For example: `getUserById should return null when user does not exist`. Avoid names like `test1`, `works`, or `happy path`. Describe the observable behavior, not the implementation detail.\n\n## Arrange-Act-Assert Structure\n\nEvery test should follow the AAA pattern with a blank line separating each phase. Flag tests that perform multiple actions or mix assertions with setup. The Act phase should contain exactly one call to the unit under test. Verify that the assertion validates only the outcome of that single action.\n\n## Boundary and Edge Cases\n\nCheck that tests cover: empty inputs, null\u002Fundefined values, zero and negative numbers, maximum boundary values, empty arrays and objects, and strings with special characters. Flag tests that only cover the happy path. For numeric logic, verify off-by-one boundaries are tested.\n\n## Mock vs Real Dependencies\n\nReal implementations should be used for: pure functions, value objects, and domain logic. Mocks are appropriate for: external HTTP services, databases, file system, clocks, and random number generators. Flag over-mocking — when a unit test mocks the very collaborator it is supposed to test through. Verify mocks are reset between tests to prevent state leakage.\n\n## Test Isolation\n\nEach test must be independently executable. Flag shared mutable state between tests (module-level variables mutated in tests). Verify `beforeEach`\u002F`afterEach` cleanup is complete. Check that test execution order does not affect results.\n\n## Coverage Expectations\n\nCritical paths (authentication, payment, data mutation) should have explicit branch coverage for both success and failure paths. Flag untested error handling branches. When reviewing new features, verify that at minimum: the primary success path, at least one failure path, and edge case inputs are covered.\n\n## Assertion Quality\n\nAssertions must be specific. Flag `expect(result).toBeTruthy()` where `expect(result).toBe(true)` is appropriate. Avoid asserting on irrelevant properties. For collections, verify both membership and order when order matters.\n","When reviewing test code, apply the following conventions to assess quality and completeness.\n\n## Test Naming\n\nTest names must be readable as documentation. Use the pattern: `\u003Cunit> should \u003Cbehavior> when \u003Ccondition>`. For example: `getUserById should return null when user does not exist`. Avoid names like `test1`, `works`, or `happy path`. Describe the observable behavior, not the implementation detail.\n\n## Arrange-Act-Assert Structure\n\nEvery test should follow the AAA pattern with a blank line separating each phase. Flag tests that perform multiple actions or mix assertions with setup. The Act phase should contain exactly one call to the unit under test. Verify that the assertion validates only the outcome of that single action.\n\n## Boundary and Edge Cases\n\nCheck that tests cover: empty inputs, null\u002Fundefined values, zero and negative numbers, maximum boundary values, empty arrays and objects, and strings with special characters. Flag tests that only cover the happy path. For numeric logic, verify off-by-one boundaries are tested.\n\n## Mock vs Real Dependencies\n\nReal implementations should be used for: pure functions, value objects, and domain logic. Mocks are appropriate for: external HTTP services, databases, file system, clocks, and random number generators. Flag over-mocking — when a unit test mocks the very collaborator it is supposed to test through. Verify mocks are reset between tests to prevent state leakage.\n\n## Test Isolation\n\nEach test must be independently executable. Flag shared mutable state between tests (module-level variables mutated in tests). Verify `beforeEach`\u002F`afterEach` cleanup is complete. Check that test execution order does not affect results.\n\n## Coverage Expectations\n\nCritical paths (authentication, payment, data mutation) should have explicit branch coverage for both success and failure paths. Flag untested error handling branches. When reviewing new features, verify that at minimum: the primary success path, at least one failure path, and edge case inputs are covered.\n\n## Assertion Quality\n\nAssertions must be specific. Flag `expect(result).toBeTruthy()` where `expect(result).toBe(true)` is appropriate. Avoid asserting on irrelevant properties. For collections, verify both membership and order when order matters.\n",{"name":5,"license":15,"version":46,"triggers":47,"description":7},"2026.3.1",{"lenses":48},[30],"main","eac6069a8690d89fd23f08d2d14e4874ed376a77",".agent-orchestra\u002Fskills\u002Ftest-conventions",0,"https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002Fmalayvuong","www.malayvuong.com","Just a newbie at everything","2026-10-09 12:52:45",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add malayvuong\u002Fagent-orchestra --skill \"Test Conventions\"",{"tool":64,"command":65},"bunx","bunx skills add malayvuong\u002Fagent-orchestra --skill \"Test Conventions\"",{"tool":67,"command":68},"pnpm","pnpm dlx skills add malayvuong\u002Fagent-orchestra --skill \"Test Conventions\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftest-conventions\u002FSKILL.md",true,[],[73,113,131,149,169,188],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":93,"publishedAt":41},"01M6GXHYPRJ43SHFPFJTF87GS8","Vue.js Review","Deep review of Vue.js applications — Composition API patterns, reactivity traps, component design, Pinia state management, and performance pitfalls.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fvue-review\u002FSKILL.md",[79,82,85,88],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[31,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112],"vue","js","Vue js Review","design","performance","component","state management","state","deep review","api patterns","applications","api","Composition","pinia","management","deep","logic","pitfalls","pinia state",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":41},"01M6GXHSPDDH1PQEN61ENMCEF5","Unity Review","Deep review of Unity C# code — object pooling, Update allocation, physics patterns, UI performance, serialization, and mobile optimization.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Funity-review\u002FSKILL.md",[],[31,120,115,98,121,32,102,122,123,124,125,36,126,109,110,127,128,129,130],"unity","update","ui","serialization","Optimization","mobile","physics","C#","mobile optimization","object","allocation",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":41},"01M6GXHNKTH12CGSRWDGF2H1Q9","TypeScript Review","Deep review of TypeScript code — type safety, generics patterns, strict mode compliance, type narrowing, module boundaries, and common escape hatches.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftypescript-review\u002FSKILL.md",[],[31,138,139,32,102,140,141,142,143,36,109,110,144,145,146,147,148],"typescript","typescript review","compliance","Type Safety","Safety","common","module","type","interface","consistency","mode",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":159,"publishedAt":41},"01M6GXHCAQSJDVNVRFFD1HJWTN","Terraform Review","Deep review of Terraform\u002FOpenTofu configuration — state management, module design, security hardening, drift prevention, and production safety patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fterraform-review\u002FSKILL.md",[155,158],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[31,160,151,97,161,100,101,102,162,163,164,165,142,166,108,167,168,109,110,144],"terraform","security","cloud","aws","hardening","Production","opentofu","iac","drift",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":41},"01M6GXH83F11CK4BQEAJPN6HDE","Swift Review","Deep review of Swift code — memory management, concurrency patterns, optionals, protocol design, SwiftUI lifecycle, and iOS platform patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fswift-review\u002FSKILL.md",[175],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[177,31,171,97,178,98,32,179,102,180,181,182,183,184,108,109,110,185,186,187],"swift","memory","protocol","ios","concurrency","lifecycle","swiftui","uikit","xcode","apple","platform",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":198,"publishedAt":41},"01M6GXH22YZZ9AES24EB27BGNX","SQL Query Review","Deep review of SQL queries — execution plans, index utilization, join efficiency, subquery patterns, locking behavior, and performance anti-patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fsql-query-review\u002FSKILL.md",[194,195],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":196,"categoryName":197,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000033","数据分析师",[31,199,200,190,98,102,201,202,203,204,205,206,207,208,209,210,109,110,211,212],"sql","query","index","execution","explain","select","behavior","utilization","anti-patterns","sql queries","queries","efficiency","plans","join"]