[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WX0GCSW2W8K0S0SAC056GG":3,"skill-same:01M6WX0GCSW2W8K0S0SAC056GG":78},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6WX0GCSW2W8K0S0SAC056GG","load-testing",null,"Load testing methodology — test types, scenario design, capacity planning, CI integration. Use when planning or running a load test, choosing a load testing tool, designing scenarios, analyzing results, setting up performance testing in CI, or estimating capacity from test data.","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.10.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fload-testing\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"load","load testing","testing","work","running","when","v1","types","test data","up","use","results","tool","ci","planning","performance testing","capacity","test","performance","design","2026-11-10 10:12:30",false,"---\nname: load-testing\ndescription: |\n  Load testing methodology — test types, scenario design, capacity planning, CI integration. Use when planning or running a load test, choosing a load testing tool, designing scenarios, analyzing results, setting up performance testing in CI, or estimating capacity from test data.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-load-testing\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Load Testing\n\n## Intro\n\nLoad tests answer specific questions: does it work, can it handle\nexpected traffic, where does it break, can it survive a spike, is\nthere long-term degradation. Always start with a smoke test, model\nreal user behavior, and capture latency percentiles — averages hide\nproblems.\n\n## Overview\n\n### Test types\n\nEach type answers a different question:\n\n| Type | VUs \u002F Load | Duration | Question It Answers |\n|---|---|---|---|\n| **Smoke** | 1-5 VUs | 1-2 min | Does it work at all under minimal load? |\n| **Load** | Expected traffic | 10-30 min | Can it handle normal production traffic? |\n| **Stress** | 2-5x expected | 10-30 min | Where does it break? What fails first? |\n| **Spike** | Sudden burst (10x) | 5-10 min | Can it handle sudden traffic surges? |\n| **Soak \u002F Endurance** | Normal traffic | 2-12 hours | Are there memory leaks or degradation over time? |\n\nAlways smoke first. A failing smoke test means you have a setup\nproblem, not a capacity problem.\n\n### Realistic scenarios\n\nA useful load test simulates real user behavior, not raw request\nthroughput:\n\n1. Identify key user journeys (login -> browse -> search -> checkout)\n2. Use realistic data — randomize IDs, search terms, and product IDs\n   from a dataset\n3. Include think time (1-5 s pauses between actions)\n4. Model traffic distribution (e.g. 60% browse, 25% search, 10% add\n   to cart, 5% checkout)\n5. Include authentication: token refresh, session management\n6. Account for downstream dependencies (payment providers, etc.)\n\n```javascript\n\u002F\u002F k6: realistic scenario with stages\nimport http from 'k6\u002Fhttp';\nimport { sleep, check } from 'k6';\n\nexport const options = {\n  stages: [\n    { duration: '2m', target: 50 },   \u002F\u002F ramp up\n    { duration: '5m', target: 50 },   \u002F\u002F hold steady\n    { duration: '2m', target: 200 },  \u002F\u002F stress\n    { duration: '5m', target: 200 },  \u002F\u002F hold stress\n    { duration: '2m', target: 0 },    \u002F\u002F ramp down\n  ],\n  thresholds: {\n    http_req_duration: ['p(95)\u003C500', 'p(99)\u003C1500'],\n    http_req_failed: ['rate\u003C0.01'],\n  },\n};\n\nexport default function () {\n  const res = http.get('https:\u002F\u002Fapi.example.com\u002Fproducts');\n  check(res, { 'status 200': (r) => r.status === 200 });\n  sleep(Math.random() * 3 + 1);  \u002F\u002F 1-4s think time\n}\n```\n\n### What to capture\n\n**Latency**: p50, p95, p99, and max — averages hide problems. Track\nper endpoint, not just aggregate. **Throughput**: successful\nrequests\u002Fsec. **Error rate**: 5xx, timeouts, connection refused.\n**Resource utilization** from monitoring: CPU per service, memory RSS\nand heap, connection pool usage, queue depth, network I\u002FO, open\nconnections.\n\n### Tool overview\n\n| Tool | Language | Strengths |\n|---|---|---|\n| **k6** | JavaScript | Developer-friendly scripting, good CLI output, Grafana integration |\n| **Locust** | Python | Easy to write complex scenarios, distributed mode, web UI |\n| **Gatling** | Scala\u002FJava | High performance, detailed HTML reports, CI-friendly |\n| **wrk** | Lua (config) | Extremely high throughput for simple URL hammering |\n| **hey** | Go | Simple CLI for quick benchmarks, no scripting needed |\n| **vegeta** | Go | Constant-rate load generation, good for precise RPS targets |\n\nUse k6 or Locust for realistic scenario testing. Use wrk or hey for\nquick single-endpoint benchmarks.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Running the load test from a single client machine that becomes the bottleneck.** A client generating 10,000 concurrent connections can exhaust its own ephemeral ports (typically 28,000), CPU, or memory before the server does, producing results that reflect the client's limits, not the server's. Distribute load generation across multiple machines or use a cloud-native load testing service for high VU counts.\n- **Hammering a single endpoint and declaring the system load-tested.** A test that hits `GET \u002Fproducts` 1000 times per second does not exercise authentication, write paths, search, or checkout — the code paths most likely to have bottlenecks. Model real user journeys with realistic traffic distribution across endpoints; include writes, auth flows, and the paths that touch the most downstream dependencies.\n- **Ignoring warm-up — measuring cold-start metrics as if they are steady-state.** The first 30–60 seconds of a load test often exercises JVM JIT compilation, connection pool warm-up, cold caches, and application initialization. These latencies are real but not representative of steady-state performance. Either discard the warm-up period from analysis or run a dedicated warm-up stage before measuring.\n- **Comparing results across test runs without controlling for environment state.** A latency improvement between Tuesday and Wednesday's runs might reflect cache state, different co-tenant load on a shared cloud host, or CPU frequency scaling — not your change. Run comparison tests back-to-back in the same environment with controlled initial state; treat cross-day comparisons as indicative, not conclusive.\n- **Reporting average latency instead of percentiles.** Average latency hides the long tail. A system with p50=50ms and p99=5000ms has an \"average\" of roughly 100ms that sounds acceptable — while 1% of users wait 5 seconds. Always report p50, p95, and p99. Use p99 as the primary SLA metric because it captures the worst experience of real users.\n- **Disabling auth, rate limiting, or caching to simplify the test.** Bypassing middleware to make the test simpler also removes the overhead that exists in production, producing results that cannot be extrapolated to real behavior. Test through the full production stack — with auth, rate limiting, and caching as configured — unless the specific goal is to isolate the application tier in isolation.\n- **Running load tests against production.** A load test can overwhelm a production system, spike database connections, corrupt cache state, or produce real charges (payment processors, SMS gateways). Load tests must target a dedicated environment with production-representative data volume but no real users or financial consequences.\n\n## Full reference\n\n### Identifying bottlenecks from results\n\nRead results systematically:\n\n- **Latency climbs linearly with load** — resource saturation (CPU,\n  DB connections, thread pool)\n- **Latency spikes periodically** — GC pauses, cron jobs, log\n  rotation, cache expiration\n- **Errors start at a specific VU count** — resource exhaustion (file\n  descriptors, connection pool, memory)\n- **Throughput plateaus while latency grows** — system at capacity;\n  find the saturated resource\n- **Errors only under concurrency** — race conditions, deadlocks,\n  connection pool starvation\n\nAlways correlate load test metrics with infrastructure monitoring\n(Grafana, Datadog, CloudWatch) to pinpoint the saturated component.\n\n### Capacity planning\n\nUse load test data to estimate scaling needs:\n\n1. Find the **throughput ceiling**: the RPS where p99 latency exceeds\n   your SLA\n2. Calculate **headroom**: production should run at 50-70% of the\n   ceiling for safety\n3. **Scale estimation**: if 1 instance handles 500 RPS at ceiling and\n   you need 2000 RPS, plan for 2000 \u002F 500 * 1.5 = 6 instances\n4. Verify with a load test against the scaled setup\n\n### CI integration\n\nAdd performance gates to prevent regressions:\n\n```yaml\n# GitHub Actions example with k6\n- name: Run load test\n  run: |\n    k6 run --out json=results.json load-test.js\n- name: Check thresholds\n  run: |\n    # k6 exits non-zero if thresholds fail\n    # Thresholds are defined in the test script\n```\n\nGuidelines for CI load tests:\n\n- Run smoke or light load tests on every PR (1-2 minutes)\n- Run full load tests nightly or before release\n- Use **relative thresholds** (compare to baseline) over absolute\n  values — environments drift\n- Test against a dedicated environment, never production\n- Store results historically to detect gradual degradation\n\n### Common mistakes\n\n- Running load tests from a single client box that itself becomes the\n  bottleneck (CPU, sockets, ephemeral ports)\n- Forgetting to disable rate limiting or auth caching during the test\n- Hammering one URL and declaring victory — that does not exercise\n  realistic code paths\n- Comparing runs across days without accounting for noisy neighbors,\n  CPU frequency scaling, or cache state\n- Ignoring warm-up — the first 30 seconds of any test usually\n  measures cold caches and JIT compilation, not steady state\n","# Load Testing\n\n## Intro\n\nLoad tests answer specific questions: does it work, can it handle\nexpected traffic, where does it break, can it survive a spike, is\nthere long-term degradation. Always start with a smoke test, model\nreal user behavior, and capture latency percentiles — averages hide\nproblems.\n\n## Overview\n\n### Test types\n\nEach type answers a different question:\n\n| Type | VUs \u002F Load | Duration | Question It Answers |\n|---|---|---|---|\n| **Smoke** | 1-5 VUs | 1-2 min | Does it work at all under minimal load? |\n| **Load** | Expected traffic | 10-30 min | Can it handle normal production traffic? |\n| **Stress** | 2-5x expected | 10-30 min | Where does it break? What fails first? |\n| **Spike** | Sudden burst (10x) | 5-10 min | Can it handle sudden traffic surges? |\n| **Soak \u002F Endurance** | Normal traffic | 2-12 hours | Are there memory leaks or degradation over time? |\n\nAlways smoke first. A failing smoke test means you have a setup\nproblem, not a capacity problem.\n\n### Realistic scenarios\n\nA useful load test simulates real user behavior, not raw request\nthroughput:\n\n1. Identify key user journeys (login -> browse -> search -> checkout)\n2. Use realistic data — randomize IDs, search terms, and product IDs\n   from a dataset\n3. Include think time (1-5 s pauses between actions)\n4. Model traffic distribution (e.g. 60% browse, 25% search, 10% add\n   to cart, 5% checkout)\n5. Include authentication: token refresh, session management\n6. Account for downstream dependencies (payment providers, etc.)\n\n```javascript\n\u002F\u002F k6: realistic scenario with stages\nimport http from 'k6\u002Fhttp';\nimport { sleep, check } from 'k6';\n\nexport const options = {\n  stages: [\n    { duration: '2m', target: 50 },   \u002F\u002F ramp up\n    { duration: '5m', target: 50 },   \u002F\u002F hold steady\n    { duration: '2m', target: 200 },  \u002F\u002F stress\n    { duration: '5m', target: 200 },  \u002F\u002F hold stress\n    { duration: '2m', target: 0 },    \u002F\u002F ramp down\n  ],\n  thresholds: {\n    http_req_duration: ['p(95)\u003C500', 'p(99)\u003C1500'],\n    http_req_failed: ['rate\u003C0.01'],\n  },\n};\n\nexport default function () {\n  const res = http.get('https:\u002F\u002Fapi.example.com\u002Fproducts');\n  check(res, { 'status 200': (r) => r.status === 200 });\n  sleep(Math.random() * 3 + 1);  \u002F\u002F 1-4s think time\n}\n```\n\n### What to capture\n\n**Latency**: p50, p95, p99, and max — averages hide problems. Track\nper endpoint, not just aggregate. **Throughput**: successful\nrequests\u002Fsec. **Error rate**: 5xx, timeouts, connection refused.\n**Resource utilization** from monitoring: CPU per service, memory RSS\nand heap, connection pool usage, queue depth, network I\u002FO, open\nconnections.\n\n### Tool overview\n\n| Tool | Language | Strengths |\n|---|---|---|\n| **k6** | JavaScript | Developer-friendly scripting, good CLI output, Grafana integration |\n| **Locust** | Python | Easy to write complex scenarios, distributed mode, web UI |\n| **Gatling** | Scala\u002FJava | High performance, detailed HTML reports, CI-friendly |\n| **wrk** | Lua (config) | Extremely high throughput for simple URL hammering |\n| **hey** | Go | Simple CLI for quick benchmarks, no scripting needed |\n| **vegeta** | Go | Constant-rate load generation, good for precise RPS targets |\n\nUse k6 or Locust for realistic scenario testing. Use wrk or hey for\nquick single-endpoint benchmarks.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Running the load test from a single client machine that becomes the bottleneck.** A client generating 10,000 concurrent connections can exhaust its own ephemeral ports (typically 28,000), CPU, or memory before the server does, producing results that reflect the client's limits, not the server's. Distribute load generation across multiple machines or use a cloud-native load testing service for high VU counts.\n- **Hammering a single endpoint and declaring the system load-tested.** A test that hits `GET \u002Fproducts` 1000 times per second does not exercise authentication, write paths, search, or checkout — the code paths most likely to have bottlenecks. Model real user journeys with realistic traffic distribution across endpoints; include writes, auth flows, and the paths that touch the most downstream dependencies.\n- **Ignoring warm-up — measuring cold-start metrics as if they are steady-state.** The first 30–60 seconds of a load test often exercises JVM JIT compilation, connection pool warm-up, cold caches, and application initialization. These latencies are real but not representative of steady-state performance. Either discard the warm-up period from analysis or run a dedicated warm-up stage before measuring.\n- **Comparing results across test runs without controlling for environment state.** A latency improvement between Tuesday and Wednesday's runs might reflect cache state, different co-tenant load on a shared cloud host, or CPU frequency scaling — not your change. Run comparison tests back-to-back in the same environment with controlled initial state; treat cross-day comparisons as indicative, not conclusive.\n- **Reporting average latency instead of percentiles.** Average latency hides the long tail. A system with p50=50ms and p99=5000ms has an \"average\" of roughly 100ms that sounds acceptable — while 1% of users wait 5 seconds. Always report p50, p95, and p99. Use p99 as the primary SLA metric because it captures the worst experience of real users.\n- **Disabling auth, rate limiting, or caching to simplify the test.** Bypassing middleware to make the test simpler also removes the overhead that exists in production, producing results that cannot be extrapolated to real behavior. Test through the full production stack — with auth, rate limiting, and caching as configured — unless the specific goal is to isolate the application tier in isolation.\n- **Running load tests against production.** A load test can overwhelm a production system, spike database connections, corrupt cache state, or produce real charges (payment processors, SMS gateways). Load tests must target a dedicated environment with production-representative data volume but no real users or financial consequences.\n\n## Full reference\n\n### Identifying bottlenecks from results\n\nRead results systematically:\n\n- **Latency climbs linearly with load** — resource saturation (CPU,\n  DB connections, thread pool)\n- **Latency spikes periodically** — GC pauses, cron jobs, log\n  rotation, cache expiration\n- **Errors start at a specific VU count** — resource exhaustion (file\n  descriptors, connection pool, memory)\n- **Throughput plateaus while latency grows** — system at capacity;\n  find the saturated resource\n- **Errors only under concurrency** — race conditions, deadlocks,\n  connection pool starvation\n\nAlways correlate load test metrics with infrastructure monitoring\n(Grafana, Datadog, CloudWatch) to pinpoint the saturated component.\n\n### Capacity planning\n\nUse load test data to estimate scaling needs:\n\n1. Find the **throughput ceiling**: the RPS where p99 latency exceeds\n   your SLA\n2. Calculate **headroom**: production should run at 50-70% of the\n   ceiling for safety\n3. **Scale estimation**: if 1 instance handles 500 RPS at ceiling and\n   you need 2000 RPS, plan for 2000 \u002F 500 * 1.5 = 6 instances\n4. Verify with a load test against the scaled setup\n\n### CI integration\n\nAdd performance gates to prevent regressions:\n\n```yaml\n# GitHub Actions example with k6\n- name: Run load test\n  run: |\n    k6 run --out json=results.json load-test.js\n- name: Check thresholds\n  run: |\n    # k6 exits non-zero if thresholds fail\n    # Thresholds are defined in the test script\n```\n\nGuidelines for CI load tests:\n\n- Run smoke or light load tests on every PR (1-2 minutes)\n- Run full load tests nightly or before release\n- Use **relative thresholds** (compare to baseline) over absolute\n  values — environments drift\n- Test against a dedicated environment, never production\n- Store results historically to detect gradual degradation\n\n### Common mistakes\n\n- Running load tests from a single client box that itself becomes the\n  bottleneck (CPU, sockets, ephemeral ports)\n- Forgetting to disable rate limiting or auth caching during the test\n- Hammering one URL and declaring victory — that does not exercise\n  realistic code paths\n- Comparing runs across days without accounting for noisy neighbors,\n  CPU frequency scaling, or cache state\n- Ignoring warm-up — the first 30 seconds of any test usually\n  measures cold caches and JIT compilation, not steady state\n",{"name":5,"metadata":49,"description":56},{"processkit":50},{"id":51,"created":52,"version":53,"category":54,"apiVersion":55},"SKILL-load-testing",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Load testing methodology — test types, scenario design, capacity planning, CI integration. Use when planning or running a load test, choosing a load testing tool, designing scenarios, analyzing results, setting up performance testing in CI, or estimating capacity from test data.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fload-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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add projectious-work\u002Fprocesskit --skill load-testing",{"tool":70,"command":71},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill load-testing",{"tool":73,"command":74},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill load-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fload-testing\u002FSKILL.md",true,[],[79,103,123,144,161,179],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":44},"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",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90,91,92,93,94,27,95,96,97,81,98,99,100,30,101,102],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":44},"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",[109],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[89,111,112,113,114,115,94,27,116,117,96,118,119,120,98,121,122],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":44},"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",[],[89,130,131,91,92,132,94,27,133,134,135,136,98,137,138,139,140,141,142,143],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":44},"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",[],[89,97,151,91,94,152,153,116,154,133,96,155,156,98,157,158,138,159,30,160],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":44},"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",[],[168,169,170,171,94,172,173,174,27,175,176,177,178],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":44},"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",[],[89,186,187,91,92,132,94,152,27,95,133,188,96,135,98,158,138,139,189,102],"capability","capability management","queries","changes"]