[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M719NMWH7M49CSX17DBJYCE1":3,"skill-same:01M719NMWH7M49CSX17DBJYCE1":98},{"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":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M719NMWH7M49CSX17DBJYCE1","testing-conventions",null,"Enforces testing standards when writing unit tests, integration tests, or agent evaluation tests. Covers test directory structure, naming conventions, fixture and setup patterns, mocking strategy, async testing, coverage requirements, and LLM-as-judge evaluation. Language-specific conventions (Python\u002Fpytest, Java\u002FJUnit, C#\u002FxUnit, React\u002FVitest) are loaded from bundled reference packs. Use this skill when writing tests, creating test files, setting up fixtures, mocking services, or reviewing test code for standards compliance.","sandeep-mewara\u002Flifecycle-agent-orchestrator","sandeep-mewara","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22136242?v=4","01M719M4609V9R414KB797CMRG","Sandeep Mewara","01M719M4700Q6AQQYT5EE5Z2DG",1,"MIT","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","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],"testing conventions","conventions","testing","pytest","patterns","judge","Evaluation","LLM-as-Judge","directory","structure","react","code","testing standards","when","writing","files","up","fixture","unit","coverage","2026-11-10 10:12:30",false,"---\nname: testing-conventions\ndescription: Enforces testing standards when writing unit tests, integration tests, or agent evaluation tests. Covers test directory structure, naming conventions, fixture and setup patterns, mocking strategy, async testing, coverage requirements, and LLM-as-judge evaluation. Language-specific conventions (Python\u002Fpytest, Java\u002FJUnit, C#\u002FxUnit, React\u002FVitest) are loaded from bundled reference packs. Use this skill when writing tests, creating test files, setting up fixtures, mocking services, or reviewing test code for standards compliance.\n---\n\n# Testing Standards\n\nStandards for testing across your services. Tests follow a layered strategy: fast unit tests for isolated logic, integration tests for service interactions, and agent evaluation tests for LLM quality gates in CI\u002FCD.\n\n**Bundled references** (read when you need the checklist):\n- `references\u002Fchecklist.md` — Universal test review checklist\n- `references\u002F\u003Clanguage>\u002Fchecklist.md` — Language-specific test checklist\n\nWhere `\u003Clanguage>` is `python`, `java`, `csharp`, or `react` — determined by the project's `lao.config.yaml` or auto-detected at pipeline start. Multi-language projects load all detected packs; apply each to files of its language.\n\nSee PROJECT.md for service-specific test directory structure, test commands, evaluation dataset details, and CI pipeline integration.\n\n---\n\n## Test Directory Structure\n\nTests mirror the source layout and are separated by type:\n\n```\ntest\u002F (or tests\u002F)\n    unit\u002F\n        \u003Cmodule_dirs>\u002F           # Mirror source directory structure\n            test_\u003Cmodule>.*      # One test file per source module\n    integration\u002F\n        test_\u003Cfeature>.*         # Feature-level integration tests\n```\n\n**Key rules:**\n- File naming mirrors the source file it tests\n- Directory structure mirrors the source tree\n- Unit tests and integration tests in separate directories\n- Test configuration specifies default test path (usually unit tests)\n\n---\n\n## Test Markers \u002F Categories\n\nThree categories drive the test pyramid:\n\n| Category | Purpose | Speed | External Deps |\n|---|---|---|---|\n| **Unit** | Isolated logic, no external dependencies | Fast (ms) | None |\n| **Integration** | Service interactions, mocked infrastructure | Medium (s) | Mocked or containerized |\n| **Agent Evaluation** | LLM-based quality assessment | Slow (min) | LLM API access |\n\nAgent evaluation tests are excluded from regular test runs and execute separately in CI.\n\nSee `references\u002F\u003Clanguage>\u002Fchecklist.md` for how to mark tests in your language's framework.\n\n---\n\n## Fixture and Setup Conventions\n\n### Unit test fixtures — minimal, no external deps\n\n- Create minimal configuration with external integrations disabled\n- Fixtures provide pre-built objects (mock requests, contexts, configs)\n- Each test is independent — no ordering dependencies between tests\n\n### Integration test fixtures — session-scoped, richer setup\n\n- Expensive setup (app creation, client initialization) happens once per test session\n- Infrastructure (secrets, auth) mocked before app creation\n- Cleanup via teardown hooks for clients that need shutdown\n\nSee PROJECT.md for specific fixture implementations and mock targets.\n\n---\n\n## Unit Test Patterns\n\n### Async testing\n\n- Use the language's async test support for testing async\u002Fawait code\n- Mock async method calls appropriately (async mocks, not sync mocks)\n- Verify async error propagation paths\n\n### Error mapping tests\n\nEach external error type gets its own test verifying it maps to the correct domain exception. Don't combine multiple error types into one test.\n\n### Mocking strategy\n\n- **Mock at boundaries** — external services, databases, third-party APIs\n- **Don't mock internal logic** — if you need to mock the function you're testing, the design needs refactoring\n- **Prefer fakes over mocks** for complex dependencies (in-memory database, fake HTTP server)\n- **One mock assertion per concept** — don't verify every method call, verify the behavior you care about\n\n### Test naming\n\nTests describe the scenario, not the implementation:\n\n```\nGood: test_report_generation_fails_when_data_missing\n      createOrder_emptyItems_throwsBadRequest\n      ProcessOrderAsync_ValidRequest_ReturnsOrderWithId\n\nBad:  test_report_1\n      testMethod3\n      Test1\n```\n\nPattern: `\u003Cmethod>_\u003Cscenario>_\u003Cexpected result>`\n\n---\n\n## Integration Test Patterns\n\n### API endpoint testing\n\n- Start the application in test mode with mocked external dependencies\n- Send real HTTP requests through the test client\n- Verify response status codes, body structure, and headers\n- Test both success and error paths\n\n### Auth testing\n\n- Verify that authenticated endpoints reject unauthenticated requests\n- Verify that authorization scoping works (user A can't access user B's data)\n- Test the gateway\u002Fmiddleware auth flow, not just the endpoint logic\n\n---\n\n## Agent Evaluation Testing\n\nLLM-as-a-judge evaluation integrated into CI\u002FCD. This is a standard pattern for measuring agent quality.\n\n### How it works\n\n1. **Golden dataset** — test cases with prompts and reference answers\n2. **Agent invocation** — run the agent against each test case\n3. **Multi-judge evaluation** — LLM judges score responses on configurable dimensions (correctness, hallucination, tool usage)\n4. **Quality gates** — pass\u002Ffail based on configurable thresholds\n5. **Metrics reporting** — results published for tracking over time\n\n### Evaluation config\n\n```json\n{\n  \"dataset_name\": \"agent-golden-dataset\",\n  \"agent_name\": \"my-agent\",\n  \"eval_mode\": \"offline\",\n  \"judges\": [\n    {\"type\": \"llm\", \"name\": \"correctness\", \"prompt\": \"CORRECTNESS_PROMPT\", \"threshold\": 0.7},\n    {\"type\": \"llm\", \"name\": \"hallucination\", \"prompt\": \"HALLUCINATION_PROMPT\", \"threshold\": 0.8},\n    {\"type\": \"code\", \"name\": \"tool_call\", \"function\": \"tool_call_evaluator\"}\n  ],\n  \"primary_metric\": \"WEIGHTED_AVG\",\n  \"pm_quality_acceptance_threshold\": 0.7\n}\n```\n\n### Test dataset format\n\n```csv\nprompt,reference,tools_called\n\"What is the product?\",\"The product is...\",\"[]\"\n\"How do I perform action X?\",\"Go to Settings > Action X\",\"[\"\"knowledge_retriever\"\"]\"\n```\n\nSee PROJECT.md for the specific dataset, judges, thresholds, and CI pipeline integration for agent evaluation.\n\n---\n\n## Coverage Requirements\n\n- **Line coverage:** >=85% for new code\n- **Branch coverage:** measured and reported alongside line coverage\n- **Coverage is not a goal in itself** — test quality matters more than coverage percentage\n- Tests should verify behavior, not just execute code paths\n- Assertions must be meaningful — not just \"it didn't crash\"\n\n---\n\nBefore committing tests, consult `references\u002Fchecklist.md` and `references\u002F\u003Clanguage>\u002Fchecklist.md` for the verification checklist.\n","# Testing Standards\n\nStandards for testing across your services. Tests follow a layered strategy: fast unit tests for isolated logic, integration tests for service interactions, and agent evaluation tests for LLM quality gates in CI\u002FCD.\n\n**Bundled references** (read when you need the checklist):\n- `references\u002Fchecklist.md` — Universal test review checklist\n- `references\u002F\u003Clanguage>\u002Fchecklist.md` — Language-specific test checklist\n\nWhere `\u003Clanguage>` is `python`, `java`, `csharp`, or `react` — determined by the project's `lao.config.yaml` or auto-detected at pipeline start. Multi-language projects load all detected packs; apply each to files of its language.\n\nSee PROJECT.md for service-specific test directory structure, test commands, evaluation dataset details, and CI pipeline integration.\n\n---\n\n## Test Directory Structure\n\nTests mirror the source layout and are separated by type:\n\n```\ntest\u002F (or tests\u002F)\n    unit\u002F\n        \u003Cmodule_dirs>\u002F           # Mirror source directory structure\n            test_\u003Cmodule>.*      # One test file per source module\n    integration\u002F\n        test_\u003Cfeature>.*         # Feature-level integration tests\n```\n\n**Key rules:**\n- File naming mirrors the source file it tests\n- Directory structure mirrors the source tree\n- Unit tests and integration tests in separate directories\n- Test configuration specifies default test path (usually unit tests)\n\n---\n\n## Test Markers \u002F Categories\n\nThree categories drive the test pyramid:\n\n| Category | Purpose | Speed | External Deps |\n|---|---|---|---|\n| **Unit** | Isolated logic, no external dependencies | Fast (ms) | None |\n| **Integration** | Service interactions, mocked infrastructure | Medium (s) | Mocked or containerized |\n| **Agent Evaluation** | LLM-based quality assessment | Slow (min) | LLM API access |\n\nAgent evaluation tests are excluded from regular test runs and execute separately in CI.\n\nSee `references\u002F\u003Clanguage>\u002Fchecklist.md` for how to mark tests in your language's framework.\n\n---\n\n## Fixture and Setup Conventions\n\n### Unit test fixtures — minimal, no external deps\n\n- Create minimal configuration with external integrations disabled\n- Fixtures provide pre-built objects (mock requests, contexts, configs)\n- Each test is independent — no ordering dependencies between tests\n\n### Integration test fixtures — session-scoped, richer setup\n\n- Expensive setup (app creation, client initialization) happens once per test session\n- Infrastructure (secrets, auth) mocked before app creation\n- Cleanup via teardown hooks for clients that need shutdown\n\nSee PROJECT.md for specific fixture implementations and mock targets.\n\n---\n\n## Unit Test Patterns\n\n### Async testing\n\n- Use the language's async test support for testing async\u002Fawait code\n- Mock async method calls appropriately (async mocks, not sync mocks)\n- Verify async error propagation paths\n\n### Error mapping tests\n\nEach external error type gets its own test verifying it maps to the correct domain exception. Don't combine multiple error types into one test.\n\n### Mocking strategy\n\n- **Mock at boundaries** — external services, databases, third-party APIs\n- **Don't mock internal logic** — if you need to mock the function you're testing, the design needs refactoring\n- **Prefer fakes over mocks** for complex dependencies (in-memory database, fake HTTP server)\n- **One mock assertion per concept** — don't verify every method call, verify the behavior you care about\n\n### Test naming\n\nTests describe the scenario, not the implementation:\n\n```\nGood: test_report_generation_fails_when_data_missing\n      createOrder_emptyItems_throwsBadRequest\n      ProcessOrderAsync_ValidRequest_ReturnsOrderWithId\n\nBad:  test_report_1\n      testMethod3\n      Test1\n```\n\nPattern: `\u003Cmethod>_\u003Cscenario>_\u003Cexpected result>`\n\n---\n\n## Integration Test Patterns\n\n### API endpoint testing\n\n- Start the application in test mode with mocked external dependencies\n- Send real HTTP requests through the test client\n- Verify response status codes, body structure, and headers\n- Test both success and error paths\n\n### Auth testing\n\n- Verify that authenticated endpoints reject unauthenticated requests\n- Verify that authorization scoping works (user A can't access user B's data)\n- Test the gateway\u002Fmiddleware auth flow, not just the endpoint logic\n\n---\n\n## Agent Evaluation Testing\n\nLLM-as-a-judge evaluation integrated into CI\u002FCD. This is a standard pattern for measuring agent quality.\n\n### How it works\n\n1. **Golden dataset** — test cases with prompts and reference answers\n2. **Agent invocation** — run the agent against each test case\n3. **Multi-judge evaluation** — LLM judges score responses on configurable dimensions (correctness, hallucination, tool usage)\n4. **Quality gates** — pass\u002Ffail based on configurable thresholds\n5. **Metrics reporting** — results published for tracking over time\n\n### Evaluation config\n\n```json\n{\n  \"dataset_name\": \"agent-golden-dataset\",\n  \"agent_name\": \"my-agent\",\n  \"eval_mode\": \"offline\",\n  \"judges\": [\n    {\"type\": \"llm\", \"name\": \"correctness\", \"prompt\": \"CORRECTNESS_PROMPT\", \"threshold\": 0.7},\n    {\"type\": \"llm\", \"name\": \"hallucination\", \"prompt\": \"HALLUCINATION_PROMPT\", \"threshold\": 0.8},\n    {\"type\": \"code\", \"name\": \"tool_call\", \"function\": \"tool_call_evaluator\"}\n  ],\n  \"primary_metric\": \"WEIGHTED_AVG\",\n  \"pm_quality_acceptance_threshold\": 0.7\n}\n```\n\n### Test dataset format\n\n```csv\nprompt,reference,tools_called\n\"What is the product?\",\"The product is...\",\"[]\"\n\"How do I perform action X?\",\"Go to Settings > Action X\",\"[\"\"knowledge_retriever\"\"]\"\n```\n\nSee PROJECT.md for the specific dataset, judges, thresholds, and CI pipeline integration for agent evaluation.\n\n---\n\n## Coverage Requirements\n\n- **Line coverage:** >=85% for new code\n- **Branch coverage:** measured and reported alongside line coverage\n- **Coverage is not a goal in itself** — test quality matters more than coverage percentage\n- Tests should verify behavior, not just execute code paths\n- Assertions must be meaningful — not just \"it didn't crash\"\n\n---\n\nBefore committing tests, consult `references\u002Fchecklist.md` and `references\u002F\u003Clanguage>\u002Fchecklist.md` for the verification checklist.\n",{"name":5,"description":7},"main","7df021855a805acbcdc470d3b4419009e57f0330","plugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions",0,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator","https:\u002F\u002Flearnbyinsight.com\u002F2026\u002F04\u002F19\u002Fthe-lifecycle-is-the-product-ai-development-engine\u002F","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara","https:\u002F\u002Flearnbyinsight.com\u002F","A software professional for more than 15+ years learning ...","2026-04-20 00:49:35",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill testing-conventions",{"tool":68,"command":69},"bunx","bunx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill testing-conventions",{"tool":71,"command":72},"pnpm","pnpm dlx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill testing-conventions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002FSKILL.md",true,[76,82,86,90,94],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fchecklist.md","REFERENCE","参考文档",1709,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002Freferences\u002Fchecklist.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fcsharp\u002Fchecklist.md",1556,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002Freferences\u002Fcsharp\u002Fchecklist.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fjava\u002Fchecklist.md",1561,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002Freferences\u002Fjava\u002Fchecklist.md",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fpython\u002Fchecklist.md",2568,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002Freferences\u002Fpython\u002Fchecklist.md",{"path":95,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Freact\u002Fchecklist.md",2043,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002Freferences\u002Freact\u002Fchecklist.md",[99,115,134,141,165,192],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":47},"01M719NW8TNRJGM3T22XC1HS1Y","extra-role","A custom project-specific role for testing","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Ftests\u002Ffixtures\u002Fvalid-project\u002Fextra-role\u002FSKILL.md",[],[106,107,108,109,110,111,38,112,29,113,114],"role","extra role","extra","review","architecture","code-review","custom","project","for",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":47},"01M719NTA6SXBZ2VG2YX7PT1G8","compliance-review","Ensures regulatory compliance for financial services","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Ftests\u002Ffixtures\u002Fvalid-config\u002Ftools\u002Fcompliance\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[109,127,128,111,110,38,129,130,131,114,132,133],"compliance review","compliance","security","regulatory compliance","regulatory","financial services","services",{"skillNo":135,"name":101,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":47},"01M719NS3WX4TRDAX41V5PSSF2","A custom role missing applies_to for testing","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Ftests\u002Ffixtures\u002Fmissing-applies-to-extra\u002Fextra-role\u002FSKILL.md",[],[108,106,107,29,114,140,112],"missing",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":47},"01M719NGZVGA0C0NY8G66FNHB8","shipping","Shipping workflow for platform services. Use this skill when creating pull requests, pushing code for review, updating Jira tickets to reflect PR status, or completing the ship cycle for a feature or bugfix. Trigger this skill when the user says things like \"open a PR,\" \"create a pull request,\" \"ship this,\" \"push for review,\" \"update the ticket,\" \"mark this as ready for review,\" or \"I'm done with this feature\" — even if they don't explicitly say \"shipping.\" Also trigger when the user wants to transition a Jira ticket status after code changes are ready.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fshipping\u002FSKILL.md",[147],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[143,149,150,151,152,153,154,155,156,157,158,109,159,160,40,161,162,163,164,38],"creating pull requests","status","bugfix","jira","update","request","transition","pull requests","reflect","create","done","workflow","open","ticket","cycle","ready",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":176,"publishedAt":47},"01M719NCJ3BNN5AXQ1V1FDYCJS","security-standards","Enforces security standards when writing or reviewing code that handles authentication, secrets, sensitive data, API boundaries, or compliance concerns. Covers secrets manager integration, encryption at rest and in transit, IAM authentication and least-privilege authorization, OWASP Top 10 secure coding (including prompt injection), dependency vulnerability management, API security (auth, validation, rate limiting), PII and sensitive data protection in logs and traces, and regulatory compliance (CCPA\u002FGDPR). Use this skill when adding endpoints, handling user data, managing secrets, reviewing for vulnerabilities, configuring auth, working with LLM prompts that accept user input, setting up deployment security, or assessing compliance. Also use when DAST findings need remediation.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fsecurity\u002FSKILL.md",[171,172,175],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":173,"categoryName":174,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[177,129,178,179,180,181,43,182,183,184,185,186,187,188,189,38,190,40,41,191],"security standards","standards","authentication","auth","pii","top","remediation","dependency","owasp top 10","iam","logs","api","vulnerability","encryption","prompt injection",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":205,"publishedAt":47},"01M719N83RCT50QAV6BPH608WW","product-manager","Product management workflows: write PRDs and spec documents, create user stories with acceptance criteria and T-shirt sizing, plan and prioritize roadmaps by quarter, run competitor and market analysis with live web research, and review Figma designs against PRD requirements for UX consistency. Use this skill whenever the user mentions PRDs, product requirements, user stories, acceptance criteria, story points, roadmaps, feature prioritization, competitor analysis, market research, or reviewing designs against specs — even if they don't explicitly say \"product management.\" Also trigger when the user wants to create Jira-ready tickets, publish specs to Confluence, or audit Figma mockups for missing states.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fproduct-management\u002FSKILL.md",[198,199,202],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":200,"categoryName":201,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000031","产品经理",{"categoryNo":203,"categoryName":204,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000032","设计师",[206,207,208,209,210,211,212,213,158,214,109,40,215,216,217,218,219,220,164,221],"product","Product Manager","manager","analysis","audit","plan","prioritization","feature prioritization","publish","workflows","documents","acceptance","states","figma","market analysis","product management workflows"]