[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WYY8ADTGAKZXG64VT7ZDEB":3,"skill-same:01M6WYY8ADTGAKZXG64VT7ZDEB":85},{"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":64,"commitSha":65,"skillDirectory":66,"forksCount":14,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":70,"install":71,"resources":84},"01M6WYY8ADTGAKZXG64VT7ZDEB","microservice-creation",null,"Designs and scaffolds new microservices — covering service boundary\nidentification, inter-service communication patterns, containerisation,\nand orchestration. Use when asked to create a new service, extract a\nmicroservice from a monolith, design a service boundary, choose a\ncommunication pattern (REST vs gRPC vs events), or set up container\norchestration for a multi-service system.","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.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fmicroservice-creation\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,43],"microservice creation","microservice","creation","up","when","manifests","software","pattern","scaffolding","container orchestration","wed","design","work","choose","configure","heuristics","SET","communication","create","orchestration","2026-11-10 10:12:30",false,"---\nname: microservice-creation\ndescription: |\n  Designs and scaffolds new microservices — covering service boundary\n  identification, inter-service communication patterns, containerisation,\n  and orchestration. Use when asked to create a new service, extract a\n  microservice from a monolith, design a service boundary, choose a\n  communication pattern (REST vs gRPC vs events), or set up container\n  orchestration for a multi-service system.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-microservice-creation\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: engineering\n    uses:\n      - skill: software-modularization\n        purpose: Apply module boundary heuristics to identify where the service boundary belongs before scaffolding.\n      - skill: container-orchestration\n        purpose: Configure docker-compose or Kubernetes manifests for the new service.\n---\n\n# Microservice Creation\n\n## Intro\n\nA microservice is a module deployed as its own process, with its own\nnetwork address, its own data store, and its own release lifecycle. The\ndecision to create a new service has a higher cost than creating a new\nmodule inside an existing service — it introduces network latency,\ndistributed failure modes, and operational complexity. Make the decision\ndeliberately; use `software-modularization` first to confirm the boundary\nis right.\n\n## Overview\n\n### When to create a new service (and when not to)\n\n**Create a new service when:**\n- The component has a meaningfully different release cadence than the rest\n  of the system\n- The component needs to scale independently (different resource profile)\n- The component has a different trust boundary (security isolation required)\n- The team owning the component is genuinely independent and has no shared\n  release coordination with other teams\n- The component must be implemented in a different language or runtime\n\n**Do NOT create a new service just because:**\n- The module is large (decompose it first, within the monolith)\n- It would be \"cleaner\" to have it separate (cleanliness has network cost)\n- You want to try a new technology (try it in a module first)\n- The current architecture is a monolith and microservices are fashionable\n\n**The rule of thumb:** if you cannot articulate the independent deployment,\nscaling, or isolation benefit in one sentence, the boundary is not ready.\n\n### Service boundary identification\n\nBefore writing any code:\n\n1. **Name the domain** — what business concept does this service own?\n   \"User authentication\" and \"Billing\" are good domain names. \"Data processing\"\n   and \"Backend\" are not — they are too broad.\n2. **Define ownership** — what data does this service own? Data owned by a\n   service must not be read directly by other services (only via the API).\n   If two services share a database table, they are the same service.\n3. **Define the API contract** — what does this service expose? Write the\n   API contract (OpenAPI \u002F protobuf \u002F AsyncAPI) before writing any\n   implementation. The contract is the service.\n4. **Identify consumers** — which other services or clients will call this?\n   If the answer is \"everything,\" the service may be too fundamental to\n   extract safely.\n\n### Inter-service communication patterns\n\nChoose the pattern that matches the interaction semantics:\n\n| Pattern | Use when | Tradeoffs |\n|---|---|---|\n| **REST (HTTP\u002FJSON)** | Request-response; human-readable; browser clients | Synchronous coupling; retries needed for reliability |\n| **gRPC (protobuf)** | High-throughput; typed contracts; service-to-service | Binary protocol; harder to debug; needs proto tooling |\n| **Async events (queue\u002Fstream)** | Fire-and-forget; pub-sub; eventual consistency OK | Decoupled; harder to trace; requires idempotency |\n| **GraphQL** | Flexible queries; multiple consumers with different field needs | Complex server; N+1 risk; overkill for service-to-service |\n\n**Decision rule:**\n- If the caller needs an immediate response → REST or gRPC\n- If the caller does not need to wait → async events\n- If the contract is typed and high-volume → gRPC over REST\n- If external\u002Fbrowser clients are involved → REST\n\n### Scaffolding a new service\n\nMinimum scaffold for a containerised microservice:\n\n```\nservices\u002F\u003Cservice-name>\u002F\n  src\u002F              ← application code\n  tests\u002F            ← unit and integration tests\n  Dockerfile        ← production image\n  pyproject.toml    ← (or package.json, Cargo.toml, go.mod)\n  README.md         ← service purpose, API summary, local dev instructions\n  openapi.yaml      ← (or .proto file if gRPC)\n```\n\nAdding to the project:\n\n```\ndocker-compose.yml  ← add service entry with health check\ncontext\u002Fservices\u002F   ← add SERVICE-\u003Cname>.md entity for processkit tracking\n```\n\n### Containerisation essentials\n\nEvery service container must have:\n\n- **Explicit base image tag** — never `FROM python:latest`; pin to\n  `python:3.12-slim` or a digest\n- **Non-root user** — `RUN adduser --system appuser && USER appuser`\n- **Health check** — `HEALTHCHECK CMD curl -f http:\u002F\u002Flocalhost:8080\u002Fhealth`\n- **Read-only filesystem** where possible — `docker run --read-only`\n- **Resource limits** — set in docker-compose or Kubernetes manifests\n\n### Orchestration basics\n\n**docker-compose (local development + small deployments):**\n\n```yaml\nservices:\n  auth:\n    build: .\u002Fservices\u002Fauth\n    ports: [\"8081:8080\"]\n    environment:\n      DATABASE_URL: postgres:\u002F\u002F...\n    depends_on:\n      db:\n        condition: service_healthy\n    healthcheck:\n      test: [\"CMD\", \"curl\", \"-f\", \"http:\u002F\u002Flocalhost:8080\u002Fhealth\"]\n      interval: 10s\n      retries: 3\n```\n\n**Kubernetes (production):**\n- One `Deployment` per service (with `replicas`, `resources`, `livenessProbe`)\n- One `Service` (ClusterIP for internal; LoadBalancer\u002FIngress for external)\n- One `ConfigMap` for non-secret config; `Secret` for credentials\n- `HorizontalPodAutoscaler` if independent scaling is the reason for extraction\n\nSee `container-orchestration` skill for full Kubernetes patterns.\n\n## Gotchas\n\n- **Extracting a service before the module boundary is clean.** A microservice\n  built on top of a tangled module boundary imports the coupling into the\n  network layer, where it is far harder to fix. Always run the module\n  boundary checklist from `software-modularization` first. If the module\n  is not clean inside the monolith, the service will not be clean either.\n- **Sharing a database between services.** If two services read and write the\n  same database table, they are a distributed monolith — all the operational\n  complexity of microservices with none of the independence. Each service must\n  own its data exclusively; other services access it only via the API.\n- **Choosing synchronous communication for operations that don't need it.**\n  Every synchronous call is a dependency: if the downstream service is slow\n  or down, the upstream service is slow or down too. For operations where the\n  caller does not need an immediate result (sending an email, updating search\n  index, generating a report), use async events.\n- **No health check endpoint.** A service without a health check cannot be\n  safely orchestrated — the orchestrator cannot distinguish a starting service\n  from a crashed one. Every service must expose a `\u002Fhealth` or `\u002Fhealthz`\n  endpoint that returns 200 when ready to serve traffic.\n- **Forgetting idempotency for async consumers.** Message queues deliver\n  at-least-once. A consumer that processes a payment, sends an email, or\n  writes a database record must handle duplicate delivery — the second\n  delivery must produce the same result as the first. Design for it from the\n  start; retrofitting idempotency is painful.\n- **No distributed tracing from day one.** Once there are two services, a\n  request spans multiple processes. Without a correlation ID propagated\n  through every call, debugging a failure means reading logs from multiple\n  services with no way to connect them. Add `X-Trace-ID` (or OpenTelemetry)\n  before the first cross-service call.\n- **Not writing the API contract before the implementation.** A service whose\n  API is defined by its implementation (rather than a contract the\n  implementation satisfies) will drift as the implementation changes. Write\n  the OpenAPI spec or proto file first; implement against it. Contract-first\n  design forces clarity about what the service actually promises to do.\n\n## Full reference\n\n### Service readiness checklist\n\nBefore extracting a service from the monolith:\n\n- [ ] Domain name defined (one business concept)\n- [ ] Data ownership defined (no shared tables)\n- [ ] API contract written (OpenAPI \u002F proto) before implementation\n- [ ] Consumers identified and have agreed to the contract\n- [ ] Independent deployment case articulated (not just \"it would be cleaner\")\n- [ ] Health check endpoint planned\n- [ ] Tracing \u002F correlation ID propagation planned\n- [ ] Local dev story in docker-compose\n\n### Communication pattern decision tree\n\n```\nCaller needs immediate response?\n  Yes → gRPC (typed, high volume) or REST (human-readable, browser clients)\n  No  → Async events (queue \u002F stream)\n\nMultiple consumers with different field needs?\n  Yes → consider GraphQL (but only for external APIs)\n  No  → REST or gRPC\n\nPerformance-critical, service-to-service only?\n  Yes → gRPC\n  No  → REST\n```\n\n### Minimum viable Dockerfile\n\n```dockerfile\nFROM python:3.12-slim\n\nWORKDIR \u002Fapp\nRUN adduser --system --no-create-home appuser\n\nCOPY pyproject.toml .\u002F\nRUN pip install --no-cache-dir .\n\nCOPY src\u002F .\u002Fsrc\u002F\n\nUSER appuser\nEXPOSE 8080\nHEALTHCHECK CMD curl -f http:\u002F\u002Flocalhost:8080\u002Fhealth || exit 1\nCMD [\"python\", \"-m\", \"src.main\"]\n```\n","# Microservice Creation\n\n## Intro\n\nA microservice is a module deployed as its own process, with its own\nnetwork address, its own data store, and its own release lifecycle. The\ndecision to create a new service has a higher cost than creating a new\nmodule inside an existing service — it introduces network latency,\ndistributed failure modes, and operational complexity. Make the decision\ndeliberately; use `software-modularization` first to confirm the boundary\nis right.\n\n## Overview\n\n### When to create a new service (and when not to)\n\n**Create a new service when:**\n- The component has a meaningfully different release cadence than the rest\n  of the system\n- The component needs to scale independently (different resource profile)\n- The component has a different trust boundary (security isolation required)\n- The team owning the component is genuinely independent and has no shared\n  release coordination with other teams\n- The component must be implemented in a different language or runtime\n\n**Do NOT create a new service just because:**\n- The module is large (decompose it first, within the monolith)\n- It would be \"cleaner\" to have it separate (cleanliness has network cost)\n- You want to try a new technology (try it in a module first)\n- The current architecture is a monolith and microservices are fashionable\n\n**The rule of thumb:** if you cannot articulate the independent deployment,\nscaling, or isolation benefit in one sentence, the boundary is not ready.\n\n### Service boundary identification\n\nBefore writing any code:\n\n1. **Name the domain** — what business concept does this service own?\n   \"User authentication\" and \"Billing\" are good domain names. \"Data processing\"\n   and \"Backend\" are not — they are too broad.\n2. **Define ownership** — what data does this service own? Data owned by a\n   service must not be read directly by other services (only via the API).\n   If two services share a database table, they are the same service.\n3. **Define the API contract** — what does this service expose? Write the\n   API contract (OpenAPI \u002F protobuf \u002F AsyncAPI) before writing any\n   implementation. The contract is the service.\n4. **Identify consumers** — which other services or clients will call this?\n   If the answer is \"everything,\" the service may be too fundamental to\n   extract safely.\n\n### Inter-service communication patterns\n\nChoose the pattern that matches the interaction semantics:\n\n| Pattern | Use when | Tradeoffs |\n|---|---|---|\n| **REST (HTTP\u002FJSON)** | Request-response; human-readable; browser clients | Synchronous coupling; retries needed for reliability |\n| **gRPC (protobuf)** | High-throughput; typed contracts; service-to-service | Binary protocol; harder to debug; needs proto tooling |\n| **Async events (queue\u002Fstream)** | Fire-and-forget; pub-sub; eventual consistency OK | Decoupled; harder to trace; requires idempotency |\n| **GraphQL** | Flexible queries; multiple consumers with different field needs | Complex server; N+1 risk; overkill for service-to-service |\n\n**Decision rule:**\n- If the caller needs an immediate response → REST or gRPC\n- If the caller does not need to wait → async events\n- If the contract is typed and high-volume → gRPC over REST\n- If external\u002Fbrowser clients are involved → REST\n\n### Scaffolding a new service\n\nMinimum scaffold for a containerised microservice:\n\n```\nservices\u002F\u003Cservice-name>\u002F\n  src\u002F              ← application code\n  tests\u002F            ← unit and integration tests\n  Dockerfile        ← production image\n  pyproject.toml    ← (or package.json, Cargo.toml, go.mod)\n  README.md         ← service purpose, API summary, local dev instructions\n  openapi.yaml      ← (or .proto file if gRPC)\n```\n\nAdding to the project:\n\n```\ndocker-compose.yml  ← add service entry with health check\ncontext\u002Fservices\u002F   ← add SERVICE-\u003Cname>.md entity for processkit tracking\n```\n\n### Containerisation essentials\n\nEvery service container must have:\n\n- **Explicit base image tag** — never `FROM python:latest`; pin to\n  `python:3.12-slim` or a digest\n- **Non-root user** — `RUN adduser --system appuser && USER appuser`\n- **Health check** — `HEALTHCHECK CMD curl -f http:\u002F\u002Flocalhost:8080\u002Fhealth`\n- **Read-only filesystem** where possible — `docker run --read-only`\n- **Resource limits** — set in docker-compose or Kubernetes manifests\n\n### Orchestration basics\n\n**docker-compose (local development + small deployments):**\n\n```yaml\nservices:\n  auth:\n    build: .\u002Fservices\u002Fauth\n    ports: [\"8081:8080\"]\n    environment:\n      DATABASE_URL: postgres:\u002F\u002F...\n    depends_on:\n      db:\n        condition: service_healthy\n    healthcheck:\n      test: [\"CMD\", \"curl\", \"-f\", \"http:\u002F\u002Flocalhost:8080\u002Fhealth\"]\n      interval: 10s\n      retries: 3\n```\n\n**Kubernetes (production):**\n- One `Deployment` per service (with `replicas`, `resources`, `livenessProbe`)\n- One `Service` (ClusterIP for internal; LoadBalancer\u002FIngress for external)\n- One `ConfigMap` for non-secret config; `Secret` for credentials\n- `HorizontalPodAutoscaler` if independent scaling is the reason for extraction\n\nSee `container-orchestration` skill for full Kubernetes patterns.\n\n## Gotchas\n\n- **Extracting a service before the module boundary is clean.** A microservice\n  built on top of a tangled module boundary imports the coupling into the\n  network layer, where it is far harder to fix. Always run the module\n  boundary checklist from `software-modularization` first. If the module\n  is not clean inside the monolith, the service will not be clean either.\n- **Sharing a database between services.** If two services read and write the\n  same database table, they are a distributed monolith — all the operational\n  complexity of microservices with none of the independence. Each service must\n  own its data exclusively; other services access it only via the API.\n- **Choosing synchronous communication for operations that don't need it.**\n  Every synchronous call is a dependency: if the downstream service is slow\n  or down, the upstream service is slow or down too. For operations where the\n  caller does not need an immediate result (sending an email, updating search\n  index, generating a report), use async events.\n- **No health check endpoint.** A service without a health check cannot be\n  safely orchestrated — the orchestrator cannot distinguish a starting service\n  from a crashed one. Every service must expose a `\u002Fhealth` or `\u002Fhealthz`\n  endpoint that returns 200 when ready to serve traffic.\n- **Forgetting idempotency for async consumers.** Message queues deliver\n  at-least-once. A consumer that processes a payment, sends an email, or\n  writes a database record must handle duplicate delivery — the second\n  delivery must produce the same result as the first. Design for it from the\n  start; retrofitting idempotency is painful.\n- **No distributed tracing from day one.** Once there are two services, a\n  request spans multiple processes. Without a correlation ID propagated\n  through every call, debugging a failure means reading logs from multiple\n  services with no way to connect them. Add `X-Trace-ID` (or OpenTelemetry)\n  before the first cross-service call.\n- **Not writing the API contract before the implementation.** A service whose\n  API is defined by its implementation (rather than a contract the\n  implementation satisfies) will drift as the implementation changes. Write\n  the OpenAPI spec or proto file first; implement against it. Contract-first\n  design forces clarity about what the service actually promises to do.\n\n## Full reference\n\n### Service readiness checklist\n\nBefore extracting a service from the monolith:\n\n- [ ] Domain name defined (one business concept)\n- [ ] Data ownership defined (no shared tables)\n- [ ] API contract written (OpenAPI \u002F proto) before implementation\n- [ ] Consumers identified and have agreed to the contract\n- [ ] Independent deployment case articulated (not just \"it would be cleaner\")\n- [ ] Health check endpoint planned\n- [ ] Tracing \u002F correlation ID propagation planned\n- [ ] Local dev story in docker-compose\n\n### Communication pattern decision tree\n\n```\nCaller needs immediate response?\n  Yes → gRPC (typed, high volume) or REST (human-readable, browser clients)\n  No  → Async events (queue \u002F stream)\n\nMultiple consumers with different field needs?\n  Yes → consider GraphQL (but only for external APIs)\n  No  → REST or gRPC\n\nPerformance-critical, service-to-service only?\n  Yes → gRPC\n  No  → REST\n```\n\n### Minimum viable Dockerfile\n\n```dockerfile\nFROM python:3.12-slim\n\nWORKDIR \u002Fapp\nRUN adduser --system --no-create-home appuser\n\nCOPY pyproject.toml .\u002F\nRUN pip install --no-cache-dir .\n\nCOPY src\u002F .\u002Fsrc\u002F\n\nUSER appuser\nEXPOSE 8080\nHEALTHCHECK CMD curl -f http:\u002F\u002Flocalhost:8080\u002Fhealth || exit 1\nCMD [\"python\", \"-m\", \"src.main\"]\n```\n",{"name":5,"metadata":49,"description":63},{"processkit":50},{"id":51,"uses":52,"created":59,"version":60,"category":61,"apiVersion":62},"SKILL-microservice-creation",[53,56],{"skill":54,"purpose":55},"software-modularization","Apply module boundary heuristics to identify where the service boundary belongs before scaffolding.",{"skill":57,"purpose":58},"container-orchestration","Configure docker-compose or Kubernetes manifests for the new service.",1775606400000,"1.0.0","engineering","processkit.projectious.work\u002Fv1","Designs and scaffolds new microservices — covering service boundary\nidentification, inter-service communication patterns, containerisation,\nand orchestration. Use when asked to create a new service, extract a\nmicroservice from a monolith, design a service boundary, choose a\ncommunication pattern (REST vs gRPC vs events), or set up container\norchestration for a multi-service system.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fmicroservice-creation","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add projectious-work\u002Fprocesskit --skill microservice-creation",{"tool":77,"command":78},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill microservice-creation",{"tool":80,"command":81},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill microservice-creation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fmicroservice-creation\u002FSKILL.md",true,[],[86,109,128,148,165,183],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":95,"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",[92],{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[96,97,42,98,99,100,36,101,102,103,88,104,105,29,106,107,108],"management","skill management","update","package","alpha","list","manage","ontology","get","as","v1","skill package","transition",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"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",[115],{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},[96,117,118,119,120,121,100,36,122,123,102,124,34,125,104,126,127],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","deterministic","contract","mode",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"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",[],[96,135,136,42,98,137,100,36,138,139,140,141,104,26,142,143,144,145,146,147],"proposition","proposition management","index","log","world","record","query","event","interface","updates","facts","claims","WSJF",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"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",[],[96,103,155,42,100,156,157,122,158,138,102,159,160,104,161,162,142,163,106,164],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"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",[],[172,173,174,175,100,176,177,178,36,179,180,181,182],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"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",[],[96,190,191,42,98,137,100,156,36,101,138,192,102,140,104,162,142,143,193,108],"capability","capability management","queries","changes"]