[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HN3TP4FS6P560XZ6GDMYVS":3,"skill-same:01M6HN3TP4FS6P560XZ6GDMYVS":168},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6HN3TP4FS6P560XZ6GDMYVS","vercel-deploy",null,"Deploy applications and websites to Vercel. Use when the user requests deployment actions like \"deploy my app\", \"deploy and give me the link\", \"push this live\", or \"create a preview deployment\".","salexandr0s\u002Fai-config","salexandr0s","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F250535030?v=4","01M6DE8DS7P9KZ6AVRN7WXK5WK","01M6HMVRBX2B360FVWFTE7K28E",14,"MIT","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"deploy","vercel deploy","vercel","when","my","requests","link","app","live","preview","me","preview deployment","use","user","applications","actions","push","create","deployment","2026-11-10 10:12:30",false,"---\nname: \"tdd-guide\"\ndescription: \"Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and Mocha. Use when the user asks to write tests, improve test coverage, practice TDD, generate mocks or stubs, or mentions testing frameworks like Jest, pytest, or JUnit.\"\n---\n\n# TDD Guide\n\nTest-driven development skill for generating tests, analyzing coverage, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, and Vitest.\n\n---\n\n## Workflows\n\n### Generate Tests from Code\n\n1. Provide source code (TypeScript, JavaScript, Python, Java)\n2. Specify target framework (Jest, Pytest, JUnit, Vitest)\n3. Run `test_generator.py` with requirements\n4. Review generated test stubs\n5. **Validation:** Tests compile and cover happy path, error cases, edge cases\n\n### Analyze Coverage Gaps\n\n1. Generate coverage report from test runner (`npm test -- --coverage`)\n2. Run `coverage_analyzer.py` on LCOV\u002FJSON\u002FXML report\n3. Review prioritized gaps (P0\u002FP1\u002FP2)\n4. Generate missing tests for uncovered paths\n5. **Validation:** Coverage meets target threshold (typically 80%+)\n\n### TDD New Feature\n\n1. Write failing test first (RED)\n2. Run `tdd_workflow.py --phase red` to validate\n3. Implement minimal code to pass (GREEN)\n4. Run `tdd_workflow.py --phase green` to validate\n5. Refactor while keeping tests green (REFACTOR)\n6. **Validation:** All tests pass after each cycle\n\n---\n\n## Examples\n\n### Test Generation — Input → Output (Pytest)\n\n**Input source function (`math_utils.py`):**\n```python\ndef divide(a: float, b: float) -> float:\n    if b == 0:\n        raise ValueError(\"Cannot divide by zero\")\n    return a \u002F b\n```\n\n**Command:**\n```bash\npython scripts\u002Ftest_generator.py --input math_utils.py --framework pytest\n```\n\n**Generated test output (`test_math_utils.py`):**\n```python\nimport pytest\nfrom math_utils import divide\n\nclass TestDivide:\n    def test_divide_positive_numbers(self):\n        assert divide(10, 2) == 5.0\n\n    def test_divide_negative_numerator(self):\n        assert divide(-10, 2) == -5.0\n\n    def test_divide_float_result(self):\n        assert divide(1, 3) == pytest.approx(0.333, rel=1e-3)\n\n    def test_divide_by_zero_raises_value_error(self):\n        with pytest.raises(ValueError, match=\"Cannot divide by zero\"):\n            divide(10, 0)\n\n    def test_divide_zero_numerator(self):\n        assert divide(0, 5) == 0.0\n```\n\n---\n\n### Coverage Analysis — Sample P0\u002FP1\u002FP2 Output\n\n**Command:**\n```bash\npython scripts\u002Fcoverage_analyzer.py --report lcov.info --threshold 80\n```\n\n**Sample output:**\n```\nCoverage Report — Overall: 63% (threshold: 80%)\n\nP0 — Critical gaps (uncovered error paths):\n  auth\u002Flogin.py:42-58   handle_expired_token()       0% covered\n  payments\u002Fprocess.py:91-110  handle_payment_failure()   0% covered\n\nP1 — High-value gaps (core logic branches):\n  users\u002Fservice.py:77   update_profile() — else branch  0% covered\n  orders\u002Fcart.py:134    apply_discount() — zero-qty guard  0% covered\n\nP2 — Low-risk gaps (utility \u002F helper functions):\n  utils\u002Fformatting.py:12  format_currency()            0% covered\n\nRecommended: Generate tests for P0 items first to reach 80% threshold.\n```\n\n---\n\n## Key Tools\n\n| Tool | Purpose | Usage |\n|------|---------|-------|\n| `test_generator.py` | Generate test cases from code\u002Frequirements | `python scripts\u002Ftest_generator.py --input source.py --framework pytest` |\n| `coverage_analyzer.py` | Parse and analyze coverage reports | `python scripts\u002Fcoverage_analyzer.py --report lcov.info --threshold 80` |\n| `tdd_workflow.py` | Guide red-green-refactor cycles | `python scripts\u002Ftdd_workflow.py --phase red --test test_auth.py` |\n| `fixture_generator.py` | Generate test data and mocks | `python scripts\u002Ffixture_generator.py --entity User --count 5` |\n\nAdditional scripts: `framework_adapter.py` (convert between frameworks), `metrics_calculator.py` (quality metrics), `format_detector.py` (detect language\u002Fframework), `output_formatter.py` (CLI\u002Fdesktop\u002FCI output).\n\n---\n\n## Input Requirements\n\n**For Test Generation:**\n- Source code (file path or pasted content)\n- Target framework (Jest, Pytest, JUnit, Vitest)\n- Coverage scope (unit, integration, edge cases)\n\n**For Coverage Analysis:**\n- Coverage report file (LCOV, JSON, or XML format)\n- Optional: Source code for context\n- Optional: Target threshold percentage\n\n**For TDD Workflow:**\n- Feature requirements or user story\n- Current phase (RED, GREEN, REFACTOR)\n- Test code and implementation status\n\n---\n\n## Spec-First Workflow\n\nTDD is most effective when driven by a written spec. The flow:\n\n1. **Write or receive a spec** — stored in `specs\u002F\u003Cfeature>.md`\n2. **Extract acceptance criteria** — each criterion becomes one or more test cases\n3. **Write failing tests (RED)** — one test per acceptance criterion\n4. **Implement minimal code (GREEN)** — satisfy each test in order\n5. **Refactor** — clean up while all tests stay green\n\n### Spec Directory Convention\n\n```\nproject\u002F\n├── specs\u002F\n│   ├── user-auth.md          # Feature spec with acceptance criteria\n│   ├── payment-processing.md\n│   └── notification-system.md\n├── tests\u002F\n│   ├── test_user_auth.py     # Tests derived from specs\u002Fuser-auth.md\n│   ├── test_payments.py\n│   └── test_notifications.py\n└── src\u002F\n```\n\n### Extracting Tests from Specs\n\nEach acceptance criterion in a spec maps to at least one test:\n\n| Spec Criterion | Test Case |\n|---------------|-----------|\n| \"User can log in with valid credentials\" | `test_login_valid_credentials_returns_token` |\n| \"Invalid password returns 401\" | `test_login_invalid_password_returns_401` |\n| \"Account locks after 5 failed attempts\" | `test_login_locks_after_five_failures` |\n\n**Tip:** Number your acceptance criteria in the spec. Reference the number in the test docstring for traceability (`# AC-3: Account locks after 5 failed attempts`).\n\n> **Cross-reference:** See `engineering\u002Fspec-driven-workflow` for the full spec methodology, including spec templates and review checklists.\n\n---\n\n## Red-Green-Refactor Examples Per Language\n\n### TypeScript \u002F Jest\n\n```typescript\n\u002F\u002F test\u002Fcart.test.ts\ndescribe(\"Cart\", () => {\n  describe(\"addItem\", () => {\n    it(\"should add a new item to an empty cart\", () => {\n      const cart = new Cart();\n      cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 1 });\n\n      expect(cart.items).toHaveLength(1);\n      expect(cart.items[0].id).toBe(\"sku-1\");\n    });\n\n    it(\"should increment quantity when adding an existing item\", () => {\n      const cart = new Cart();\n      cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 1 });\n      cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 2 });\n\n      expect(cart.items).toHaveLength(1);\n      expect(cart.items[0].qty).toBe(3);\n    });\n\n    it(\"should throw when quantity is zero or negative\", () => {\n      const cart = new Cart();\n      expect(() =>\n        cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 0 })\n      ).toThrow(\"Quantity must be positive\");\n    });\n  });\n});\n```\n\n### Python \u002F Pytest (Advanced Patterns)\n\n```python\n# tests\u002Fconftest.py — shared fixtures\nimport pytest\nfrom app.db import create_engine, Session\n\n@pytest.fixture(scope=\"session\")\ndef db_engine():\n    engine = create_engine(\"sqlite:\u002F\u002F\u002F:memory:\")\n    yield engine\n    engine.dispose()\n\n@pytest.fixture\ndef db_session(db_engine):\n    session = Session(bind=db_engine)\n    yield session\n    session.rollback()\n    session.close()\n\n# tests\u002Ftest_pricing.py — parametrize for multiple cases\nimport pytest\nfrom app.pricing import calculate_discount\n\n@pytest.mark.parametrize(\"subtotal, expected_discount\", [\n    (50.0, 0.0),       # Below threshold — no discount\n    (100.0, 5.0),      # 5% tier\n    (250.0, 25.0),     # 10% tier\n    (500.0, 75.0),     # 15% tier\n])\ndef test_calculate_discount(subtotal, expected_discount):\n    assert calculate_discount(subtotal) == pytest.approx(expected_discount)\n```\n\n### Go — Table-Driven Tests\n\n```go\n\u002F\u002F cart_test.go\npackage cart\n\nimport \"testing\"\n\nfunc TestApplyDiscount(t *testing.T) {\n    tests := []struct {\n        name     string\n        subtotal float64\n        want     float64\n    }{\n        {\"no discount below threshold\", 50.0, 0.0},\n        {\"5 percent tier\", 100.0, 5.0},\n        {\"10 percent tier\", 250.0, 25.0},\n        {\"15 percent tier\", 500.0, 75.0},\n        {\"zero subtotal\", 0.0, 0.0},\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            got := ApplyDiscount(tt.subtotal)\n            if got != tt.want {\n                t.Errorf(\"ApplyDiscount(%v) = %v, want %v\", tt.subtotal, got, tt.want)\n            }\n        })\n    }\n}\n```\n\n---\n\n## Bounded Autonomy Rules\n\nWhen generating tests autonomously, follow these rules to decide when to stop and ask the user:\n\n### Stop and Ask When\n\n- **Ambiguous requirements** — the spec or user story has conflicting or unclear acceptance criteria\n- **Missing edge cases** — you cannot determine boundary values without domain knowledge (e.g., max allowed transaction amount)\n- **Test count exceeds 50** — large test suites need human review before committing; present a summary and ask which areas to prioritize\n- **External dependencies unclear** — the feature relies on third-party APIs or services with undocumented behavior\n- **Security-sensitive logic** — authentication, authorization, encryption, or payment flows require human sign-off on test scenarios\n\n### Continue Autonomously When\n\n- **Clear spec with numbered acceptance criteria** — each criterion maps directly to tests\n- **Straightforward CRUD operations** — create, read, update, delete with well-defined models\n- **Well-defined API contracts** — OpenAPI spec or typed interfaces available\n- **Pure functions** — deterministic input\u002Foutput with no side effects\n- **Existing test patterns** — the codebase already has similar tests to follow\n\n---\n\n## Property-Based Testing\n\nProperty-based testing generates random inputs to verify invariants instead of relying on hand-picked examples. Use it when the input space is large and the expected behavior can be described as a property.\n\n### Python — Hypothesis\n\n```python\nfrom hypothesis import given, strategies as st\nfrom app.serializers import serialize, deserialize\n\n@given(st.text())\ndef test_roundtrip_serialization(data):\n    \"\"\"Serialization followed by deserialization returns the original.\"\"\"\n    assert deserialize(serialize(data)) == data\n\n@given(st.integers(), st.integers())\ndef test_addition_is_commutative(a, b):\n    assert a + b == b + a\n```\n\n### TypeScript — fast-check\n\n```typescript\nimport fc from \"fast-check\";\nimport { encode, decode } from \".\u002Fcodec\";\n\ntest(\"encode\u002Fdecode roundtrip\", () => {\n  fc.assert(\n    fc.property(fc.string(), (input) => {\n      expect(decode(encode(input))).toBe(input);\n    })\n  );\n});\n```\n\n### When to Use Property-Based Over Example-Based\n\n| Use Property-Based | Example |\n|-------------------|---------|\n| Data transformations | Serialize\u002Fdeserialize roundtrips |\n| Mathematical properties | Commutativity, associativity, idempotency |\n| Encoding\u002Fdecoding | Base64, URL encoding, compression |\n| Sorting and filtering | Output is sorted, length preserved |\n| Parser correctness | Valid input always parses without error |\n\n---\n\n## Mutation Testing\n\nMutation testing modifies your production code (creates \"mutants\") and checks whether your tests catch the changes. If a mutant survives (tests still pass), your tests have a gap that coverage alone cannot reveal.\n\n### Tools\n\n| Language | Tool | Command |\n|----------|------|---------|\n| TypeScript\u002FJavaScript | **Stryker** | `npx stryker run` |\n| Python | **mutmut** | `mutmut run --paths-to-mutate=src\u002F` |\n| Java | **PIT** | `mvn org.pitest:pitest-maven:mutationCoverage` |\n\n### Why Mutation Testing Matters\n\n- **100% line coverage != good tests** — coverage tells you code was executed, not that it was verified\n- **Catches weak assertions** — tests that run code but assert nothing meaningful\n- **Finds missing boundary tests** — mutants that change `\u003C` to `\u003C=` expose off-by-one gaps\n- **Quantifiable quality metric** — mutation score (% mutants killed) is a stronger signal than coverage %\n\n**Recommendation:** Run mutation testing on critical paths (auth, payments, data processing) even if overall coverage is high. Target 85%+ mutation score on P0 modules.\n\n---\n\n## Cross-References\n\n| Skill | Relationship |\n|-------|-------------|\n| `engineering\u002Fspec-driven-workflow` | Spec → acceptance criteria → test extraction pipeline |\n| `engineering-team\u002Ffocused-fix` | Phase 5 (Verify) uses TDD to confirm the fix with a regression test |\n| `engineering-team\u002Fsenior-qa` | Broader QA strategy; TDD is one layer in the test pyramid |\n| `engineering-team\u002Fcode-reviewer` | Review generated tests for assertion quality and coverage completeness |\n| `engineering-team\u002Fsenior-fullstack` | Project scaffolders include testing infrastructure compatible with TDD workflows |\n\n---\n\n## Limitations\n\n| Scope | Details |\n|-------|---------|\n| Unit test focus | Integration and E2E tests require different patterns |\n| Static analysis | Cannot execute tests or measure runtime behavior |\n| Language support | Best for TypeScript, JavaScript, Python, Java |\n| Report formats | LCOV, JSON, XML only; other formats need conversion |\n| Generated tests | Provide scaffolding; require human review for complex logic |\n\n**When to use other tools:**\n- E2E testing: Playwright, Cypress, Selenium\n- Performance testing: k6, JMeter, Locust\n- Security testing: OWASP ZAP, Burp Suite\n","# TDD Guide\n\nTest-driven development skill for generating tests, analyzing coverage, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, and Vitest.\n\n---\n\n## Workflows\n\n### Generate Tests from Code\n\n1. Provide source code (TypeScript, JavaScript, Python, Java)\n2. Specify target framework (Jest, Pytest, JUnit, Vitest)\n3. Run `test_generator.py` with requirements\n4. Review generated test stubs\n5. **Validation:** Tests compile and cover happy path, error cases, edge cases\n\n### Analyze Coverage Gaps\n\n1. Generate coverage report from test runner (`npm test -- --coverage`)\n2. Run `coverage_analyzer.py` on LCOV\u002FJSON\u002FXML report\n3. Review prioritized gaps (P0\u002FP1\u002FP2)\n4. Generate missing tests for uncovered paths\n5. **Validation:** Coverage meets target threshold (typically 80%+)\n\n### TDD New Feature\n\n1. Write failing test first (RED)\n2. Run `tdd_workflow.py --phase red` to validate\n3. Implement minimal code to pass (GREEN)\n4. Run `tdd_workflow.py --phase green` to validate\n5. Refactor while keeping tests green (REFACTOR)\n6. **Validation:** All tests pass after each cycle\n\n---\n\n## Examples\n\n### Test Generation — Input → Output (Pytest)\n\n**Input source function (`math_utils.py`):**\n```python\ndef divide(a: float, b: float) -> float:\n    if b == 0:\n        raise ValueError(\"Cannot divide by zero\")\n    return a \u002F b\n```\n\n**Command:**\n```bash\npython scripts\u002Ftest_generator.py --input math_utils.py --framework pytest\n```\n\n**Generated test output (`test_math_utils.py`):**\n```python\nimport pytest\nfrom math_utils import divide\n\nclass TestDivide:\n    def test_divide_positive_numbers(self):\n        assert divide(10, 2) == 5.0\n\n    def test_divide_negative_numerator(self):\n        assert divide(-10, 2) == -5.0\n\n    def test_divide_float_result(self):\n        assert divide(1, 3) == pytest.approx(0.333, rel=1e-3)\n\n    def test_divide_by_zero_raises_value_error(self):\n        with pytest.raises(ValueError, match=\"Cannot divide by zero\"):\n            divide(10, 0)\n\n    def test_divide_zero_numerator(self):\n        assert divide(0, 5) == 0.0\n```\n\n---\n\n### Coverage Analysis — Sample P0\u002FP1\u002FP2 Output\n\n**Command:**\n```bash\npython scripts\u002Fcoverage_analyzer.py --report lcov.info --threshold 80\n```\n\n**Sample output:**\n```\nCoverage Report — Overall: 63% (threshold: 80%)\n\nP0 — Critical gaps (uncovered error paths):\n  auth\u002Flogin.py:42-58   handle_expired_token()       0% covered\n  payments\u002Fprocess.py:91-110  handle_payment_failure()   0% covered\n\nP1 — High-value gaps (core logic branches):\n  users\u002Fservice.py:77   update_profile() — else branch  0% covered\n  orders\u002Fcart.py:134    apply_discount() — zero-qty guard  0% covered\n\nP2 — Low-risk gaps (utility \u002F helper functions):\n  utils\u002Fformatting.py:12  format_currency()            0% covered\n\nRecommended: Generate tests for P0 items first to reach 80% threshold.\n```\n\n---\n\n## Key Tools\n\n| Tool | Purpose | Usage |\n|------|---------|-------|\n| `test_generator.py` | Generate test cases from code\u002Frequirements | `python scripts\u002Ftest_generator.py --input source.py --framework pytest` |\n| `coverage_analyzer.py` | Parse and analyze coverage reports | `python scripts\u002Fcoverage_analyzer.py --report lcov.info --threshold 80` |\n| `tdd_workflow.py` | Guide red-green-refactor cycles | `python scripts\u002Ftdd_workflow.py --phase red --test test_auth.py` |\n| `fixture_generator.py` | Generate test data and mocks | `python scripts\u002Ffixture_generator.py --entity User --count 5` |\n\nAdditional scripts: `framework_adapter.py` (convert between frameworks), `metrics_calculator.py` (quality metrics), `format_detector.py` (detect language\u002Fframework), `output_formatter.py` (CLI\u002Fdesktop\u002FCI output).\n\n---\n\n## Input Requirements\n\n**For Test Generation:**\n- Source code (file path or pasted content)\n- Target framework (Jest, Pytest, JUnit, Vitest)\n- Coverage scope (unit, integration, edge cases)\n\n**For Coverage Analysis:**\n- Coverage report file (LCOV, JSON, or XML format)\n- Optional: Source code for context\n- Optional: Target threshold percentage\n\n**For TDD Workflow:**\n- Feature requirements or user story\n- Current phase (RED, GREEN, REFACTOR)\n- Test code and implementation status\n\n---\n\n## Spec-First Workflow\n\nTDD is most effective when driven by a written spec. The flow:\n\n1. **Write or receive a spec** — stored in `specs\u002F\u003Cfeature>.md`\n2. **Extract acceptance criteria** — each criterion becomes one or more test cases\n3. **Write failing tests (RED)** — one test per acceptance criterion\n4. **Implement minimal code (GREEN)** — satisfy each test in order\n5. **Refactor** — clean up while all tests stay green\n\n### Spec Directory Convention\n\n```\nproject\u002F\n├── specs\u002F\n│   ├── user-auth.md          # Feature spec with acceptance criteria\n│   ├── payment-processing.md\n│   └── notification-system.md\n├── tests\u002F\n│   ├── test_user_auth.py     # Tests derived from specs\u002Fuser-auth.md\n│   ├── test_payments.py\n│   └── test_notifications.py\n└── src\u002F\n```\n\n### Extracting Tests from Specs\n\nEach acceptance criterion in a spec maps to at least one test:\n\n| Spec Criterion | Test Case |\n|---------------|-----------|\n| \"User can log in with valid credentials\" | `test_login_valid_credentials_returns_token` |\n| \"Invalid password returns 401\" | `test_login_invalid_password_returns_401` |\n| \"Account locks after 5 failed attempts\" | `test_login_locks_after_five_failures` |\n\n**Tip:** Number your acceptance criteria in the spec. Reference the number in the test docstring for traceability (`# AC-3: Account locks after 5 failed attempts`).\n\n> **Cross-reference:** See `engineering\u002Fspec-driven-workflow` for the full spec methodology, including spec templates and review checklists.\n\n---\n\n## Red-Green-Refactor Examples Per Language\n\n### TypeScript \u002F Jest\n\n```typescript\n\u002F\u002F test\u002Fcart.test.ts\ndescribe(\"Cart\", () => {\n  describe(\"addItem\", () => {\n    it(\"should add a new item to an empty cart\", () => {\n      const cart = new Cart();\n      cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 1 });\n\n      expect(cart.items).toHaveLength(1);\n      expect(cart.items[0].id).toBe(\"sku-1\");\n    });\n\n    it(\"should increment quantity when adding an existing item\", () => {\n      const cart = new Cart();\n      cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 1 });\n      cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 2 });\n\n      expect(cart.items).toHaveLength(1);\n      expect(cart.items[0].qty).toBe(3);\n    });\n\n    it(\"should throw when quantity is zero or negative\", () => {\n      const cart = new Cart();\n      expect(() =>\n        cart.addItem({ id: \"sku-1\", name: \"Widget\", price: 9.99, qty: 0 })\n      ).toThrow(\"Quantity must be positive\");\n    });\n  });\n});\n```\n\n### Python \u002F Pytest (Advanced Patterns)\n\n```python\n# tests\u002Fconftest.py — shared fixtures\nimport pytest\nfrom app.db import create_engine, Session\n\n@pytest.fixture(scope=\"session\")\ndef db_engine():\n    engine = create_engine(\"sqlite:\u002F\u002F\u002F:memory:\")\n    yield engine\n    engine.dispose()\n\n@pytest.fixture\ndef db_session(db_engine):\n    session = Session(bind=db_engine)\n    yield session\n    session.rollback()\n    session.close()\n\n# tests\u002Ftest_pricing.py — parametrize for multiple cases\nimport pytest\nfrom app.pricing import calculate_discount\n\n@pytest.mark.parametrize(\"subtotal, expected_discount\", [\n    (50.0, 0.0),       # Below threshold — no discount\n    (100.0, 5.0),      # 5% tier\n    (250.0, 25.0),     # 10% tier\n    (500.0, 75.0),     # 15% tier\n])\ndef test_calculate_discount(subtotal, expected_discount):\n    assert calculate_discount(subtotal) == pytest.approx(expected_discount)\n```\n\n### Go — Table-Driven Tests\n\n```go\n\u002F\u002F cart_test.go\npackage cart\n\nimport \"testing\"\n\nfunc TestApplyDiscount(t *testing.T) {\n    tests := []struct {\n        name     string\n        subtotal float64\n        want     float64\n    }{\n        {\"no discount below threshold\", 50.0, 0.0},\n        {\"5 percent tier\", 100.0, 5.0},\n        {\"10 percent tier\", 250.0, 25.0},\n        {\"15 percent tier\", 500.0, 75.0},\n        {\"zero subtotal\", 0.0, 0.0},\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            got := ApplyDiscount(tt.subtotal)\n            if got != tt.want {\n                t.Errorf(\"ApplyDiscount(%v) = %v, want %v\", tt.subtotal, got, tt.want)\n            }\n        })\n    }\n}\n```\n\n---\n\n## Bounded Autonomy Rules\n\nWhen generating tests autonomously, follow these rules to decide when to stop and ask the user:\n\n### Stop and Ask When\n\n- **Ambiguous requirements** — the spec or user story has conflicting or unclear acceptance criteria\n- **Missing edge cases** — you cannot determine boundary values without domain knowledge (e.g., max allowed transaction amount)\n- **Test count exceeds 50** — large test suites need human review before committing; present a summary and ask which areas to prioritize\n- **External dependencies unclear** — the feature relies on third-party APIs or services with undocumented behavior\n- **Security-sensitive logic** — authentication, authorization, encryption, or payment flows require human sign-off on test scenarios\n\n### Continue Autonomously When\n\n- **Clear spec with numbered acceptance criteria** — each criterion maps directly to tests\n- **Straightforward CRUD operations** — create, read, update, delete with well-defined models\n- **Well-defined API contracts** — OpenAPI spec or typed interfaces available\n- **Pure functions** — deterministic input\u002Foutput with no side effects\n- **Existing test patterns** — the codebase already has similar tests to follow\n\n---\n\n## Property-Based Testing\n\nProperty-based testing generates random inputs to verify invariants instead of relying on hand-picked examples. Use it when the input space is large and the expected behavior can be described as a property.\n\n### Python — Hypothesis\n\n```python\nfrom hypothesis import given, strategies as st\nfrom app.serializers import serialize, deserialize\n\n@given(st.text())\ndef test_roundtrip_serialization(data):\n    \"\"\"Serialization followed by deserialization returns the original.\"\"\"\n    assert deserialize(serialize(data)) == data\n\n@given(st.integers(), st.integers())\ndef test_addition_is_commutative(a, b):\n    assert a + b == b + a\n```\n\n### TypeScript — fast-check\n\n```typescript\nimport fc from \"fast-check\";\nimport { encode, decode } from \".\u002Fcodec\";\n\ntest(\"encode\u002Fdecode roundtrip\", () => {\n  fc.assert(\n    fc.property(fc.string(), (input) => {\n      expect(decode(encode(input))).toBe(input);\n    })\n  );\n});\n```\n\n### When to Use Property-Based Over Example-Based\n\n| Use Property-Based | Example |\n|-------------------|---------|\n| Data transformations | Serialize\u002Fdeserialize roundtrips |\n| Mathematical properties | Commutativity, associativity, idempotency |\n| Encoding\u002Fdecoding | Base64, URL encoding, compression |\n| Sorting and filtering | Output is sorted, length preserved |\n| Parser correctness | Valid input always parses without error |\n\n---\n\n## Mutation Testing\n\nMutation testing modifies your production code (creates \"mutants\") and checks whether your tests catch the changes. If a mutant survives (tests still pass), your tests have a gap that coverage alone cannot reveal.\n\n### Tools\n\n| Language | Tool | Command |\n|----------|------|---------|\n| TypeScript\u002FJavaScript | **Stryker** | `npx stryker run` |\n| Python | **mutmut** | `mutmut run --paths-to-mutate=src\u002F` |\n| Java | **PIT** | `mvn org.pitest:pitest-maven:mutationCoverage` |\n\n### Why Mutation Testing Matters\n\n- **100% line coverage != good tests** — coverage tells you code was executed, not that it was verified\n- **Catches weak assertions** — tests that run code but assert nothing meaningful\n- **Finds missing boundary tests** — mutants that change `\u003C` to `\u003C=` expose off-by-one gaps\n- **Quantifiable quality metric** — mutation score (% mutants killed) is a stronger signal than coverage %\n\n**Recommendation:** Run mutation testing on critical paths (auth, payments, data processing) even if overall coverage is high. Target 85%+ mutation score on P0 modules.\n\n---\n\n## Cross-References\n\n| Skill | Relationship |\n|-------|-------------|\n| `engineering\u002Fspec-driven-workflow` | Spec → acceptance criteria → test extraction pipeline |\n| `engineering-team\u002Ffocused-fix` | Phase 5 (Verify) uses TDD to confirm the fix with a regression test |\n| `engineering-team\u002Fsenior-qa` | Broader QA strategy; TDD is one layer in the test pyramid |\n| `engineering-team\u002Fcode-reviewer` | Review generated tests for assertion quality and coverage completeness |\n| `engineering-team\u002Fsenior-fullstack` | Project scaffolders include testing infrastructure compatible with TDD workflows |\n\n---\n\n## Limitations\n\n| Scope | Details |\n|-------|---------|\n| Unit test focus | Integration and E2E tests require different patterns |\n| Static analysis | Cannot execute tests or measure runtime behavior |\n| Language support | Best for TypeScript, JavaScript, Python, Java |\n| Report formats | LCOV, JSON, XML only; other formats need conversion |\n| Generated tests | Provide scaffolding; require human review for complex logic |\n\n**When to use other tools:**\n- E2E testing: Playwright, Cypress, Selenium\n- Performance testing: k6, JMeter, Locust\n- Security testing: OWASP ZAP, Burp Suite\n",{"name":48,"description":49},"tdd-guide","Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and Mocha. Use when the user asks to write tests, improve test coverage, practice TDD, generate mocks or stubs, or mentions testing frameworks like Jest, pytest, or JUnit.","main","510dd2917e051cc953dc55f56fd6ef442aa01b38","codex\u002Fskills\u002Fvercel-deploy",3,"https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config","https:\u002F\u002Fgithub.com\u002Fsalexandr0s","https:\u002F\u002Fsavorg.xyz\u002F","Solo building with agents since 2025. Learning as i do. Do not blindly trust my code.","2026-11-09 09:22:33",{"source":8,"skillName":48,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add salexandr0s\u002Fai-config --skill tdd-guide",{"tool":65,"command":66},"bunx","bunx skills add salexandr0s\u002Fai-config --skill tdd-guide",{"tool":68,"command":69},"pnpm","pnpm dlx skills add salexandr0s\u002Fai-config --skill tdd-guide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002FSKILL.md",true,[73,79,85,89,93,97,101,105,109,114,118,122,126,130,136,140,144,148,152,156,160,164],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"agents\u002Fopenai.yaml","REFERENCE","参考文档",306,"https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002Fagents\u002Fopenai.yaml",{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"assets\u002Fexpected_output.json","ASSET","资产文件",2404,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fassets\u002Fexpected_output.json",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"assets\u002Fsample_coverage_report.lcov",615,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fassets\u002Fsample_coverage_report.lcov",{"path":90,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":91,"sourceHtmlUrl":92},"assets\u002Fsample_input_python.json",1443,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fassets\u002Fsample_input_python.json",{"path":94,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":95,"sourceHtmlUrl":96},"assets\u002Fsample_input_typescript.json",1469,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fassets\u002Fsample_input_typescript.json",{"path":98,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":99,"sourceHtmlUrl":100},"assets\u002Fvercel-small.svg",243,"https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002Fassets\u002Fvercel-small.svg",{"path":102,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":103,"sourceHtmlUrl":104},"assets\u002Fvercel.png",788,"https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002Fassets\u002Fvercel.png",{"path":106,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":107,"sourceHtmlUrl":108},"HOW_TO_USE.md",7176,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002FHOW_TO_USE.md",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",1063,{"path":115,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":116,"sourceHtmlUrl":117},"README.md",18528,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002FREADME.md",{"path":119,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Fci-integration.md",4017,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Freferences\u002Fci-integration.md",{"path":123,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Fframework-guide.md",4316,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Freferences\u002Fframework-guide.md",{"path":127,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":128,"sourceHtmlUrl":129},"references\u002Ftdd-best-practices.md",3516,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Freferences\u002Ftdd-best-practices.md",{"path":131,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":134,"sourceHtmlUrl":135},"scripts\u002Fcoverage_analyzer.py","SCRIPT","脚本",15502,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Fcoverage_analyzer.py",{"path":137,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":138,"sourceHtmlUrl":139},"scripts\u002Fdeploy.sh",8877,"https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fcodex\u002Fskills\u002Fvercel-deploy\u002Fscripts\u002Fdeploy.sh",{"path":141,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":142,"sourceHtmlUrl":143},"scripts\u002Ffixture_generator.py",14311,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Ffixture_generator.py",{"path":145,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":146,"sourceHtmlUrl":147},"scripts\u002Fformat_detector.py",12207,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Fformat_detector.py",{"path":149,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":150,"sourceHtmlUrl":151},"scripts\u002Fframework_adapter.py",14834,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Fframework_adapter.py",{"path":153,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":154,"sourceHtmlUrl":155},"scripts\u002Fmetrics_calculator.py",15476,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Fmetrics_calculator.py",{"path":157,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":158,"sourceHtmlUrl":159},"scripts\u002Foutput_formatter.py",12734,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Foutput_formatter.py",{"path":161,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":162,"sourceHtmlUrl":163},"scripts\u002Ftdd_workflow.py",16968,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Ftdd_workflow.py",{"path":165,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":166,"sourceHtmlUrl":167},"scripts\u002Ftest_generator.py",14617,"https:\u002F\u002Fgithub.com\u002Fmne20114-hash\u002Fgest35bi\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fengineering-team\u002Fskills\u002Ftdd-guide\u002Fscripts\u002Ftest_generator.py",[169,200,229,252,275,306],{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":173,"sourceHtmlUrl":174,"categories":175,"keywords":179,"publishedAt":43},"01M6HN7EHN65GQEVEHWJ146W8C","swiftui-performance-audit","Audit and improve SwiftUI runtime performance from code review and architecture. Use for requests to diagnose slow rendering, janky scrolling, high CPU\u002Fmemory usage, excessive view updates, or layout thrash in SwiftUI apps, and to provide guidance for user-run Instruments profiling when code review alone is insufficient.","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fswiftui-performance-audit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fswiftui-performance-audit\u002FSKILL.md",[176],{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",[180,181,182,183,184,185,186,187,188,189,190,191,192,36,193,194,195,196,197,198,199,27],"performance","swiftui performance audit","audit","swiftui","performance audit","code review","review","memory","architecture","diagnose","code","improve","view","instruments profiling","runtime","apps","usage","updates","high","for",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":204,"sourceHtmlUrl":205,"categories":206,"keywords":210,"publishedAt":43},"01M6HN68GQ9MYF3VVJ8RH8EE54","stageshow","Build faux product UI that looks like a real product, as a still illustration or an animated demo with a cursor. Browser and app windows, dashboards, phones, notifications, terminals, bento grids and cursor walkthroughs, framed, masked and cropped the way a marketing page, feature card or docs hero needs them. Use whenever someone wants a fake or mocked UI, a product demo or walkthrough animation, a hero or feature-card illustration of an app, a product shot in the style of a polished marketing site, or an animated cursor doing things in an interface, even if they never say \"faux UI\". React and plain CSS.","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fstageshow\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fstageshow\u002FSKILL.md",[207],{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[202,211,212,213,214,215,216,217,218,219,36,220,221,222,223,31,224,225,226,227,228],"css","react","windows","browser","demo","notifications","Animation","walkthrough","page","never","illustration","feature","as","framed","card","interface","things","hero",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":233,"sourceHtmlUrl":234,"categories":235,"keywords":236,"publishedAt":43},"01M6HN62WDPD2REKFZ0QH712BA","shadcn","Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn\u002Fui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for \"shadcn init\", \"create an app with --preset\", or \"switch to --preset\".","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fshadcn\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fshadcn\u002FSKILL.md",[],[231,237,238,239,240,241,41,242,243,244,245,246,247,31,248,249,250,251,196,199,27],"components","component","init","preset","debugging","file","examples","projects","switch","project","triggers","false","component docs","codes","with",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":256,"licenseFileUrl":257,"sourceHtmlUrl":258,"categories":259,"keywords":260,"publishedAt":43},"01M6HN5Z52QN1BF5B0XNHEN4FZ","portless","Set up and use portless for named local dev server URLs (e.g. https:\u002F\u002Fmyapp.localhost instead of http:\u002F\u002Flocalhost:3000). Use when integrating portless into a project, configuring dev server names, setting up the local proxy, working with .localhost domains, or troubleshooting port\u002Fproxy issues.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fportless\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fportless\u002FSKILL.md",[],[254,261,262,263,264,265,266,267,268,269,36,270,271,272,246,273,274,251,199,27],"local dev","http","dev","issues","proxy","https","server","SET","troubleshooting","local dev server","up","local","domains","port",{"skillNo":276,"name":277,"nameZh":6,"description":278,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":279,"sourceHtmlUrl":280,"categories":281,"keywords":288,"publishedAt":43},"01M6HN5MXHWEVRWHPPZ0S5AE3A","ios-simulator-skill","21 production-ready scripts for iOS app testing, building, and automation. Provides semantic UI navigation, build automation, accessibility testing, and simulator lifecycle management. Optimized for AI agents with minimal token output.","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fios-simulator-skill\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fios-simulator-skill\u002FSKILL.md",[282,285],{"categoryNo":283,"categoryName":284,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":286,"categoryName":287,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[289,290,291,292,293,294,295,296,297,298,299,300,301,302,31,303,304,251,305,199],"ios","ios simulator skill","ios simulator","testing","ai agents","automation","accessibility","lifecycle","ready","minimal","build","accessibility testing","ios app","token","scripts","output","production-ready",{"skillNo":307,"name":308,"nameZh":6,"description":309,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":256,"licenseFileUrl":310,"sourceHtmlUrl":311,"categories":312,"keywords":313,"publishedAt":43},"01M6HN48WA9ZZNPR7C3A43Z4X1","deepsec","Run deepsec, an AI-powered cyber-security vulnerability scanner. Activates when the user invokes \u002Fdeepsec, asks to run deepsec, or wants to scan their repo, branch, or uncommitted changes for vulnerabilities.","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fdeepsec\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fsalexandr0s\u002Fai-config\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Fdeepsec\u002FSKILL.md",[],[308,314,315,316,317,318,319,320,321,37,322,323,324,199,325,27],"security","security vulnerability","vulnerabilities","run","vulnerability","vulnerability scanner","branch","repo","scanner","scan","security vulnerability scanner","changes"]