[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X1VZXHMSWA7MYXMQK4Q9CX":3,"skill-same:01M6X1VZXHMSWA7MYXMQK4Q9CX":86},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":14,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6X1VZXHMSWA7MYXMQK4Q9CX","integration-testing",null,"Integration and E2E testing patterns — testcontainers, fixtures, API mocking, snapshots, and CI isolation. Use when writing integration tests against databases, APIs, or queues; setting up testcontainers or fixture infrastructure; mocking external APIs; or debugging flaky tests.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fintegration-testing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[27,28,29,30,31,32,5,33,34,35,36,37,38,39,40,41,42,43,44,45],"integration","integration testing","testing","up","when","v1","mocking","tests","fixture","snapshots","databases","use","e2e","testing patterns","e2e testing patterns","ci","debugging","integration tests","writing","2026-11-10 10:12:30",false,"---\nname: integration-testing\ndescription: |\n  Integration and E2E testing patterns — testcontainers, fixtures, API mocking, snapshots, and CI isolation. Use when writing integration tests against databases, APIs, or queues; setting up testcontainers or fixture infrastructure; mocking external APIs; or debugging flaky tests.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-integration-testing\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Integration Testing\n\n## Intro\n\nIntegration tests verify that your code works against real\ncollaborators — databases, APIs, queues — not just mocks. The trick\nis keeping them fast, isolated, and reproducible. Disposable\ncontainers, per-test fixtures, and strict API mocks are the\nprimary tools.\n\n## Overview\n\n### Testcontainers\n\nSpin up real services as disposable containers for the duration of\nthe test suite:\n\n- Each suite gets its own container — no shared state.\n- Use fixed image tags (not `latest`) for reproducibility.\n- Set health checks or wait strategies so tests start only after\n  the service is ready.\n- Tear down after the suite (most libraries handle this via RAII\n  or `afterAll`).\n\nSupported in Python (`testcontainers`), Rust (`testcontainers`),\nJS\u002FTS (`testcontainers`), Java (`testcontainers`), and Go\n(`testcontainers-go`).\n\n### Database fixtures\n\nThree core strategies:\n\n- **Factories** — generate objects with sensible defaults; override\n  only what matters per test.\n- **Fixtures** — predefined datasets loaded before tests; good for\n  read-heavy tests.\n- **Seeds** — baseline data loaded once for the suite; reset per\n  test via transactions.\n\nCleanup approaches (pick one per project):\n\n| Approach | Speed | Isolation | Multi-Connection |\n|----------|-------|-----------|------------------|\n| Transaction rollback | Fast | Per-test | No (single conn) |\n| TRUNCATE + CASCADE | Medium | Per-test | Yes |\n| DROP + CREATE schema | Slow | Per-suite | Yes |\n| Disposable container | Slow | Per-suite | Yes |\n\nDefault to transaction rollback. Fall back to truncation when you\nneed multiple connections (e.g. concurrent access tests). Use\ndisposable containers for full isolation in CI.\n\n### API mocking\n\nMock external HTTP APIs so integration tests run without network\ndependencies:\n\n| Tool | Language | Approach |\n|------|----------|----------|\n| **WireMock** | Java, standalone | Local HTTP server matching by URL\u002Fbody |\n| **MSW** | JS\u002FTS | Network-level interception via Service Workers \u002F node interceptors |\n| **nock** | Node.js | Patches `http`\u002F`https` modules |\n| **httpmock** | Rust | Local mock server with registered expectations |\n| **responses** | Python | Decorators that intercept `requests` calls |\n\nBest practices:\n\n- Assert on what the code sent (method, headers, body), not just\n  the response.\n- Use strict mode — fail on any unexpected request.\n- Record real API responses once and replay in CI (contract\n  tests).\n\n### Snapshot and E2E\n\nSnapshot tests capture function or component output and compare\nagainst a stored baseline. Good for serialized JSON, rendered HTML,\nCLI output, and error messages. Update intentionally\n(`--update-snapshots` \u002F `-u`) and review diffs in PRs. Store\nsnapshots next to tests in version control. Normalize volatile\ndata (timestamps, random IDs) before snapshotting.\n\nFor E2E:\n\n- **Page Object Model** — encapsulate page interactions; tests\n  read like user stories.\n- **Arrange-Act-Assert** — set up state, perform the action,\n  verify the outcome.\n- Test user journeys, not individual pages. One E2E test should\n  cover a meaningful flow.\n- Use dedicated test accounts and isolated environments. Never\n  test against production data.\n\n### CI isolation and flaky tests\n\n- Run integration tests in a separate CI job with longer timeouts.\n- Use testcontainers or Docker Compose for backing services.\n- Give each parallel worker a unique database\u002Fschema.\n- Set per-test timeouts (not just per-job) to catch hangs.\n- Cache container images in CI to speed up startup.\n\nCommon flaky-test causes and fixes:\n\n- **Shared state** — per-test databases or transaction rollback.\n- **Timing\u002Frace conditions** — replace `sleep` with explicit\n  wait-for conditions.\n- **Non-deterministic ordering** — randomize test order in CI to\n  surface hidden dependencies.\n- **Network flakiness** — mock all external APIs.\n- **Resource exhaustion** — limit parallelism, close connections.\n\nA flaky test that is ignored is worse than no test at all. Tag\nknown flaky tests and track them.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Sharing a single database across parallel test workers.** Parallel workers reading and writing to the same schema produces ordering-dependent failures and data contamination. Give each worker a unique database or schema, or use per-test transaction rollback.\n- **Using `sleep()` to wait for async behavior.** Fixed delays are both fragile (fail on slow CI runners) and wasteful (over-wait on fast machines). Replace with explicit wait-for conditions that poll until the expected state is reached or a timeout fires.\n- **Mocking the unit under test instead of its boundary.** If the code being tested is itself replaced by a mock, the test verifies nothing. Mocks belong at the boundary — the external API, database, or queue — not inside the module under test.\n- **Asserting only on response shape, never on the request the code sent.** Testing that \"we got a 200\" but not verifying the request body, headers, or method means outbound contract violations go undetected. Assert on what the code sent, not just what it received.\n- **Snapshotting timestamps or random IDs without normalization.** Snapshots that contain `created_at: 2026-04-08T10:23:11Z` or `id: \"f3a2...\"` fail on every run. Normalize or mask volatile fields before snapshotting.\n- **Marking flaky tests as skipped without assigning an owner.** A skipped test is a test that never catches anything. Tag the test with the owner's handle and a follow-up date; skipped tests must be fixed before a release.\n- **Using `latest` image tags for testcontainers.** When an upstream container image is updated, CI breaks unpredictably. Pin testcontainer images to fixed tags (`postgres:16-alpine`, not `postgres:latest`) for reproducible CI runs.\n\n## Full reference\n\n### Testcontainers with Postgres (Python)\n\n```python\nimport pytest\nfrom testcontainers.postgres import PostgresContainer\nfrom sqlalchemy import create_engine, text\n\n@pytest.fixture(scope=\"module\")\ndef db_engine():\n    with PostgresContainer(\"postgres:16-alpine\") as pg:\n        engine = create_engine(pg.get_connection_url())\n        with engine.begin() as conn:\n            conn.execute(text(\"CREATE TABLE users (id SERIAL, name TEXT)\"))\n        yield engine\n\ndef test_insert_and_query_user(db_engine):\n    with db_engine.begin() as conn:\n        conn.execute(text(\"INSERT INTO users (name) VALUES (:n)\"), {\"n\": \"Alice\"})\n        result = conn.execute(text(\"SELECT name FROM users\")).fetchone()\n    assert result[0] == \"Alice\"\n```\n\n### API mocking with MSW (TypeScript)\n\n```typescript\nimport { http, HttpResponse } from \"msw\";\nimport { setupServer } from \"msw\u002Fnode\";\nimport { fetchWeather } from \"..\u002Fsrc\u002Fweather\";\n\nconst server = setupServer(\n  http.get(\"https:\u002F\u002Fapi.weather.example\u002Fcurrent\", ({ request }) => {\n    const url = new URL(request.url);\n    if (url.searchParams.get(\"city\") === \"Berlin\") {\n      return HttpResponse.json({ temp: 18, condition: \"cloudy\" });\n    }\n    return new HttpResponse(null, { status: 404 });\n  })\n);\n\nbeforeAll(() => server.listen({ onUnhandledRequest: \"error\" }));\nafterEach(() => server.resetHandlers());\nafterAll(() => server.close());\n\ntest(\"returns weather for known city\", async () => {\n  const weather = await fetchWeather(\"Berlin\");\n  expect(weather.temp).toBe(18);\n});\n```\n\n### httpmock (Rust)\n\n```rust\nuse httpmock::prelude::*;\nuse reqwest;\n\n#[tokio::test]\nasync fn test_client_sends_auth_header() {\n    let server = MockServer::start();\n    let mock = server.mock(|when, then| {\n        when.method(GET)\n            .path(\"\u002Fapi\u002Fdata\")\n            .header(\"Authorization\", \"Bearer test-token\");\n        then.status(200)\n            .json_body_obj(&serde_json::json!({\"items\": [1, 2, 3]}));\n    });\n\n    let client = ApiClient::new(&server.base_url(), \"test-token\");\n    let result = client.fetch_data().await.unwrap();\n\n    assert_eq!(result.items, vec![1, 2, 3]);\n    mock.assert();\n}\n```\n\n### Fixture patterns\n\nFor deeper fixture and factory patterns across Python, TypeScript,\nand Rust, see `references\u002Ftest-fixtures.md`. Key takeaways:\n\n- **pytest fixtures** — use `scope=\"session\"` for an engine and\n  `scope=\"function\"` with transaction rollback for a per-test\n  session. `factory_boy` handles complex object graphs via\n  `SubFactory`.\n- **TypeScript** — pair `beforeEach` truncation with builder\n  functions or a `Builder` class for complex fixtures. Order\n  truncations to respect foreign keys.\n- **Rust** — implement a `TestUserBuilder` with `.insert(pool)` or\n  `.insert_tx(&mut tx)` methods. `#[sqlx::test]` plus\n  per-test transactions gives automatic rollback on drop.\n\n### Database seeding strategies\n\n- **Minimal seed** (recommended) — each test creates only the data\n  it needs through factories. Tests stay independent and easy to\n  read.\n- **Shared baseline seed** — load reference data (countries,\n  roles) once per suite; tests add their own records on top. Good\n  for read-heavy suites.\n- **Snapshot seed** — dump a known-good database state to a SQL\n  file or container image and restore before each suite. Fastest\n  for large datasets but harder to maintain.\n\n### Anti-patterns\n\n- Sharing a single database across parallel test workers\n- Using `sleep()` to wait for async behavior\n- Mocking the unit under test instead of its boundary\n- Asserting only on response shape, never on the request the code\n  sent\n- Snapshotting timestamps or random IDs without normalization\n- Marking flaky tests as skipped without an owner or follow-up\n","# Integration Testing\n\n## Intro\n\nIntegration tests verify that your code works against real\ncollaborators — databases, APIs, queues — not just mocks. The trick\nis keeping them fast, isolated, and reproducible. Disposable\ncontainers, per-test fixtures, and strict API mocks are the\nprimary tools.\n\n## Overview\n\n### Testcontainers\n\nSpin up real services as disposable containers for the duration of\nthe test suite:\n\n- Each suite gets its own container — no shared state.\n- Use fixed image tags (not `latest`) for reproducibility.\n- Set health checks or wait strategies so tests start only after\n  the service is ready.\n- Tear down after the suite (most libraries handle this via RAII\n  or `afterAll`).\n\nSupported in Python (`testcontainers`), Rust (`testcontainers`),\nJS\u002FTS (`testcontainers`), Java (`testcontainers`), and Go\n(`testcontainers-go`).\n\n### Database fixtures\n\nThree core strategies:\n\n- **Factories** — generate objects with sensible defaults; override\n  only what matters per test.\n- **Fixtures** — predefined datasets loaded before tests; good for\n  read-heavy tests.\n- **Seeds** — baseline data loaded once for the suite; reset per\n  test via transactions.\n\nCleanup approaches (pick one per project):\n\n| Approach | Speed | Isolation | Multi-Connection |\n|----------|-------|-----------|------------------|\n| Transaction rollback | Fast | Per-test | No (single conn) |\n| TRUNCATE + CASCADE | Medium | Per-test | Yes |\n| DROP + CREATE schema | Slow | Per-suite | Yes |\n| Disposable container | Slow | Per-suite | Yes |\n\nDefault to transaction rollback. Fall back to truncation when you\nneed multiple connections (e.g. concurrent access tests). Use\ndisposable containers for full isolation in CI.\n\n### API mocking\n\nMock external HTTP APIs so integration tests run without network\ndependencies:\n\n| Tool | Language | Approach |\n|------|----------|----------|\n| **WireMock** | Java, standalone | Local HTTP server matching by URL\u002Fbody |\n| **MSW** | JS\u002FTS | Network-level interception via Service Workers \u002F node interceptors |\n| **nock** | Node.js | Patches `http`\u002F`https` modules |\n| **httpmock** | Rust | Local mock server with registered expectations |\n| **responses** | Python | Decorators that intercept `requests` calls |\n\nBest practices:\n\n- Assert on what the code sent (method, headers, body), not just\n  the response.\n- Use strict mode — fail on any unexpected request.\n- Record real API responses once and replay in CI (contract\n  tests).\n\n### Snapshot and E2E\n\nSnapshot tests capture function or component output and compare\nagainst a stored baseline. Good for serialized JSON, rendered HTML,\nCLI output, and error messages. Update intentionally\n(`--update-snapshots` \u002F `-u`) and review diffs in PRs. Store\nsnapshots next to tests in version control. Normalize volatile\ndata (timestamps, random IDs) before snapshotting.\n\nFor E2E:\n\n- **Page Object Model** — encapsulate page interactions; tests\n  read like user stories.\n- **Arrange-Act-Assert** — set up state, perform the action,\n  verify the outcome.\n- Test user journeys, not individual pages. One E2E test should\n  cover a meaningful flow.\n- Use dedicated test accounts and isolated environments. Never\n  test against production data.\n\n### CI isolation and flaky tests\n\n- Run integration tests in a separate CI job with longer timeouts.\n- Use testcontainers or Docker Compose for backing services.\n- Give each parallel worker a unique database\u002Fschema.\n- Set per-test timeouts (not just per-job) to catch hangs.\n- Cache container images in CI to speed up startup.\n\nCommon flaky-test causes and fixes:\n\n- **Shared state** — per-test databases or transaction rollback.\n- **Timing\u002Frace conditions** — replace `sleep` with explicit\n  wait-for conditions.\n- **Non-deterministic ordering** — randomize test order in CI to\n  surface hidden dependencies.\n- **Network flakiness** — mock all external APIs.\n- **Resource exhaustion** — limit parallelism, close connections.\n\nA flaky test that is ignored is worse than no test at all. Tag\nknown flaky tests and track them.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Sharing a single database across parallel test workers.** Parallel workers reading and writing to the same schema produces ordering-dependent failures and data contamination. Give each worker a unique database or schema, or use per-test transaction rollback.\n- **Using `sleep()` to wait for async behavior.** Fixed delays are both fragile (fail on slow CI runners) and wasteful (over-wait on fast machines). Replace with explicit wait-for conditions that poll until the expected state is reached or a timeout fires.\n- **Mocking the unit under test instead of its boundary.** If the code being tested is itself replaced by a mock, the test verifies nothing. Mocks belong at the boundary — the external API, database, or queue — not inside the module under test.\n- **Asserting only on response shape, never on the request the code sent.** Testing that \"we got a 200\" but not verifying the request body, headers, or method means outbound contract violations go undetected. Assert on what the code sent, not just what it received.\n- **Snapshotting timestamps or random IDs without normalization.** Snapshots that contain `created_at: 2026-04-08T10:23:11Z` or `id: \"f3a2...\"` fail on every run. Normalize or mask volatile fields before snapshotting.\n- **Marking flaky tests as skipped without assigning an owner.** A skipped test is a test that never catches anything. Tag the test with the owner's handle and a follow-up date; skipped tests must be fixed before a release.\n- **Using `latest` image tags for testcontainers.** When an upstream container image is updated, CI breaks unpredictably. Pin testcontainer images to fixed tags (`postgres:16-alpine`, not `postgres:latest`) for reproducible CI runs.\n\n## Full reference\n\n### Testcontainers with Postgres (Python)\n\n```python\nimport pytest\nfrom testcontainers.postgres import PostgresContainer\nfrom sqlalchemy import create_engine, text\n\n@pytest.fixture(scope=\"module\")\ndef db_engine():\n    with PostgresContainer(\"postgres:16-alpine\") as pg:\n        engine = create_engine(pg.get_connection_url())\n        with engine.begin() as conn:\n            conn.execute(text(\"CREATE TABLE users (id SERIAL, name TEXT)\"))\n        yield engine\n\ndef test_insert_and_query_user(db_engine):\n    with db_engine.begin() as conn:\n        conn.execute(text(\"INSERT INTO users (name) VALUES (:n)\"), {\"n\": \"Alice\"})\n        result = conn.execute(text(\"SELECT name FROM users\")).fetchone()\n    assert result[0] == \"Alice\"\n```\n\n### API mocking with MSW (TypeScript)\n\n```typescript\nimport { http, HttpResponse } from \"msw\";\nimport { setupServer } from \"msw\u002Fnode\";\nimport { fetchWeather } from \"..\u002Fsrc\u002Fweather\";\n\nconst server = setupServer(\n  http.get(\"https:\u002F\u002Fapi.weather.example\u002Fcurrent\", ({ request }) => {\n    const url = new URL(request.url);\n    if (url.searchParams.get(\"city\") === \"Berlin\") {\n      return HttpResponse.json({ temp: 18, condition: \"cloudy\" });\n    }\n    return new HttpResponse(null, { status: 404 });\n  })\n);\n\nbeforeAll(() => server.listen({ onUnhandledRequest: \"error\" }));\nafterEach(() => server.resetHandlers());\nafterAll(() => server.close());\n\ntest(\"returns weather for known city\", async () => {\n  const weather = await fetchWeather(\"Berlin\");\n  expect(weather.temp).toBe(18);\n});\n```\n\n### httpmock (Rust)\n\n```rust\nuse httpmock::prelude::*;\nuse reqwest;\n\n#[tokio::test]\nasync fn test_client_sends_auth_header() {\n    let server = MockServer::start();\n    let mock = server.mock(|when, then| {\n        when.method(GET)\n            .path(\"\u002Fapi\u002Fdata\")\n            .header(\"Authorization\", \"Bearer test-token\");\n        then.status(200)\n            .json_body_obj(&serde_json::json!({\"items\": [1, 2, 3]}));\n    });\n\n    let client = ApiClient::new(&server.base_url(), \"test-token\");\n    let result = client.fetch_data().await.unwrap();\n\n    assert_eq!(result.items, vec![1, 2, 3]);\n    mock.assert();\n}\n```\n\n### Fixture patterns\n\nFor deeper fixture and factory patterns across Python, TypeScript,\nand Rust, see `references\u002Ftest-fixtures.md`. Key takeaways:\n\n- **pytest fixtures** — use `scope=\"session\"` for an engine and\n  `scope=\"function\"` with transaction rollback for a per-test\n  session. `factory_boy` handles complex object graphs via\n  `SubFactory`.\n- **TypeScript** — pair `beforeEach` truncation with builder\n  functions or a `Builder` class for complex fixtures. Order\n  truncations to respect foreign keys.\n- **Rust** — implement a `TestUserBuilder` with `.insert(pool)` or\n  `.insert_tx(&mut tx)` methods. `#[sqlx::test]` plus\n  per-test transactions gives automatic rollback on drop.\n\n### Database seeding strategies\n\n- **Minimal seed** (recommended) — each test creates only the data\n  it needs through factories. Tests stay independent and easy to\n  read.\n- **Shared baseline seed** — load reference data (countries,\n  roles) once per suite; tests add their own records on top. Good\n  for read-heavy suites.\n- **Snapshot seed** — dump a known-good database state to a SQL\n  file or container image and restore before each suite. Fastest\n  for large datasets but harder to maintain.\n\n### Anti-patterns\n\n- Sharing a single database across parallel test workers\n- Using `sleep()` to wait for async behavior\n- Mocking the unit under test instead of its boundary\n- Asserting only on response shape, never on the request the code\n  sent\n- Snapshotting timestamps or random IDs without normalization\n- Marking flaky tests as skipped without an owner or follow-up\n",{"name":5,"metadata":51,"description":58},{"processkit":52},{"id":53,"created":54,"version":55,"category":56,"apiVersion":57},"SKILL-integration-testing",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Integration and E2E testing patterns — testcontainers, fixtures, API mocking, snapshots, and CI isolation. Use when writing integration tests against databases, APIs, or queues; setting up testcontainers or fixture infrastructure; mocking external APIs; or debugging flaky tests.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fintegration-testing","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add projectious-work\u002Fprocesskit --skill integration-testing",{"tool":72,"command":73},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill integration-testing",{"tool":75,"command":76},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill integration-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fintegration-testing\u002FSKILL.md",true,[80],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Ftest-fixtures.md","REFERENCE","参考文档",6462,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fintegration-testing\u002Freferences\u002Ftest-fixtures.md",[87,112,132,153,170,188],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":96,"publishedAt":46},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[93],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[97,98,99,100,101,102,103,104,105,106,89,107,108,109,32,110,111],"management","skill management","create","update","package","alpha","work","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":46},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[118],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},[97,120,121,122,123,124,102,103,125,126,105,127,128,129,107,130,131],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":46},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[97,139,140,99,100,141,102,103,142,143,144,145,107,146,147,148,149,150,151,152],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":46},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[97,106,160,99,102,161,162,125,163,142,105,164,165,107,166,167,147,168,32,169],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":46},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[177,178,179,180,102,181,182,183,103,184,185,186,187],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":46},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[97,195,196,99,100,141,102,161,103,104,142,197,105,144,107,167,147,148,198,111],"capability","capability management","queries","changes"]