{"id":"3c970ce6-aaf0-4867-9567-b72e36ac8e49","entityType":"agent","slug":"clawhub-gechengling-agentic-test-engineer","name":"Agentic Test Engineer","canonicalUrl":"https://www.xpersona.co/agent/clawhub-gechengling-agentic-test-engineer","canonicalPath":"/agent/clawhub-gechengling-agentic-test-engineer","generatedAt":"2026-10-13T06:52:36.068Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T23:21:47.252Z","emptyReason":null},"description":"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA. Skill: Agentic Test Engineer Owner: gechengling Summary: AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test dete","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 977 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17ewqc4f2s6gpcbm88hy7fgvn85kg1g:agentic-test-engineer","sourceUrl":"https://clawhub.ai/gechengling/agentic-test-engineer","homepage":"https://clawhub.ai/gechengling/skills/agentic-test-engineer","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/gechengling/agentic-test-engineer","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/gechengling/skills/agentic-test-engineer","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors,"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T23:21:47.252Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T23:21:47.252Z","emptyReason":null},"stars":null,"forks":null,"downloads":977,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.0.2","tractionLabel":"977 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T23:21:47.238Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T23:21:47.252Z","lastCrawledAt":"2026-10-11T23:21:47.238Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T23:21:47.238Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.2","createdAt":"2026-09-28T05:19:17.039Z","changelog":"修正minimal human intervention自相矛盾表述；新增Scope and Data-Handling Policy（SQP-1/SQP-2）含SaaS厂商六问清单与测试数据最小化规则；三张表各新增一列；新增Example 6截图外发决策；生态动态更新至2026-09-28","fileCount":3,"zipByteSize":12757},{"version":"1.0.1","createdAt":"2026-09-10T05:24:07.020Z","changelog":"1.0.1: Step2-5各补实例、自愈禁用场景表、覆盖率分级表、能力表扩至7列7行、示例4-5、生态现状(截至2026-09-10)、明确执行边界","fileCount":3,"zipByteSize":10472},{"version":"1.0.0","createdAt":"2026-05-19T12:06:23.229Z","changelog":"Agentic Test Engineer 1.0.0 – Initial Release - Introduces an AI-powered assistant for autonomous test generation and self-healing test maintenance. - Supports generating unit, integration, E2E, and API tests from code or user stories. - Automates flaky test detection and diagnosis, providing root cause analysis and repair suggestions. - Auto-fixes broken selectors in UI tests using visual AI and multiple selector strategies. - Includes test coverage analysis and suggests new tests for uncovered code. - Provides workflow triggers, detailed step-by-step processes, and practical input/output examples for QA and development teams.","fileCount":3,"zipByteSize":5002}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ewqc4f2s6gpcbm88hy7fgvn85kg1g:agentic-test-engineer","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-13T06:52:36.067Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-gechengling-agentic-test-engineer/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T23:21:47.252Z","emptyReason":null},"readme":"Skill: Agentic Test Engineer\n\nOwner: gechengling\n\nSummary: AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA.\n\nTags: agentic-test-engineer:1.0.2, latest:1.0.2\n\nVersion history:\n\nv1.0.2 | 2026-09-28T05:19:17.039Z | user\n\n修正minimal human intervention自相矛盾表述；新增Scope and Data-Handling Policy（SQP-1/SQP-2）含SaaS厂商六问清单与测试数据最小化规则；三张表各新增一列；新增Example 6截图外发决策；生态动态更新至2026-09-28\n\nv1.0.1 | 2026-09-10T05:24:07.020Z | user\n\n1.0.1: Step2-5各补实例、自愈禁用场景表、覆盖率分级表、能力表扩至7列7行、示例4-5、生态现状(截至2026-09-10)、明确执行边界\n\nv1.0.0 | 2026-05-19T12:06:23.229Z | auto\n\nAgentic Test Engineer 1.0.0 – Initial Release\n\n- Introduces an AI-powered assistant for autonomous test generation and self-healing test maintenance.\n- Supports generating unit, integration, E2E, and API tests from code or user stories.\n- Automates flaky test detection and diagnosis, providing root cause analysis and repair suggestions.\n- Auto-fixes broken selectors in UI tests using visual AI and multiple selector strategies.\n- Includes test coverage analysis and suggests new tests for uncovered code.\n- Provides workflow triggers, detailed step-by-step processes, and practical input/output examples for QA and development teams.\n\nArchive index:\n\nArchive v1.0.2: 3 files, 12757 bytes\n\nFiles: skill-card.md (1996b), SKILL.md (26694b), _meta.json (140b)\n\nFile v1.0.2:SKILL.md\n\n---\r\nname: \"Agentic Test Engineer\"\r\ndescription: \"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA.\"\r\nversion: \"1.0.2\"\r\n---\r\n\r\n# Agentic Test Engineer\r\n\r\n## Overview\r\n\r\nAn AI-powered autonomous testing assistant that revolutionizes QA workflows. It generates comprehensive test suites from user stories and code, self-heals broken selectors using visual AI, detects and diagnoses flaky tests, and continuously maintains test coverage metrics. It is an **advisory** skill: it\r\nproduces test code, selectors, diagnoses and configuration for you to review and run\r\nin your own CI. It does not execute tests, does not edit your repository, and does not\r\npush changes. Every healing suggestion carries a human checkpoint before merge.\r\n\r\n## Scope and Data-Handling Policy (read first)\r\n\r\n**Advisory only.** This skill drafts tests, selectors and diagnoses. It does not run\r\nthem, does not write files into your repository, and does not talk to your CI. Code\r\nblocks below are reference material to copy into your own environment.\r\n\r\n**In scope**: unit / integration / E2E / API test design, flaky-test diagnosis,\r\nselector maintenance, coverage triage, and the review policy for AI-generated tests.\r\n\r\n**Out of scope (do not activate for these)**: production incident response, security\r\npenetration testing, performance/load engineering, accessibility conformance audits,\r\nand general debugging that is not about a test. Those need their own tooling.\r\n\r\n### Third-party and SaaS test-vendor checklist (SQP-2)\r\n\r\nSelf-healing and visual-regression features are frequently delivered as a SaaS\r\nservice. That means **screenshots, DOM snapshots and sometimes test data leave your\r\nnetwork**. Confirm the following before enabling any external vendor:\r\n\r\n| Question to answer | Why it matters | Deal-breaker |\r\n|---|---|---|\r\n| Are screenshots and DOM snapshots stored outside our network? | Screenshots of a real policy or claim screen are customer data | Regulated data with no on-prem option |\r\n| Where is the data processed and for how long is it retained? | Retention turns a test artefact into a data store | Retention the vendor cannot state in writing |\r\n| Is the healing engine self-hostable? | Self-hosting removes the egress question entirely | No self-host option and no DPA |\r\n| Can we redact before upload? | Redaction is the practical middle ground | No redaction hook and no masking |\r\n| Does the vendor train on our artefacts? | Your UI may contain unreleased business logic | Training on customer data without an opt-out |\r\n| Who can access the artefact store? | Broad vendor-side access is a real exposure | Shared, unlogged access |\r\n\r\n**Data minimisation rules for test artefacts**\r\n\r\n1. Seed test data with synthetic values; never copy production records into a fixture.\r\n2. Redact account numbers, ID numbers and faces before any upload or baseline image.\r\n3. Keep DOM snapshots as short as the diagnosis needs — a page fragment, not the page.\r\n4. Treat a quarantine queue as production data: same access controls, same retention.\r\n5. If a vendor cannot answer the table above in writing, keep visual testing self-hosted.\r\n\r\n\r\n\r\n## Triggers\r\n\r\n- \"generate tests for [feature/code]\"\r\n- \"write unit tests for [function]\"\r\n- \"self-heal my broken test\"\r\n- \"find flaky tests in [project]\"\r\n- \"check test coverage for [module]\"\r\n- \"run E2E tests for [workflow]\"\r\n- \"why is my test failing\"\r\n- \"智能测试生成\"\r\n- \"自愈测试修复\"\r\n- \"测试覆盖率分析\"\r\n\r\n**Non-triggers (explicitly not this skill)**\r\n\r\n- \"the site is down, help\" → production incident response, not test design\r\n- \"load-test this endpoint at 10k rps\" → performance engineering\r\n- \"is this page WCAG compliant\" → accessibility audit\r\n- \"fix this bug in my code\" → general debugging, not a test concern\r\n\r\n## Workflow\r\n\r\n### Step 1: Detect Context\r\n\r\nIdentify the testing scenario:\r\n- **Unit tests**: Python, JavaScript, TypeScript, Java, Go functions\r\n- **Integration tests**: API endpoints, database interactions, service meshes\r\n- **E2E tests**: Browser workflows (Playwright, Cypress, Selenium)\r\n- **API tests**: REST/GraphQL endpoints, contract testing\r\n- **Flaky test diagnosis**: Test results history, timing issues, async race conditions\r\n- **Self-healing**: Broken selectors, changed DOM, moved UI elements\r\n\r\n### Step 2: Test Generation\r\n\r\nFor test generation:\r\n1. Analyze code structure, user story, or API spec\r\n2. Select appropriate testing framework:\r\n   - Python: pytest, unittest\r\n   - JavaScript/TypeScript: Jest, Vitest, Playwright, Cypress\r\n   - Java: JUnit, TestNG\r\n   - Go: testing package, testify\r\n3. Generate comprehensive test cases:\r\n   - Happy path scenarios\r\n   - Edge cases and boundary conditions\r\n   - Error handling scenarios\r\n   - Negative test cases\r\n4. Include setup/teardown fixtures\r\n5. Add data-driven test parameters\r\n\r\n**Worked micro-example — turning one user story into a case list**\r\n\r\nUser story: *\"As a policyholder, I can upload a claim document up to 10 MB.\"*\r\n\r\n| # | Case | Type | Input | Expected | Why it earns its place | Priority |\r\n|---|---|---|---|---|---|---|\r\n| 1 | Upload a 2 MB PDF | Happy | valid.pdf | Accepted, stored, ID returned | Baseline path | P0 |\r\n| 2 | Upload exactly 10 MB | Boundary | 10mb.pdf | Accepted | Off-by-one at the limit | P1 |\r\n| 3 | Upload 10 MB + 1 byte | Boundary | over.pdf | Rejected with size error | The classic boundary miss | P0 |\r\n| 4 | Upload 0-byte file | Edge | empty.pdf | Rejected, clear message | Empty file often crashes parsers | P2 |\r\n| 5 | Upload .exe renamed .pdf | Negative | fake.pdf | Rejected on content type | Extension-only validation bypass | P0 |\r\n| 6 | Upload while offline | Error | network drop | Retryable error, no data loss | Network path is untested by default | P2 |\r\n\r\nRule of thumb used above: happy path 1, boundaries 2, edge 1, negative 1, error 1.\r\nIf a generator returns 20 near-identical cases, it has enumerated values instead of risks.\r\n\r\n**Framework selection quick map**\r\n\r\n| Stack | Default choice | Add-on | Avoid when |\r\n|---|---|---|---|\r\n| Python | pytest | pytest-cov, pytest-asyncio | You need strict BDD reporting → use behave |\r\n| JS/TS (unit) | Vitest | @vitest/coverage-v8 | Legacy CommonJS with heavy jest mocks |\r\n| JS/TS (E2E) | Playwright | trace viewer | You require real Safari on old iOS |\r\n| Java | JUnit 5 | JaCoCo, AssertJ | You need data-driven Excel specs → TestNG |\r\n| Go | testing | testify, go-cover-treemap | Table-driven cases need rich diffing → gotest.tools |\r\n| API contract | Pact or OpenAPI schema check | Dredd | Provider is third-party and unstable → mock instead |\r\n\r\n\r\n### Step 3: Self-Healing (When Triggered)\r\n\r\nWhen a test breaks due to UI changes:\r\n1. Capture the failing selector/error message\r\n2. Use visual AI to identify the new element location\r\n3. Generate updated selector using multiple strategies:\r\n   - Text content matching\r\n   - Semantic role/labels\r\n   - Visual proximity to stable elements\r\n   - Shadow DOM traversal\r\n4. Validate the fix across related tests\r\n5. Log the healing action for audit trail\r\n\r\n**Worked micro-example — healing a renamed submit button**\r\n\r\n```\r\nBroken:   await page.click('.btn-primary.submit')\r\nSymptom:  Timeout 30000ms exceeded, 0 elements matched\r\nDOM now:  <button data-testid=\"policy-submit\" type=\"submit\">提交保单</button>\r\n\r\nCandidate selectors, ranked by robustness:\r\n1. page.getByTestId('policy-submit')        <- stable by contract, best\r\n2. page.getByRole('button', { name: '提交保单' })  <- semantic, i18n-aware\r\n3. page.locator('button[type=\"submit\"]')    <- structural, survives class changes\r\n4. page.getByText('提交保单')                <- brittle if copy changes\r\n\r\nChosen: 1 (with 2 as documented fallback)\r\nAudit entry: { healed_at, old_selector, new_selector, confidence: 0.82,\r\n               evidence: \"data-testid present, unique in DOM\", reviewer: pending }\r\n```\r\n\r\n**When NOT to auto-heal (stop and escalate instead)**\r\n\r\n| Situation | Why auto-heal is dangerous | Correct action |\r\n|---|---|---|\r\n| Selector resolves to 2+ elements | Silent wrong-element clicks | Fail loudly, ask for a `data-testid` |\r\n| The element is a legal/financial confirmation | Wrong click has real-world cost | Require human-authored selector |\r\n| Failure appears only in production | May be a real defect, not a test problem | File a bug, do not heal |\r\n| Healing rate > 30% of a suite in one sprint | UI is churning; tests are not the problem | Escalate to the design/dev team |\r\n| Selector change accompanies a behaviour change | Test may now assert the wrong outcome | Re-derive assertions from the spec |\r\n\r\nSelf-healing is a maintenance aid, not a substitute for a selector contract.\r\nIf you heal the same selector twice, add a `data-testid` instead.\r\n\r\n\r\n### Step 4: Flaky Test Detection\r\n\r\n1. Collect test execution history from CI/CD\r\n2. Analyze failure patterns:\r\n   - Timing issues (race conditions, async waits)\r\n   - Resource contention (DB connections, file locks)\r\n   - Environment instability\r\n   - Test interdependencies\r\n3. Generate diagnosis report with:\r\n   - Probability of flakiness\r\n   - Root cause analysis\r\n   - Recommended fixes (add explicit waits, mock external calls, etc.)\r\n\r\n**Root-cause taxonomy (use this to classify before proposing a fix)**\r\n\r\n| Category | Typical symptom | Diagnostic signal | Fix | How to verify the fix | Cheapest first check |\r\n|---|---|---|---|---|---|\r\n| Async race | Passes locally, fails in CI | Failure time clusters at start-up | Explicit waits / `expect.poll` | 50 consecutive green runs | Rerun the single test 10x in CI, not locally |\r\n| Test interdependency | Fails only in certain orders | Passes when run alone | Isolate fixtures, reset DB per test | Run in random order 10× | Run the test alone; if it passes, it is an order problem |\r\n| Shared resource | Fails under parallel load | Fails more as workers increase | Unique ports/DB schemas, no shared state | Rerun at 4× worker count | Halve the worker count and see if the rate drops |\r\n| Time dependence | Fails at month/day boundaries | Fails on specific dates | Inject a clock, freeze time | Run with 5 faked dates | Run with a frozen clock at month-end and leap day |\r\n| External dependency | Fails randomly, no code change | Network errors in logs | Mock or contract-test the boundary | Cut network, still green | Cut the network and see if it still passes |\r\n| Environment drift | Fails only on one runner | Version mismatch in logs | Pin versions, containerise | Compare runner fingerprints | Diff the runner's tool versions against a green runner |\r\n| Data pollution | Fails after other suites ran | Unexpected rows present | Transaction rollback / fresh seed | Run full suite twice in a row | Run the full suite twice back-to-back |\r\n\r\n**Severity rule**: a test that flakes more than 1 in 100 runs should be quarantined\r\nwithin one sprint. Quarantining is not the same as deleting — keep it running in a\r\nnon-blocking job so the signal is not lost.\r\n\r\n\r\n### Step 5: Coverage Analysis\r\n\r\n1. Parse code and existing test files\r\n2. Calculate line/branch/function coverage\r\n3. Identify untested code paths\r\n4. Suggest priority test cases for uncovered areas\r\n5. Generate coverage trend report\r\n\r\n**Coverage is a triage tool, not a target — prioritise like this**\r\n\r\n| Band | Current coverage | Risk profile | What to do first | What to ignore | Gate to set now |\r\n|---|---|---|---|---|---|\r\n| Critical path | 0–40% | Payment, underwriting, auth | Tests + contract tests + alerting | Mutation score | Ratchet from today, never lower; alert on regression |\r\n| Business logic | 40–70% | Pricing, eligibility rules | Property-based tests on rules | Chasing 100% line coverage | Gate on branch coverage, not line coverage |\r\n| Glue / adapters | 70–90% | Controllers, mappers | Integration tests at the boundary | Unit tests per branch | Gate at the boundary, not per branch |\r\n| Generated code | any | DTOs, clients | Exclude from coverage denominators | Manual assertions | Exclude from the denominator entirely |\r\n| Dead code | any | Unreachable | Delete it | Testing it | Delete the code instead of gating it |\r\n\r\n**Two coverage metrics that beat line coverage**\r\n\r\n1. *Mutation score* — inject small faults; a suite that still passes has blind spots.\r\n2. *Critical-path coverage* — coverage restricted to the modules that carry money or\r\n   regulatory risk. A 60% score here matters more than 95% overall.\r\n\r\n**Anti-pattern**: raising the coverage gate while the suite is flaky. You will get\r\ngreen numbers and no confidence.\r\n\r\n\r\n## Input/Output Examples\r\n\r\n### Example 1: Generate Unit Tests\r\n\r\n**Input:**\r\n```\r\nGenerate unit tests for this Python function:\r\ndef calculate_premium(age: int, health_score: float, coverage_amount: float) -> float:\r\n    if age < 18 or age > 70:\r\n        raise ValueError(\"Age must be between 18 and 70\")\r\n    base_rate = coverage_amount * 0.05\r\n    health_factor = 1.0 - (health_score / 100) * 0.3\r\n    return base_rate * health_factor\r\n```\r\n\r\n**Output:**\r\n```python\r\nimport pytest\r\nfrom your_module import calculate_premium\r\n\r\nclass TestCalculatePremium:\r\n    def test_happy_path(self):\r\n        result = calculate_premium(age=30, health_score=80, coverage_amount=100000)\r\n        assert 3000 <= result <= 5000\r\n\r\n    def test_age_boundary_18_valid(self):\r\n        result = calculate_premium(age=18, health_score=50, coverage_amount=100000)\r\n        assert result == 100000 * 0.05 * (1.0 - 0.5 * 0.3)\r\n\r\n    def test_age_boundary_70_valid(self):\r\n        result = calculate_premium(age=70, health_score=50, coverage_amount=100000)\r\n        assert isinstance(result, float)\r\n\r\n    def test_age_too_young(self):\r\n        with pytest.raises(ValueError, match=\"Age must be between\"):\r\n            calculate_premium(age=17, health_score=80, coverage_amount=100000)\r\n\r\n    def test_age_too_old(self):\r\n        with pytest.raises(ValueError, match=\"Age must be between\"):\r\n            calculate_premium(age=71, health_score=80, coverage_amount=100000)\r\n\r\n    @pytest.mark.parametrize(\"health_score,expected_factor_range\", [\r\n        (0, (0.97, 1.01)),\r\n        (50, (0.82, 0.88)),\r\n        (100, (0.69, 0.71)),\r\n    ])\r\n    def test_health_factor_bounds(self, health_score, expected_factor_range):\r\n        result = calculate_premium(age=30, health_score=health_score, coverage_amount=100000)\r\n        lower, upper = expected_factor_range\r\n        assert lower * 5000 <= result <= upper * 5000\r\n```\r\n\r\n### Example 2: Self-Healing a Broken Playwright Test\r\n\r\n**Input:**\r\n```\r\nMy Playwright test is failing: Selector \".submit-button\" not found.\r\nThe button text is \"提交保单\" now.\r\n```\r\n\r\n**Output:**\r\n```\r\n🔧 Self-Healing Analysis:\r\n- Original selector: \".submit-button\"\r\n- Issue: UI updated, element selector changed\r\n- Healed selector strategy: text-content match\r\n\r\nGenerated alternatives:\r\n1. await page.getByRole('button', { name: '提交保单' }).click()\r\n2. await page.locator('button[type=\"submit\"]').click()\r\n3. await page.getByText('提交保单').click()\r\n\r\nRecommended (most robust): Option 1\r\n- Uses semantic role binding (survives CSS class changes)\r\n- Language-aware (works with i18n updates)\r\n```\r\n\r\n### Example 3: Flaky Test Diagnosis\r\n\r\n**Input:**\r\n```\r\nDiagnose why this test is flaky:\r\nit('should load user dashboard', async () => {\r\n  const dashboard = await page.locator('.dashboard').waitFor();\r\n  const count = await dashboard.locator('.card').count();\r\n  expect(count).toBeGreaterThan(0);\r\n});\r\n```\r\n\r\n**Output:**\r\n```\r\nFlaky Test Report:\r\n- Flakiness probability: 87% (HIGH)\r\n- Root cause: Race condition between page load and element appearance\r\n\r\nRecommended fixes:\r\n1. Replace implicit waitFor() with explicit wait:\r\n   await expect(page.locator('.dashboard')).toBeVisible({ timeout: 10000 })\r\n\r\n2. Add network idle wait:\r\n   await page.waitForLoadState('networkidle')\r\n\r\n3. Use data-testid for stability:\r\n   <div data-testid=\"user-dashboard\" className=\"dashboard\">...</div>\r\n\r\n4. Add retry wrapper for truly async cases:\r\n   await expect.poll(async () => {\r\n     return await page.locator('.card').count();\r\n   }, { timeout: 10000 }).toBeGreaterThan(0);\r\n```\r\n\r\n### Example 4: Coverage triage for a legacy module\r\n\r\n**Input:**\r\n```\r\nModule: premium_calculator.py, 41% coverage, 1,800 lines, no tests for 2 years.\r\nWhere do we start? We cannot stop feature work to fix this.\r\n```\r\n\r\n**Output:**\r\n```\r\nDo not \"add tests until 80%\". Triage instead.\r\n\r\nStep 1 - Find the money paths (half a day)\r\n  Grep for the entry points actually called in production:\r\n  calculate_premium, apply_discount, validate_eligibility\r\n  These 3 functions are ~180 lines and carry all the risk.\r\n\r\nStep 2 - Characterisation tests first (2 days)\r\n  Before refactoring anything, lock in current behaviour:\r\n  - Snapshot 200 real historical inputs -> outputs into a fixture file\r\n  - Assert the module reproduces them exactly\r\n  This makes future refactoring safe even if today's behaviour is wrong.\r\n\r\nStep 3 - Add rule tests only where rules are unclear (3 days)\r\n  Boundary: age 18 / 70, health_score 0 / 100, coverage 0 / max\r\n  Negative: non-integer age, negative coverage, None\r\n  Error: missing rate table -> explicit exception, not silent 0\r\n\r\nStep 4 - Exclude the noise (1 hour)\r\n  # .coveragerc\r\n  omit = generated/*, migrations/*, */dto/*\r\n\r\nStep 5 - Set the gate where you actually are, then ratchet\r\n  Start the gate at 45% (today + small margin) and raise it only when a\r\n  pull request would otherwise pass below it. Never lower it.\r\n\r\nRealistic outcome after 1 sprint: overall ~55%, critical-path ~90%.\r\nThe second number is the one that matters.\r\n```\r\n\r\n### Example 5: A test that should not be healed\r\n\r\n**Input:**\r\n```\r\nThis Playwright test has been auto-healed 4 times this month. Should we heal it again?\r\n```\r\n\r\n**Output:**\r\n```\r\nNo. Four heals in a month is a design signal, not a maintenance event.\r\n\r\nWhat the pattern tells us:\r\n- The UI is churning faster than the test contract can follow\r\n- There is no stable selector agreement between dev and QA\r\n- Each heal silently moves the test further from the original intent\r\n- At some point the test will pass while the feature is broken\r\n\r\nRecommended sequence:\r\n1. Freeze healing on this test; mark it @quarantined with an expiry date\r\n2. Ask the dev team to add data-testid to the 3 elements involved\r\n   (a 15-minute change that removes the whole problem class)\r\n3. Re-derive the assertions from the user story, not from the current DOM\r\n4. Add the selector contract to the definition-of-done for that component\r\n\r\nEscalation trigger for management:\r\n- If >20% of the suite needed healing this month, the cost is a process problem.\r\n  One engineer adding test IDs is cheaper than an agent healing forever.\r\n\r\nHealing budget rule of thumb: at most 2 heals per selector per quarter.\r\nBeyond that, fix the contract.\r\n```\r\n\r\n### Example 6: Should we send screenshots to a SaaS visual-testing vendor?\r\n\r\n**Input:**\r\n```\r\nOur vendor's visual AI would fix our flaky selectors, but it uploads screenshots.\r\nLegal is uneasy. What do we actually need to decide?\r\n```\r\n\r\n**Output:**\r\n```\r\nThis is a data-handling decision before it is a tooling decision. Work the list:\r\n\r\n1. Classify what is in the screenshot.\r\n   A checkout page with a real name and policy number is personal data. A login\r\n   page with synthetic credentials usually is not. Most suites contain both.\r\n\r\n2. Ask the vendor the six questions in the Scope and Data-Handling Policy table,\r\n   and require written answers - not a marketing page.\r\n\r\n3. Try the middle path first: redact before upload.\r\n   Mask text nodes containing account or ID patterns, blur faces, and upload\r\n   page fragments rather than full-page captures. Many teams find this is enough.\r\n\r\n4. If redaction is insufficient, self-host the comparison.\r\n   Playwright snapshot comparison runs entirely inside your network; you lose\r\n   some convenience and keep the data.\r\n\r\n5. Whatever you choose, log it as a control.\r\n   Record which suites are allowed to egress, on what basis, and who approved it.\r\n   \"We never thought about it\" is the finding an auditor will write down.\r\n\r\nDefault answer if nobody owns the decision: do not upload. A flaky selector is\r\nan inconvenience; an uncontrolled data egress is not.\r\n```\r\n\r\n\r\n\r\n## Key Capabilities\r\n\r\n| Capability | Description | Supported Frameworks | Input you must supply | Output artifact | Main false-positive risk | Human checkpoint |\r\n|---|---|---|---|---|---|---|\r\n| Test Generation | Generate tests from code/user stories | pytest, Jest, Vitest, JUnit, Playwright, Cypress | Source file + user story or API spec | Test file + case table | Assertions mirror a buggy implementation | Review expected values against the spec |\r\n| Self-Healing | Auto-fix broken selectors | Playwright, Cypress, Selenium | Failing selector + DOM snapshot | Ranked candidate selectors + audit entry | Selector matches the wrong element | Approve before merge |\r\n| Flaky Test Detection | Diagnose intermittent failures | All major frameworks + CI logs | ≥ 30 runs of history | Root-cause report + fix list | Blaming flakiness for a real defect | Confirm with a targeted rerun |\r\n| Coverage Analysis | Measure and report test coverage | Istanbul, pytest-cov, JaCoCo | Coverage JSON/XML | Gap list + priority order | High line coverage, low assertion quality | Pair with mutation score |\r\n| API Contract Testing | Validate API schemas and responses | OpenAPI, Postman, Pact | OpenAPI spec or consumer contract | Contract report + breaking-change diff | Spec itself is stale | Re-sync spec from production traffic |\r\n| Mutation Testing (advisory) | Assess assertion strength | mutmut, Stryker, PIT | Passing suite + source | Mutation score per module | Equivalent mutants inflate the score | Sample-review surviving mutants |\r\n| Visual Regression (advisory) | Catch unintended UI change | Playwright snapshots, Percy | Baseline images | Diff images + review queue | Font/AA rendering noise | Approve or reject each diff |\r\n\r\n## Ecosystem Status (as of 2026-09-28)\r\n\r\nTooling in AI-assisted QA changes quickly. Verify each item against the\r\nproject's official releases before relying on it.\r\n\r\n| Area | What to verify | Why it matters here |\r\n|---|---|---|\r\n| Browser automation baseline | Current Playwright / Cypress / Selenium major versions | Selector APIs and auto-waiting behaviour differ by version |\r\n| Visual AI / self-healing vendors | Whether the healing engine is self-hosted or SaaS | SaaS means screenshots leave your network — a blocker for regulated data |\r\n| CI log retention | How long your CI keeps test history | Flakiness detection needs ≥ 30 runs; short retention kills the signal |\r\n| Coverage format stability | JSON/XML schema of your coverage tool | Parser breaks silently on major upgrades |\r\n| AI-generated test review policy | Your org's rule on merging generated tests | Determines the human checkpoint that must exist |\r\n\r\n**Recent dynamics (as of 2026-09-28, verify against official sources)**\r\n1. Self-healing and visual-AI testing have become common features rather than\r\n   differentiators, which shifts the buyer question from \"does it heal\" to\r\n   \"can I audit what it healed and why\".\r\n2. More teams are treating test-suite health as a production signal: flaky-test\r\n   quarantine budgets and mutation scores are appearing alongside coverage gates.\r\n3. Data-residency concerns are pushing some regulated teams away from\r\n   SaaS-based visual testing toward self-hosted snapshot comparison.\r\n4. Vendor due-diligence for AI test tooling has widened: buyers now routinely ask\r\n   where screenshots and DOM snapshots are processed, how long they are retained,\r\n   and whether they are used for training — not just whether the healing works.\r\n5. Self-hosted snapshot comparison has become a common fallback for teams that\r\n   cannot accept screenshot egress, at the cost of maintaining baselines in-repo.\r\n6. Every version number and tool name above is point-in-time; confirm upstream.\r\n\r\n## Best Practices\r\n\r\n1. **Always add `data-testid` attributes** to UI elements for stable selectors\r\n2. **Use explicit waits** instead of `sleep()` — AI will recommend optimal wait strategies\r\n3. **Keep tests isolated** — each test should be independent\r\n4. **Parameterize test data** — use data-driven tests for variant coverage\r\n5. **Review self-healed selectors** — AI suggestions should be human-verified before production\r\n\r\n## Notes\r\n\r\n- This skill produces test code, analysis and configuration for you to run in your own environment; the code blocks in this document are reference material, not commands this skill executes on your behalf\r\n- For CI/CD integration, combine with `ai-test-strategy-architect` skill\r\n- Self-healing suggestions prioritize semantic selectors over CSS class selectors\r\n- Coverage analysis requires access to test execution output files (JSON/XML format)\r\n\r\n## Changelog\r\n\r\n- **1.0.1** (2026-09-10): Added worked micro-examples to Steps 2–5 (story→case table,\r\n  selector healing with audit entry, flaky root-cause taxonomy, coverage triage bands).\r\n  Added \"when NOT to auto-heal\" table and coverage-priority table. Expanded the\r\n  capability table from 3 to 7 columns and 5 to 7 rows (input required, output artifact,\r\n  false-positive risk, human checkpoint). Added Examples 4–5. Added \"Ecosystem Status\r\n  (as of 2026-09-10)\". Clarified the execution-boundary note.\r\n- **1.0.2** (2026-09-28): Replaced the \"minimal human intervention\" claim with an\r\n  accurate statement that the skill is advisory and does not execute tests or edit\r\n  repositories. Added a \"Scope and Data-Handling Policy\" section covering the\r\n  advisory boundary, explicit out-of-scope topics and non-triggers (SQP-1), plus a\r\n  six-question SaaS/visual-testing vendor checklist and five data-minimisation rules\r\n  for test artefacts (SQP-2). Added a Priority column to the story-to-case table, a\r\n  \"Gate to set now\" column to the coverage triage table and a \"Cheapest first check\"\r\n  column to the flaky root-cause taxonomy. Added Example 6 on screenshot egress\r\n  decisions. Ecosystem status updated to 2026-09-28 with two additional dynamics.\r\n\r\n- **1.0.0** (2026-05-19): Initial version.\r\n\r\n**Last Updated**: 2026-09-28\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"agentic-test-engineer\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1790572757039\n}\n\nFile v1.0.2:skill-card.md\n\n## Description:\n\nDrafts test cases, test code, selector fixes, flaky-test diagnoses, and coverage guidance for human review without running tests or changing repositories.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gechengling](https://clawhub.ai/user/gechengling)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers and developers use this advisory skill to design unit, integration, API, and browser tests, diagnose flaky failures, propose selector repairs, and prioritize coverage gaps. They review its suggestions before running tests or merging changes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Screenshots, DOM snapshots, CI logs, and coverage files may expose sensitive information when shared with external testing services.\n\nMitigation: Use synthetic test data, redact sensitive content, limit snapshots to what is needed, and keep visual testing self-hosted unless vendor handling is approved.\n\nRisk: A suggested selector repair may hide a product regression or target the wrong element.\n\nMitigation: Review every repair before merging; stop and escalate ambiguous selectors or behavior changes instead of automatically healing them.\n\n## Reference(s):\n\n- [Agentic Test Engineer on ClawHub](https://clawhub.ai/gechengling/skills/agentic-test-engineer)\n\n## Skill Output:\n\n**Output Type(s):** [Code, Analysis, Configuration instructions, Guidance]\n\n**Output Format:** [Markdown with code blocks and tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Advisory output for human review; does not run tests, modify repositories, or access CI.]\n\n## Skill Version(s):\n\n1.0.2 (source: release metadata and frontmatter)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.1: 3 files, 10472 bytes\n\nFiles: skill-card.md (2243b), SKILL.md (20452b), _meta.json (140b)\n\nFile v1.0.1:SKILL.md\n\n---\r\nname: \"Agentic Test Engineer\"\r\ndescription: \"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA.\"\r\nversion: \"1.0.1\"\r\n---\r\n\r\n# Agentic Test Engineer\r\n\r\n## Overview\r\n\r\nAn AI-powered autonomous testing assistant that revolutionizes QA workflows. It generates comprehensive test suites from user stories and code, self-heals broken selectors using visual AI, detects and diagnoses flaky tests, and continuously maintains test coverage metrics — all with minimal human intervention.\r\n\r\n## Triggers\r\n\r\n- \"generate tests for [feature/code]\"\r\n- \"write unit tests for [function]\"\r\n- \"self-heal my broken test\"\r\n- \"find flaky tests in [project]\"\r\n- \"check test coverage for [module]\"\r\n- \"run E2E tests for [workflow]\"\r\n- \"why is my test failing\"\r\n- \"智能测试生成\"\r\n- \"自愈测试修复\"\r\n- \"测试覆盖率分析\"\r\n\r\n## Workflow\r\n\r\n### Step 1: Detect Context\r\n\r\nIdentify the testing scenario:\r\n- **Unit tests**: Python, JavaScript, TypeScript, Java, Go functions\r\n- **Integration tests**: API endpoints, database interactions, service meshes\r\n- **E2E tests**: Browser workflows (Playwright, Cypress, Selenium)\r\n- **API tests**: REST/GraphQL endpoints, contract testing\r\n- **Flaky test diagnosis**: Test results history, timing issues, async race conditions\r\n- **Self-healing**: Broken selectors, changed DOM, moved UI elements\r\n\r\n### Step 2: Test Generation\r\n\r\nFor test generation:\r\n1. Analyze code structure, user story, or API spec\r\n2. Select appropriate testing framework:\r\n   - Python: pytest, unittest\r\n   - JavaScript/TypeScript: Jest, Vitest, Playwright, Cypress\r\n   - Java: JUnit, TestNG\r\n   - Go: testing package, testify\r\n3. Generate comprehensive test cases:\r\n   - Happy path scenarios\r\n   - Edge cases and boundary conditions\r\n   - Error handling scenarios\r\n   - Negative test cases\r\n4. Include setup/teardown fixtures\r\n5. Add data-driven test parameters\r\n\r\n**Worked micro-example — turning one user story into a case list**\r\n\r\nUser story: *\"As a policyholder, I can upload a claim document up to 10 MB.\"*\r\n\r\n| # | Case | Type | Input | Expected | Why it earns its place |\r\n|---|---|---|---|---|---|\r\n| 1 | Upload a 2 MB PDF | Happy | valid.pdf | Accepted, stored, ID returned | Baseline path |\r\n| 2 | Upload exactly 10 MB | Boundary | 10mb.pdf | Accepted | Off-by-one at the limit |\r\n| 3 | Upload 10 MB + 1 byte | Boundary | over.pdf | Rejected with size error | The classic boundary miss |\r\n| 4 | Upload 0-byte file | Edge | empty.pdf | Rejected, clear message | Empty file often crashes parsers |\r\n| 5 | Upload .exe renamed .pdf | Negative | fake.pdf | Rejected on content type | Extension-only validation bypass |\r\n| 6 | Upload while offline | Error | network drop | Retryable error, no data loss | Network path is untested by default |\r\n\r\nRule of thumb used above: happy path 1, boundaries 2, edge 1, negative 1, error 1.\r\nIf a generator returns 20 near-identical cases, it has enumerated values instead of risks.\r\n\r\n**Framework selection quick map**\r\n\r\n| Stack | Default choice | Add-on | Avoid when |\r\n|---|---|---|---|\r\n| Python | pytest | pytest-cov, pytest-asyncio | You need strict BDD reporting → use behave |\r\n| JS/TS (unit) | Vitest | @vitest/coverage-v8 | Legacy CommonJS with heavy jest mocks |\r\n| JS/TS (E2E) | Playwright | trace viewer | You require real Safari on old iOS |\r\n| Java | JUnit 5 | JaCoCo, AssertJ | You need data-driven Excel specs → TestNG |\r\n| Go | testing | testify, go-cover-treemap | Table-driven cases need rich diffing → gotest.tools |\r\n| API contract | Pact or OpenAPI schema check | Dredd | Provider is third-party and unstable → mock instead |\r\n\r\n\r\n### Step 3: Self-Healing (When Triggered)\r\n\r\nWhen a test breaks due to UI changes:\r\n1. Capture the failing selector/error message\r\n2. Use visual AI to identify the new element location\r\n3. Generate updated selector using multiple strategies:\r\n   - Text content matching\r\n   - Semantic role/labels\r\n   - Visual proximity to stable elements\r\n   - Shadow DOM traversal\r\n4. Validate the fix across related tests\r\n5. Log the healing action for audit trail\r\n\r\n**Worked micro-example — healing a renamed submit button**\r\n\r\n```\r\nBroken:   await page.click('.btn-primary.submit')\r\nSymptom:  Timeout 30000ms exceeded, 0 elements matched\r\nDOM now:  <button data-testid=\"policy-submit\" type=\"submit\">提交保单</button>\r\n\r\nCandidate selectors, ranked by robustness:\r\n1. page.getByTestId('policy-submit')        <- stable by contract, best\r\n2. page.getByRole('button', { name: '提交保单' })  <- semantic, i18n-aware\r\n3. page.locator('button[type=\"submit\"]')    <- structural, survives class changes\r\n4. page.getByText('提交保单')                <- brittle if copy changes\r\n\r\nChosen: 1 (with 2 as documented fallback)\r\nAudit entry: { healed_at, old_selector, new_selector, confidence: 0.82,\r\n               evidence: \"data-testid present, unique in DOM\", reviewer: pending }\r\n```\r\n\r\n**When NOT to auto-heal (stop and escalate instead)**\r\n\r\n| Situation | Why auto-heal is dangerous | Correct action |\r\n|---|---|---|\r\n| Selector resolves to 2+ elements | Silent wrong-element clicks | Fail loudly, ask for a `data-testid` |\r\n| The element is a legal/financial confirmation | Wrong click has real-world cost | Require human-authored selector |\r\n| Failure appears only in production | May be a real defect, not a test problem | File a bug, do not heal |\r\n| Healing rate > 30% of a suite in one sprint | UI is churning; tests are not the problem | Escalate to the design/dev team |\r\n| Selector change accompanies a behaviour change | Test may now assert the wrong outcome | Re-derive assertions from the spec |\r\n\r\nSelf-healing is a maintenance aid, not a substitute for a selector contract.\r\nIf you heal the same selector twice, add a `data-testid` instead.\r\n\r\n\r\n### Step 4: Flaky Test Detection\r\n\r\n1. Collect test execution history from CI/CD\r\n2. Analyze failure patterns:\r\n   - Timing issues (race conditions, async waits)\r\n   - Resource contention (DB connections, file locks)\r\n   - Environment instability\r\n   - Test interdependencies\r\n3. Generate diagnosis report with:\r\n   - Probability of flakiness\r\n   - Root cause analysis\r\n   - Recommended fixes (add explicit waits, mock external calls, etc.)\r\n\r\n**Root-cause taxonomy (use this to classify before proposing a fix)**\r\n\r\n| Category | Typical symptom | Diagnostic signal | Fix | How to verify the fix |\r\n|---|---|---|---|---|\r\n| Async race | Passes locally, fails in CI | Failure time clusters at start-up | Explicit waits / `expect.poll` | 50 consecutive green runs |\r\n| Test interdependency | Fails only in certain orders | Passes when run alone | Isolate fixtures, reset DB per test | Run in random order 10× |\r\n| Shared resource | Fails under parallel load | Fails more as workers increase | Unique ports/DB schemas, no shared state | Rerun at 4× worker count |\r\n| Time dependence | Fails at month/day boundaries | Fails on specific dates | Inject a clock, freeze time | Run with 5 faked dates |\r\n| External dependency | Fails randomly, no code change | Network errors in logs | Mock or contract-test the boundary | Cut network, still green |\r\n| Environment drift | Fails only on one runner | Version mismatch in logs | Pin versions, containerise | Compare runner fingerprints |\r\n| Data pollution | Fails after other suites ran | Unexpected rows present | Transaction rollback / fresh seed | Run full suite twice in a row |\r\n\r\n**Severity rule**: a test that flakes more than 1 in 100 runs should be quarantined\r\nwithin one sprint. Quarantining is not the same as deleting — keep it running in a\r\nnon-blocking job so the signal is not lost.\r\n\r\n\r\n### Step 5: Coverage Analysis\r\n\r\n1. Parse code and existing test files\r\n2. Calculate line/branch/function coverage\r\n3. Identify untested code paths\r\n4. Suggest priority test cases for uncovered areas\r\n5. Generate coverage trend report\r\n\r\n**Coverage is a triage tool, not a target — prioritise like this**\r\n\r\n| Band | Current coverage | Risk profile | What to do first | What to ignore |\r\n|---|---|---|---|---|\r\n| Critical path | 0–40% | Payment, underwriting, auth | Tests + contract tests + alerting | Mutation score |\r\n| Business logic | 40–70% | Pricing, eligibility rules | Property-based tests on rules | Chasing 100% line coverage |\r\n| Glue / adapters | 70–90% | Controllers, mappers | Integration tests at the boundary | Unit tests per branch |\r\n| Generated code | any | DTOs, clients | Exclude from coverage denominators | Manual assertions |\r\n| Dead code | any | Unreachable | Delete it | Testing it |\r\n\r\n**Two coverage metrics that beat line coverage**\r\n\r\n1. *Mutation score* — inject small faults; a suite that still passes has blind spots.\r\n2. *Critical-path coverage* — coverage restricted to the modules that carry money or\r\n   regulatory risk. A 60% score here matters more than 95% overall.\r\n\r\n**Anti-pattern**: raising the coverage gate while the suite is flaky. You will get\r\ngreen numbers and no confidence.\r\n\r\n\r\n## Input/Output Examples\r\n\r\n### Example 1: Generate Unit Tests\r\n\r\n**Input:**\r\n```\r\nGenerate unit tests for this Python function:\r\ndef calculate_premium(age: int, health_score: float, coverage_amount: float) -> float:\r\n    if age < 18 or age > 70:\r\n        raise ValueError(\"Age must be between 18 and 70\")\r\n    base_rate = coverage_amount * 0.05\r\n    health_factor = 1.0 - (health_score / 100) * 0.3\r\n    return base_rate * health_factor\r\n```\r\n\r\n**Output:**\r\n```python\r\nimport pytest\r\nfrom your_module import calculate_premium\r\n\r\nclass TestCalculatePremium:\r\n    def test_happy_path(self):\r\n        result = calculate_premium(age=30, health_score=80, coverage_amount=100000)\r\n        assert 3000 <= result <= 5000\r\n\r\n    def test_age_boundary_18_valid(self):\r\n        result = calculate_premium(age=18, health_score=50, coverage_amount=100000)\r\n        assert result == 100000 * 0.05 * (1.0 - 0.5 * 0.3)\r\n\r\n    def test_age_boundary_70_valid(self):\r\n        result = calculate_premium(age=70, health_score=50, coverage_amount=100000)\r\n        assert isinstance(result, float)\r\n\r\n    def test_age_too_young(self):\r\n        with pytest.raises(ValueError, match=\"Age must be between\"):\r\n            calculate_premium(age=17, health_score=80, coverage_amount=100000)\r\n\r\n    def test_age_too_old(self):\r\n        with pytest.raises(ValueError, match=\"Age must be between\"):\r\n            calculate_premium(age=71, health_score=80, coverage_amount=100000)\r\n\r\n    @pytest.mark.parametrize(\"health_score,expected_factor_range\", [\r\n        (0, (0.97, 1.01)),\r\n        (50, (0.82, 0.88)),\r\n        (100, (0.69, 0.71)),\r\n    ])\r\n    def test_health_factor_bounds(self, health_score, expected_factor_range):\r\n        result = calculate_premium(age=30, health_score=health_score, coverage_amount=100000)\r\n        lower, upper = expected_factor_range\r\n        assert lower * 5000 <= result <= upper * 5000\r\n```\r\n\r\n### Example 2: Self-Healing a Broken Playwright Test\r\n\r\n**Input:**\r\n```\r\nMy Playwright test is failing: Selector \".submit-button\" not found.\r\nThe button text is \"提交保单\" now.\r\n```\r\n\r\n**Output:**\r\n```\r\n🔧 Self-Healing Analysis:\r\n- Original selector: \".submit-button\"\r\n- Issue: UI updated, element selector changed\r\n- Healed selector strategy: text-content match\r\n\r\nGenerated alternatives:\r\n1. await page.getByRole('button', { name: '提交保单' }).click()\r\n2. await page.locator('button[type=\"submit\"]').click()\r\n3. await page.getByText('提交保单').click()\r\n\r\nRecommended (most robust): Option 1\r\n- Uses semantic role binding (survives CSS class changes)\r\n- Language-aware (works with i18n updates)\r\n```\r\n\r\n### Example 3: Flaky Test Diagnosis\r\n\r\n**Input:**\r\n```\r\nDiagnose why this test is flaky:\r\nit('should load user dashboard', async () => {\r\n  const dashboard = await page.locator('.dashboard').waitFor();\r\n  const count = await dashboard.locator('.card').count();\r\n  expect(count).toBeGreaterThan(0);\r\n});\r\n```\r\n\r\n**Output:**\r\n```\r\nFlaky Test Report:\r\n- Flakiness probability: 87% (HIGH)\r\n- Root cause: Race condition between page load and element appearance\r\n\r\nRecommended fixes:\r\n1. Replace implicit waitFor() with explicit wait:\r\n   await expect(page.locator('.dashboard')).toBeVisible({ timeout: 10000 })\r\n\r\n2. Add network idle wait:\r\n   await page.waitForLoadState('networkidle')\r\n\r\n3. Use data-testid for stability:\r\n   <div data-testid=\"user-dashboard\" className=\"dashboard\">...</div>\r\n\r\n4. Add retry wrapper for truly async cases:\r\n   await expect.poll(async () => {\r\n     return await page.locator('.card').count();\r\n   }, { timeout: 10000 }).toBeGreaterThan(0);\r\n```\r\n\r\n### Example 4: Coverage triage for a legacy module\r\n\r\n**Input:**\r\n```\r\nModule: premium_calculator.py, 41% coverage, 1,800 lines, no tests for 2 years.\r\nWhere do we start? We cannot stop feature work to fix this.\r\n```\r\n\r\n**Output:**\r\n```\r\nDo not \"add tests until 80%\". Triage instead.\r\n\r\nStep 1 - Find the money paths (half a day)\r\n  Grep for the entry points actually called in production:\r\n  calculate_premium, apply_discount, validate_eligibility\r\n  These 3 functions are ~180 lines and carry all the risk.\r\n\r\nStep 2 - Characterisation tests first (2 days)\r\n  Before refactoring anything, lock in current behaviour:\r\n  - Snapshot 200 real historical inputs -> outputs into a fixture file\r\n  - Assert the module reproduces them exactly\r\n  This makes future refactoring safe even if today's behaviour is wrong.\r\n\r\nStep 3 - Add rule tests only where rules are unclear (3 days)\r\n  Boundary: age 18 / 70, health_score 0 / 100, coverage 0 / max\r\n  Negative: non-integer age, negative coverage, None\r\n  Error: missing rate table -> explicit exception, not silent 0\r\n\r\nStep 4 - Exclude the noise (1 hour)\r\n  # .coveragerc\r\n  omit = generated/*, migrations/*, */dto/*\r\n\r\nStep 5 - Set the gate where you actually are, then ratchet\r\n  Start the gate at 45% (today + small margin) and raise it only when a\r\n  pull request would otherwise pass below it. Never lower it.\r\n\r\nRealistic outcome after 1 sprint: overall ~55%, critical-path ~90%.\r\nThe second number is the one that matters.\r\n```\r\n\r\n### Example 5: A test that should not be healed\r\n\r\n**Input:**\r\n```\r\nThis Playwright test has been auto-healed 4 times this month. Should we heal it again?\r\n```\r\n\r\n**Output:**\r\n```\r\nNo. Four heals in a month is a design signal, not a maintenance event.\r\n\r\nWhat the pattern tells us:\r\n- The UI is churning faster than the test contract can follow\r\n- There is no stable selector agreement between dev and QA\r\n- Each heal silently moves the test further from the original intent\r\n- At some point the test will pass while the feature is broken\r\n\r\nRecommended sequence:\r\n1. Freeze healing on this test; mark it @quarantined with an expiry date\r\n2. Ask the dev team to add data-testid to the 3 elements involved\r\n   (a 15-minute change that removes the whole problem class)\r\n3. Re-derive the assertions from the user story, not from the current DOM\r\n4. Add the selector contract to the definition-of-done for that component\r\n\r\nEscalation trigger for management:\r\n- If >20% of the suite needed healing this month, the cost is a process problem.\r\n  One engineer adding test IDs is cheaper than an agent healing forever.\r\n\r\nHealing budget rule of thumb: at most 2 heals per selector per quarter.\r\nBeyond that, fix the contract.\r\n```\r\n\r\n## Key Capabilities\r\n\r\n| Capability | Description | Supported Frameworks | Input you must supply | Output artifact | Main false-positive risk | Human checkpoint |\r\n|---|---|---|---|---|---|---|\r\n| Test Generation | Generate tests from code/user stories | pytest, Jest, Vitest, JUnit, Playwright, Cypress | Source file + user story or API spec | Test file + case table | Assertions mirror a buggy implementation | Review expected values against the spec |\r\n| Self-Healing | Auto-fix broken selectors | Playwright, Cypress, Selenium | Failing selector + DOM snapshot | Ranked candidate selectors + audit entry | Selector matches the wrong element | Approve before merge |\r\n| Flaky Test Detection | Diagnose intermittent failures | All major frameworks + CI logs | ≥ 30 runs of history | Root-cause report + fix list | Blaming flakiness for a real defect | Confirm with a targeted rerun |\r\n| Coverage Analysis | Measure and report test coverage | Istanbul, pytest-cov, JaCoCo | Coverage JSON/XML | Gap list + priority order | High line coverage, low assertion quality | Pair with mutation score |\r\n| API Contract Testing | Validate API schemas and responses | OpenAPI, Postman, Pact | OpenAPI spec or consumer contract | Contract report + breaking-change diff | Spec itself is stale | Re-sync spec from production traffic |\r\n| Mutation Testing (advisory) | Assess assertion strength | mutmut, Stryker, PIT | Passing suite + source | Mutation score per module | Equivalent mutants inflate the score | Sample-review surviving mutants |\r\n| Visual Regression (advisory) | Catch unintended UI change | Playwright snapshots, Percy | Baseline images | Diff images + review queue | Font/AA rendering noise | Approve or reject each diff |\r\n\r\n## Ecosystem Status (as of 2026-09-10)\r\n\r\nTooling in AI-assisted QA changes quickly. Verify each item against the\r\nproject's official releases before relying on it.\r\n\r\n| Area | What to verify | Why it matters here |\r\n|---|---|---|\r\n| Browser automation baseline | Current Playwright / Cypress / Selenium major versions | Selector APIs and auto-waiting behaviour differ by version |\r\n| Visual AI / self-healing vendors | Whether the healing engine is self-hosted or SaaS | SaaS means screenshots leave your network — a blocker for regulated data |\r\n| CI log retention | How long your CI keeps test history | Flakiness detection needs ≥ 30 runs; short retention kills the signal |\r\n| Coverage format stability | JSON/XML schema of your coverage tool | Parser breaks silently on major upgrades |\r\n| AI-generated test review policy | Your org's rule on merging generated tests | Determines the human checkpoint that must exist |\r\n\r\n**Recent dynamics (as of 2026-09-10, verify against official sources)**\r\n1. Self-healing and visual-AI testing have become common features rather than\r\n   differentiators, which shifts the buyer question from \"does it heal\" to\r\n   \"can I audit what it healed and why\".\r\n2. More teams are treating test-suite health as a production signal: flaky-test\r\n   quarantine budgets and mutation scores are appearing alongside coverage gates.\r\n3. Data-residency concerns are pushing some regulated teams away from\r\n   SaaS-based visual testing toward self-hosted snapshot comparison.\r\n4. Every version number and tool name above is point-in-time; confirm upstream.\r\n\r\n## Best Practices\r\n\r\n1. **Always add `data-testid` attributes** to UI elements for stable selectors\r\n2. **Use explicit waits** instead of `sleep()` — AI will recommend optimal wait strategies\r\n3. **Keep tests isolated** — each test should be independent\r\n4. **Parameterize test data** — use data-driven tests for variant coverage\r\n5. **Review self-healed selectors** — AI suggestions should be human-verified before production\r\n\r\n## Notes\r\n\r\n- This skill produces test code, analysis and configuration for you to run in your own environment; the code blocks in this document are reference material, not commands this skill executes on your behalf\r\n- For CI/CD integration, combine with `ai-test-strategy-architect` skill\r\n- Self-healing suggestions prioritize semantic selectors over CSS class selectors\r\n- Coverage analysis requires access to test execution output files (JSON/XML format)\r\n\r\n## Changelog\r\n\r\n- **1.0.1** (2026-09-10): Added worked micro-examples to Steps 2–5 (story→case table,\r\n  selector healing with audit entry, flaky root-cause taxonomy, coverage triage bands).\r\n  Added \"when NOT to auto-heal\" table and coverage-priority table. Expanded the\r\n  capability table from 3 to 7 columns and 5 to 7 rows (input required, output artifact,\r\n  false-positive risk, human checkpoint). Added Examples 4–5. Added \"Ecosystem Status\r\n  (as of 2026-09-10)\". Clarified the execution-boundary note.\r\n- **1.0.0** (2026-05-19): Initial version.\r\n\r\n**Last Updated**: 2026-09-10\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"agentic-test-engineer\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1789017847020\n}\n\nFile v1.0.1:skill-card.md\n\n## Description:\n\nAgentic Test Engineer helps QA engineers and developers generate unit, integration, E2E, and API tests, diagnose flaky tests, suggest selector self-healing fixes, and prioritize coverage gaps.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gechengling](https://clawhub.ai/user/gechengling)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, QA engineers, and test owners use this skill to create and review test artifacts, investigate flaky tests, propose selector repairs, and triage coverage gaps across common application stacks.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated tests, flaky-test diagnoses, coverage recommendations, or self-healed selectors may be incorrect or may preserve a bug in the implementation.\n\nMitigation: Review generated and self-healed test artifacts against the product specification before merging or relying on them in CI.\n\nRisk: Screenshots, DOM snapshots, CI logs, coverage files, and broad debugging prompts can contain secrets, customer data, or regulated information.\n\nMitigation: Redact sensitive data and use external visual-AI or SaaS testing tools only when permitted by the organization's data-handling policy.\n\nRisk: Repeated selector healing can hide unstable UI contracts or behavior changes.\n\nMitigation: Require stable selector contracts such as data-testid attributes and escalate repeated healing or behavior-changing failures for human review.\n\n## Reference(s):\n\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown with code blocks, command snippets, reports, and review guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces proposals and artifacts for review; it does not execute tests or modify production systems by itself.]\n\n## Skill Version(s):\n\n1.0.1 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.0: 3 files, 5002 bytes\n\nFiles: skill-card.md (2146b), SKILL.md (8331b), _meta.json (140b)\n\nFile v1.0.0:SKILL.md\n\n---\r\nname: \"Agentic Test Engineer\"\r\ndescription: \"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA.\"\r\nversion: \"1.0.0\"\r\n---\r\n\r\n# Agentic Test Engineer\r\n\r\n## Overview\r\n\r\nAn AI-powered autonomous testing assistant that revolutionizes QA workflows. It generates comprehensive test suites from user stories and code, self-heals broken selectors using visual AI, detects and diagnoses flaky tests, and continuously maintains test coverage metrics — all with minimal human intervention.\r\n\r\n## Triggers\r\n\r\n- \"generate tests for [feature/code]\"\r\n- \"write unit tests for [function]\"\r\n- \"self-heal my broken test\"\r\n- \"find flaky tests in [project]\"\r\n- \"check test coverage for [module]\"\r\n- \"run E2E tests for [workflow]\"\r\n- \"why is my test failing\"\r\n- \"智能测试生成\"\r\n- \"自愈测试修复\"\r\n- \"测试覆盖率分析\"\r\n\r\n## Workflow\r\n\r\n### Step 1: Detect Context\r\n\r\nIdentify the testing scenario:\r\n- **Unit tests**: Python, JavaScript, TypeScript, Java, Go functions\r\n- **Integration tests**: API endpoints, database interactions, service meshes\r\n- **E2E tests**: Browser workflows (Playwright, Cypress, Selenium)\r\n- **API tests**: REST/GraphQL endpoints, contract testing\r\n- **Flaky test diagnosis**: Test results history, timing issues, async race conditions\r\n- **Self-healing**: Broken selectors, changed DOM, moved UI elements\r\n\r\n### Step 2: Test Generation\r\n\r\nFor test generation:\r\n1. Analyze code structure, user story, or API spec\r\n2. Select appropriate testing framework:\r\n   - Python: pytest, unittest\r\n   - JavaScript/TypeScript: Jest, Vitest, Playwright, Cypress\r\n   - Java: JUnit, TestNG\r\n   - Go: testing package, testify\r\n3. Generate comprehensive test cases:\r\n   - Happy path scenarios\r\n   - Edge cases and boundary conditions\r\n   - Error handling scenarios\r\n   - Negative test cases\r\n4. Include setup/teardown fixtures\r\n5. Add data-driven test parameters\r\n\r\n### Step 3: Self-Healing (When Triggered)\r\n\r\nWhen a test breaks due to UI changes:\r\n1. Capture the failing selector/error message\r\n2. Use visual AI to identify the new element location\r\n3. Generate updated selector using multiple strategies:\r\n   - Text content matching\r\n   - Semantic role/labels\r\n   - Visual proximity to stable elements\r\n   - Shadow DOM traversal\r\n4. Validate the fix across related tests\r\n5. Log the healing action for audit trail\r\n\r\n### Step 4: Flaky Test Detection\r\n\r\n1. Collect test execution history from CI/CD\r\n2. Analyze failure patterns:\r\n   - Timing issues (race conditions, async waits)\r\n   - Resource contention (DB connections, file locks)\r\n   - Environment instability\r\n   - Test interdependencies\r\n3. Generate diagnosis report with:\r\n   - Probability of flakiness\r\n   - Root cause analysis\r\n   - Recommended fixes (add explicit waits, mock external calls, etc.)\r\n\r\n### Step 5: Coverage Analysis\r\n\r\n1. Parse code and existing test files\r\n2. Calculate line/branch/function coverage\r\n3. Identify untested code paths\r\n4. Suggest priority test cases for uncovered areas\r\n5. Generate coverage trend report\r\n\r\n## Input/Output Examples\r\n\r\n### Example 1: Generate Unit Tests\r\n\r\n**Input:**\r\n```\r\nGenerate unit tests for this Python function:\r\ndef calculate_premium(age: int, health_score: float, coverage_amount: float) -> float:\r\n    if age < 18 or age > 70:\r\n        raise ValueError(\"Age must be between 18 and 70\")\r\n    base_rate = coverage_amount * 0.05\r\n    health_factor = 1.0 - (health_score / 100) * 0.3\r\n    return base_rate * health_factor\r\n```\r\n\r\n**Output:**\r\n```python\r\nimport pytest\r\nfrom your_module import calculate_premium\r\n\r\nclass TestCalculatePremium:\r\n    def test_happy_path(self):\r\n        result = calculate_premium(age=30, health_score=80, coverage_amount=100000)\r\n        assert 3000 <= result <= 5000\r\n\r\n    def test_age_boundary_18_valid(self):\r\n        result = calculate_premium(age=18, health_score=50, coverage_amount=100000)\r\n        assert result == 100000 * 0.05 * (1.0 - 0.5 * 0.3)\r\n\r\n    def test_age_boundary_70_valid(self):\r\n        result = calculate_premium(age=70, health_score=50, coverage_amount=100000)\r\n        assert isinstance(result, float)\r\n\r\n    def test_age_too_young(self):\r\n        with pytest.raises(ValueError, match=\"Age must be between\"):\r\n            calculate_premium(age=17, health_score=80, coverage_amount=100000)\r\n\r\n    def test_age_too_old(self):\r\n        with pytest.raises(ValueError, match=\"Age must be between\"):\r\n            calculate_premium(age=71, health_score=80, coverage_amount=100000)\r\n\r\n    @pytest.mark.parametrize(\"health_score,expected_factor_range\", [\r\n        (0, (0.97, 1.01)),\r\n        (50, (0.82, 0.88)),\r\n        (100, (0.69, 0.71)),\r\n    ])\r\n    def test_health_factor_bounds(self, health_score, expected_factor_range):\r\n        result = calculate_premium(age=30, health_score=health_score, coverage_amount=100000)\r\n        lower, upper = expected_factor_range\r\n        assert lower * 5000 <= result <= upper * 5000\r\n```\r\n\r\n### Example 2: Self-Healing a Broken Playwright Test\r\n\r\n**Input:**\r\n```\r\nMy Playwright test is failing: Selector \".submit-button\" not found.\r\nThe button text is \"提交保单\" now.\r\n```\r\n\r\n**Output:**\r\n```\r\n🔧 Self-Healing Analysis:\r\n- Original selector: \".submit-button\"\r\n- Issue: UI updated, element selector changed\r\n- Healed selector strategy: text-content match\r\n\r\nGenerated alternatives:\r\n1. await page.getByRole('button', { name: '提交保单' }).click()\r\n2. await page.locator('button[type=\"submit\"]').click()\r\n3. await page.getByText('提交保单').click()\r\n\r\nRecommended (most robust): Option 1\r\n- Uses semantic role binding (survives CSS class changes)\r\n- Language-aware (works with i18n updates)\r\n```\r\n\r\n### Example 3: Flaky Test Diagnosis\r\n\r\n**Input:**\r\n```\r\nDiagnose why this test is flaky:\r\nit('should load user dashboard', async () => {\r\n  const dashboard = await page.locator('.dashboard').waitFor();\r\n  const count = await dashboard.locator('.card').count();\r\n  expect(count).toBeGreaterThan(0);\r\n});\r\n```\r\n\r\n**Output:**\r\n```\r\nFlaky Test Report:\r\n- Flakiness probability: 87% (HIGH)\r\n- Root cause: Race condition between page load and element appearance\r\n\r\nRecommended fixes:\r\n1. Replace implicit waitFor() with explicit wait:\r\n   await expect(page.locator('.dashboard')).toBeVisible({ timeout: 10000 })\r\n\r\n2. Add network idle wait:\r\n   await page.waitForLoadState('networkidle')\r\n\r\n3. Use data-testid for stability:\r\n   <div data-testid=\"user-dashboard\" className=\"dashboard\">...</div>\r\n\r\n4. Add retry wrapper for truly async cases:\r\n   await expect.poll(async () => {\r\n     return await page.locator('.card').count();\r\n   }, { timeout: 10000 }).toBeGreaterThan(0);\r\n```\r\n\r\n## Key Capabilities\r\n\r\n| Capability | Description | Supported Frameworks |\r\n|------------|-------------|---------------------|\r\n| Test Generation | Generate tests from code/user stories | pytest, Jest, Vitest, JUnit, Playwright, Cypress |\r\n| Self-Healing | Auto-fix broken selectors | Playwright, Cypress, Selenium |\r\n| Flaky Test Detection | Diagnose intermittent failures | All major frameworks + CI logs |\r\n| Coverage Analysis | Measure and report test coverage | Istanbul, pytest-cov, JaCoCo |\r\n| API Contract Testing | Validate API schemas and responses | OpenAPI, Postman, Pact |\r\n\r\n## Best Practices\r\n\r\n1. **Always add `data-testid` attributes** to UI elements for stable selectors\r\n2. **Use explicit waits** instead of `sleep()` — AI will recommend optimal wait strategies\r\n3. **Keep tests isolated** — each test should be independent\r\n4. **Parameterize test data** — use data-driven tests for variant coverage\r\n5. **Review self-healed selectors** — AI suggestions should be human-verified before production\r\n\r\n## Notes\r\n\r\n- This skill generates test code only — it does not execute tests directly\r\n- For CI/CD integration, combine with `ai-test-strategy-architect` skill\r\n- Self-healing suggestions prioritize semantic selectors over CSS class selectors\r\n- Coverage analysis requires access to test execution output files (JSON/XML format)\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"agentic-test-engineer\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1779192383229\n}\n\nFile v1.0.0:skill-card.md\n\n## Description: <br>\nAgentic Test Engineer helps QA engineers and developers generate tests, diagnose flaky failures, repair broken UI selectors, and identify coverage gaps. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[gechengling](https://clawhub.ai/user/gechengling) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers and developers use this skill to generate unit, integration, E2E, and API tests from code or stories, diagnose flaky test failures, suggest selector repairs, and plan tests for uncovered code paths. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated tests or selector repairs may be incorrect, brittle, or misaligned with the intended application behavior. <br>\nMitigation: Review generated tests and proposed self-healed selectors before committing or using them in production workflows. <br>\nRisk: The skill may need access to project code, tests, CI logs, and coverage files to provide useful guidance. <br>\nMitigation: Install and run it only where sharing those project artifacts with the agent is acceptable. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/gechengling/agentic-test-engineer) <br>\n- [Publisher profile](https://clawhub.ai/user/gechengling) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance] <br>\n**Output Format:** [Markdown with code blocks and structured recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces test code examples, selector repair options, flaky-test analysis, coverage recommendations, and reviewable workflow guidance; it does not execute tests directly.] <br>\n\n## Skill Version(s): <br>\n1.0.0 (source: frontmatter and release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: Agentic Test Engineer Owner: gechengling Summary: AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test dete","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\r\nname: \"Agentic Test Engineer\"\r\ndescription: \"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA.\"\r\nversion: \"1.0.2\"\r\n---\r\n\r\n# Agentic Test Engineer\r\n\r\n## Overview\r\n\r\nAn AI-powered autonomous testing assistant that revolutionizes QA workflows. It generates comprehensive test suites from user stories and code, self-heals broken selectors using visual AI, detects and diagnoses flaky tests, and continuously maintains test coverage metrics. It is an **advisory** skill: it\r\nproduces test code, selectors, diagnoses and configuration for you to review and run\r\nin your own CI. It does not execute tests, does not edit your repository, and does not\r\npush changes. Every healing suggestion carries a human checkpoint before merge.\r\n\r\n## Scope and Data-Handling Policy (read first)\r\n\r\n**Advisory only.** This skill drafts tests, selectors and diagnoses. It does not run\r\nthem, does not write files into your repository, and does not talk to your CI. Code\r\nblocks below are reference material to copy into your own environment.\r\n\r\n**In scope**: unit / integration / E2E / API test design, flaky-test diagnosis,\r\nselector maintenance, coverage triage, and the review policy for AI-generated tests.\r\n\r\n**Out of scope (do not activate for these)**: production incident response, security\r\npenetration testing, performance/load engineering, accessibility conformance audits,\r\nand general debugging that is not about a test. Those need their own tooling.\r\n\r\n### Third-party and SaaS test-vendor checklist (SQP-2)\r\n\r\nSelf-healing and visual-regression features are frequently delivered as a SaaS\r\nservice. That means **screenshots, DOM snapshots and sometimes test data leave your\r\nnetwork**. Confirm the following before enabling any external vendor:\r\n\r\n| Question to answer | Why it matters | Deal-breaker |\r\n|---|---|---|\r\n| Are screenshots and DOM snapshots stored outside our network? | Screenshots of a real policy or claim screen are customer data | Regulated data with no on-prem option |\r\n| Where is the data processed and for how long is it retained? | Retention turns a test artefact into a data store | Retention the vendor cannot state in writing |\r\n| Is the healing engine self-hostable? | Self-hosting removes the egress question entirely | No self-host option and no DPA |\r\n| Can we redact before upload? | Redaction is the practical middle ground | No redaction hook and no masking |\r\n| Does the vendor train on our artefacts? | Your UI may contain unreleased business logic | Training on customer data without an opt-out |\r\n| Who can access the artefact store? | Broad vendor-side access is a real exposure | Shared, unlogg"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn74e704j3ygjcygnpf02rdvd185js13\",\n  \"slug\": \"agentic-test-engineer\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1790572757039\n}"},{"path":"skill-card.md","content":"## Description:\n\nDrafts test cases, test code, selector fixes, flaky-test diagnoses, and coverage guidance for human review without running tests or changing repositories.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[gechengling](https://clawhub.ai/user/gechengling)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers and developers use this advisory skill to design unit, integration, API, and browser tests, diagnose flaky failures, propose selector repairs, and prioritize coverage gaps. They review its suggestions before running tests or merging changes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Screenshots, DOM snapshots, CI logs, and coverage files may expose sensitive information when shared with external testing services.\n\nMitigation: Use synthetic test data, redact sensitive content, limit snapshots to what is needed, and keep visual testing self-hosted unless vendor handling is approved.\n\nRisk: A suggested selector repair may hide a product regression or target the wrong element.\n\nMitigation: Review every repair before merging; stop and escalate ambiguous selectors or behavior changes instead of automatically healing them.\n\n## Reference(s):\n\n- [Agentic Test Engineer on ClawHub](https://clawhub.ai/gechengling/skills/agentic-test-engineer)\n\n## Skill Output:\n\n**Output Type(s):** [Code, Analysis, Configuration instructions, Guidance]\n\n**Output Format:** [Markdown with code blocks and tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Advisory output for human review; does not run tests, modify repositories, or access CI.]\n\n## Skill Version(s):\n\n1.0.2 (source: release metadata and frontmatter)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test detection, visual AI testing, test coverage, AI-native QA. Skill: Agentic Test Engineer Owner: gechengling Summary: AI-powered autonomous test generation and self-healing test maintenance. Generates unit/integration/E2E tests, detects flaky tests, auto-fixes broken selectors, and maintains test coverage. Built for QA engineers and developers. Keywords: AI test automation, self-healing tests, autonomous QA, test generation, Playwright, Selenium, CI/CD testing, flaky test dete","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1226,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T23:21:47.252Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T23:21:47.252Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-13T06:52:36.068Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}