[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0PXBNEH2D7BA5M727SJS9":3,"skill-same:01M6X0PXBNEH2D7BA5M727SJS9":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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6X0PXBNEH2D7BA5M727SJS9","logging-strategy",null,"Structured logging strategy — levels, correlation IDs, context propagation, PII avoidance. Use when designing a logging approach, reviewing log statements, setting up log aggregation (ELK, Loki, CloudWatch), adding correlation IDs to a distributed system, or deciding what to log and what to keep out.","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.22.0\u002Fcontext\u002Fskills\u002Fdevops\u002Flogging-strategy\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"logging","logging strategy","strategy","when","distributed","v1","keep","loki","propagation","Setting Up Log Aggregation","log","up","devops","use","work","system","pii","ids","aggregation","distributed system","2026-11-10 10:12:30",false,"---\nname: logging-strategy\ndescription: |\n  Structured logging strategy — levels, correlation IDs, context propagation, PII avoidance. Use when designing a logging approach, reviewing log statements, setting up log aggregation (ELK, Loki, CloudWatch), adding correlation IDs to a distributed system, or deciding what to log and what to keep out.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-logging-strategy\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: devops\n---\n\n# Logging Strategy\n\n## Intro\n\nGood logs are structured, leveled, correlated, and free of secrets.\nPick a JSON logger, generate a `request_id` at every system boundary,\nand propagate it through every downstream call. The cost of bad\nlogging is cost itself — most overspend comes from a few noisy\nendpoints logged at INFO.\n\n## Overview\n\n### Log levels\n\nUse levels intentionally. The semantic ladder:\n\n1. **TRACE** — fine-grained diagnostic detail (loop iterations).\n   Never on in production.\n2. **DEBUG** — useful during development (SQL queries, cache hits,\n   loaded config). Off by default in production.\n3. **INFO** — normal operational events (service started, request\n   handled, job completed). The default production level.\n4. **WARN** — unexpected but recoverable (retry succeeded, deprecated\n   API called, approaching rate limit). Not page-worthy.\n5. **ERROR** — a failure that prevented an operation from completing.\n   Should trigger an alert or ticket.\n6. **FATAL** — process cannot continue (missing required config, port\n   bound, unrecoverable state). Extremely rare.\n\nWhen unsure between two levels, pick the lower one. Over-logging at\nDEBUG is better than missing context at ERROR.\n\n### Structured over unstructured\n\nAlways prefer structured logging (JSON or key-value pairs). Structured\nlogs are machine-parseable, searchable, and survive message format\nchanges. Every log line should include `timestamp` (ISO 8601 UTC),\n`level`, `service`, `message`, and a `request_id` or `trace_id`. See\n`references\u002Fstructured-logging.md` for language-specific libraries.\n\n### Correlation and context propagation\n\nGenerate a unique `request_id` (UUID or ULID) at the system boundary —\nAPI gateway, message consumer, scheduled job. Propagate it through\nevery downstream call via headers (`X-Request-ID`) or message\nmetadata. Include it in every log line so you can correlate. In\ndistributed systems, also propagate `trace_id` and `span_id` (W3C\nTrace Context). Use MDC or contextvars to avoid threading IDs through\nevery function signature.\n\n### What to log\n\nRequest and response summaries (method, path, status, duration);\nstate transitions (order placed, payment processed); decision points\n(why a branch was taken, which cache was hit); error details with\nstack trace and the input that caused the failure; performance data\n(query duration, queue depth); lifecycle events (start, config load,\ngraceful shutdown); retry attempts with attempt number and backoff;\nexternal calls with downstream service, latency, and status.\n\n### What NOT to log\n\n- **PII**: names, emails, phone numbers, addresses, IP addresses\n  (unless legally required and compliant)\n- **Secrets**: passwords, API keys, tokens, session IDs, card numbers\n- **Sensitive business data**: salary, health records, financial\n  details\n- **High-cardinality user input**: full request bodies — log a hash or\n  a truncation instead\n- When in doubt, mask: `email=b***@example.com`, `card=****1234`\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Logging at ERROR level for expected operational conditions.** A database query that returns zero results, a user failing authentication, or a cache miss are not errors — they are normal application states. Logging them as ERROR trains the team to ignore error logs and buries actual errors in noise. Match the level to severity: INFO for normal operations, WARN for unexpected-but-recoverable, ERROR for actual failures.\n- **Log and rethrow — logging the same error at every level of the call stack.** When a low-level function logs an error and then throws an exception, and every caller also logs before rethrowing, the same error appears three or four times in the log stream with different (and sometimes contradictory) context. Choose one place to log — typically the outermost handler that decides whether to return an error response or retry.\n- **PII or secrets appearing in log statements.** User email addresses, full names, passwords, API keys, and session tokens written to logs create a compliance liability and a security exposure — log aggregation systems are often less strictly access-controlled than the application itself. Never log these values; log opaque IDs (numeric user IDs, hashed email) and redact sensitive fields in error messages.\n- **No correlation ID or request ID propagated through the request lifecycle.** A log line that says \"database query failed\" with no request context is useless for debugging — you cannot tell which user, which request, or which code path caused it. Generate a unique request ID at the system boundary and include it in every log line for the duration of that request's handling. In distributed systems, propagate it as a header.\n- **Logging inside tight loops.** A single request that logs once per iteration of a loop processing 10,000 items produces 10,000 log lines — overwhelming the log system and hiding every other log line from concurrent requests. Aggregate counts and log a summary after the loop: \"processed 10,000 items, 42 failed\" rather than one line per item.\n- **Unstructured log messages that vary format across similar events.** `\"User 123 logged in\"` and `\"Login succeeded for user_id=456\"` and `\"auth success: {\\\"id\\\": 789}\"` are the same event with three different formats — impossible to query consistently in a log aggregation system. Define standard event types with consistent field names and use them everywhere the same event occurs.\n- **Missing timestamps or timestamps without timezone.** A log line without a timestamp makes it impossible to correlate with other events or determine the sequence of operations during an incident. A timestamp without a timezone is ambiguous across server locations and daylight saving time transitions. Always log ISO 8601 UTC timestamps.\n\n## Full reference\n\n### Common fields for every entry\n\n| Field        | Description                          | Example                            |\n|--------------|--------------------------------------|------------------------------------|\n| `timestamp`  | ISO 8601 with timezone               | `2026-03-22T14:30:00.123Z`         |\n| `level`      | Log severity                         | `info`, `error`, `debug`           |\n| `service`    | Service or application name          | `order-service`                    |\n| `message`    | Human-readable description           | `Order created successfully`       |\n| `trace_id`   | Distributed trace identifier         | `4bf92f3577b34da6a3ce929d0e0e4736` |\n| `span_id`    | Span within the trace                | `00f067aa0ba902b7`                 |\n| `request_id` | Unique ID for the incoming request   | `req_01HXYZ...`                    |\n| `duration_ms`| Operation duration in milliseconds   | `142`                              |\n| `error`      | Error type or message (if applicable)| `ConnectionTimeout`                |\n\n### Event naming convention\n\nUse dot-delimited event names so logs are easy to filter:\n`http.request.received`, `http.response.sent`, `db.query.executed`,\n`cache.hit`, `cache.miss`, `order.created`, `order.cancelled`,\n`auth.login.success`, `auth.login.failed`,\n`queue.message.published`, `queue.message.consumed`. See\n`references\u002Fstructured-logging.md` for full language patterns\n(structlog, pino, slog, tracing) and ELK\u002FLoki ingestion examples.\n\n### Aggregation and rotation\n\nShip logs to a centralized system (ELK, Grafana Loki, CloudWatch\nLogs). Use JSON for ingestion and avoid multi-line messages where\npossible. Set tiered retention: hot (7-30 days searchable), warm\n(90 days), cold archive (1+ year if regulated). In containers, log to\nstdout\u002Fstderr and let the orchestrator collect — never write to local\nfiles. For VMs, rotate by size (100MB) or daily to prevent disk\nexhaustion.\n\n### Performance considerations\n\nLogging has real cost — I\u002FO, serialization, allocation. Use lazy\nevaluation for expensive log arguments so debug strings are not built\nwhen DEBUG is off. Avoid logging inside tight loops; aggregate counts\nand log a summary after. Sample high-volume logs (e.g. 1 in 100 health\nchecks). Use async appenders so log I\u002FO does not block requests.\n\n### Anti-patterns\n\n- **Log and throw** — logs the error, then logs it again at every\n  caller. Choose one place to log\n- **Everything at INFO** — buries the events that matter\n- **String concatenation in log calls** — wastes CPU when level is\n  off; use parameterized messages\n- **`\"Error occurred\"`** with no context about what, where, or why\n- **Mixing structured and unstructured** within the same service\n- **Logging in a loop** — aggregate and log a summary\n- **Timestamps without timezone** — always UTC, ISO 8601\n- **Swallowing exceptions** — catching then logging only a generic\n  message loses the stack trace\n","# Logging Strategy\n\n## Intro\n\nGood logs are structured, leveled, correlated, and free of secrets.\nPick a JSON logger, generate a `request_id` at every system boundary,\nand propagate it through every downstream call. The cost of bad\nlogging is cost itself — most overspend comes from a few noisy\nendpoints logged at INFO.\n\n## Overview\n\n### Log levels\n\nUse levels intentionally. The semantic ladder:\n\n1. **TRACE** — fine-grained diagnostic detail (loop iterations).\n   Never on in production.\n2. **DEBUG** — useful during development (SQL queries, cache hits,\n   loaded config). Off by default in production.\n3. **INFO** — normal operational events (service started, request\n   handled, job completed). The default production level.\n4. **WARN** — unexpected but recoverable (retry succeeded, deprecated\n   API called, approaching rate limit). Not page-worthy.\n5. **ERROR** — a failure that prevented an operation from completing.\n   Should trigger an alert or ticket.\n6. **FATAL** — process cannot continue (missing required config, port\n   bound, unrecoverable state). Extremely rare.\n\nWhen unsure between two levels, pick the lower one. Over-logging at\nDEBUG is better than missing context at ERROR.\n\n### Structured over unstructured\n\nAlways prefer structured logging (JSON or key-value pairs). Structured\nlogs are machine-parseable, searchable, and survive message format\nchanges. Every log line should include `timestamp` (ISO 8601 UTC),\n`level`, `service`, `message`, and a `request_id` or `trace_id`. See\n`references\u002Fstructured-logging.md` for language-specific libraries.\n\n### Correlation and context propagation\n\nGenerate a unique `request_id` (UUID or ULID) at the system boundary —\nAPI gateway, message consumer, scheduled job. Propagate it through\nevery downstream call via headers (`X-Request-ID`) or message\nmetadata. Include it in every log line so you can correlate. In\ndistributed systems, also propagate `trace_id` and `span_id` (W3C\nTrace Context). Use MDC or contextvars to avoid threading IDs through\nevery function signature.\n\n### What to log\n\nRequest and response summaries (method, path, status, duration);\nstate transitions (order placed, payment processed); decision points\n(why a branch was taken, which cache was hit); error details with\nstack trace and the input that caused the failure; performance data\n(query duration, queue depth); lifecycle events (start, config load,\ngraceful shutdown); retry attempts with attempt number and backoff;\nexternal calls with downstream service, latency, and status.\n\n### What NOT to log\n\n- **PII**: names, emails, phone numbers, addresses, IP addresses\n  (unless legally required and compliant)\n- **Secrets**: passwords, API keys, tokens, session IDs, card numbers\n- **Sensitive business data**: salary, health records, financial\n  details\n- **High-cardinality user input**: full request bodies — log a hash or\n  a truncation instead\n- When in doubt, mask: `email=b***@example.com`, `card=****1234`\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Logging at ERROR level for expected operational conditions.** A database query that returns zero results, a user failing authentication, or a cache miss are not errors — they are normal application states. Logging them as ERROR trains the team to ignore error logs and buries actual errors in noise. Match the level to severity: INFO for normal operations, WARN for unexpected-but-recoverable, ERROR for actual failures.\n- **Log and rethrow — logging the same error at every level of the call stack.** When a low-level function logs an error and then throws an exception, and every caller also logs before rethrowing, the same error appears three or four times in the log stream with different (and sometimes contradictory) context. Choose one place to log — typically the outermost handler that decides whether to return an error response or retry.\n- **PII or secrets appearing in log statements.** User email addresses, full names, passwords, API keys, and session tokens written to logs create a compliance liability and a security exposure — log aggregation systems are often less strictly access-controlled than the application itself. Never log these values; log opaque IDs (numeric user IDs, hashed email) and redact sensitive fields in error messages.\n- **No correlation ID or request ID propagated through the request lifecycle.** A log line that says \"database query failed\" with no request context is useless for debugging — you cannot tell which user, which request, or which code path caused it. Generate a unique request ID at the system boundary and include it in every log line for the duration of that request's handling. In distributed systems, propagate it as a header.\n- **Logging inside tight loops.** A single request that logs once per iteration of a loop processing 10,000 items produces 10,000 log lines — overwhelming the log system and hiding every other log line from concurrent requests. Aggregate counts and log a summary after the loop: \"processed 10,000 items, 42 failed\" rather than one line per item.\n- **Unstructured log messages that vary format across similar events.** `\"User 123 logged in\"` and `\"Login succeeded for user_id=456\"` and `\"auth success: {\\\"id\\\": 789}\"` are the same event with three different formats — impossible to query consistently in a log aggregation system. Define standard event types with consistent field names and use them everywhere the same event occurs.\n- **Missing timestamps or timestamps without timezone.** A log line without a timestamp makes it impossible to correlate with other events or determine the sequence of operations during an incident. A timestamp without a timezone is ambiguous across server locations and daylight saving time transitions. Always log ISO 8601 UTC timestamps.\n\n## Full reference\n\n### Common fields for every entry\n\n| Field        | Description                          | Example                            |\n|--------------|--------------------------------------|------------------------------------|\n| `timestamp`  | ISO 8601 with timezone               | `2026-03-22T14:30:00.123Z`         |\n| `level`      | Log severity                         | `info`, `error`, `debug`           |\n| `service`    | Service or application name          | `order-service`                    |\n| `message`    | Human-readable description           | `Order created successfully`       |\n| `trace_id`   | Distributed trace identifier         | `4bf92f3577b34da6a3ce929d0e0e4736` |\n| `span_id`    | Span within the trace                | `00f067aa0ba902b7`                 |\n| `request_id` | Unique ID for the incoming request   | `req_01HXYZ...`                    |\n| `duration_ms`| Operation duration in milliseconds   | `142`                              |\n| `error`      | Error type or message (if applicable)| `ConnectionTimeout`                |\n\n### Event naming convention\n\nUse dot-delimited event names so logs are easy to filter:\n`http.request.received`, `http.response.sent`, `db.query.executed`,\n`cache.hit`, `cache.miss`, `order.created`, `order.cancelled`,\n`auth.login.success`, `auth.login.failed`,\n`queue.message.published`, `queue.message.consumed`. See\n`references\u002Fstructured-logging.md` for full language patterns\n(structlog, pino, slog, tracing) and ELK\u002FLoki ingestion examples.\n\n### Aggregation and rotation\n\nShip logs to a centralized system (ELK, Grafana Loki, CloudWatch\nLogs). Use JSON for ingestion and avoid multi-line messages where\npossible. Set tiered retention: hot (7-30 days searchable), warm\n(90 days), cold archive (1+ year if regulated). In containers, log to\nstdout\u002Fstderr and let the orchestrator collect — never write to local\nfiles. For VMs, rotate by size (100MB) or daily to prevent disk\nexhaustion.\n\n### Performance considerations\n\nLogging has real cost — I\u002FO, serialization, allocation. Use lazy\nevaluation for expensive log arguments so debug strings are not built\nwhen DEBUG is off. Avoid logging inside tight loops; aggregate counts\nand log a summary after. Sample high-volume logs (e.g. 1 in 100 health\nchecks). Use async appenders so log I\u002FO does not block requests.\n\n### Anti-patterns\n\n- **Log and throw** — logs the error, then logs it again at every\n  caller. Choose one place to log\n- **Everything at INFO** — buries the events that matter\n- **String concatenation in log calls** — wastes CPU when level is\n  off; use parameterized messages\n- **`\"Error occurred\"`** with no context about what, where, or why\n- **Mixing structured and unstructured** within the same service\n- **Logging in a loop** — aggregate and log a summary\n- **Timestamps without timezone** — always UTC, ISO 8601\n- **Swallowing exceptions** — catching then logging only a generic\n  message loses the stack trace\n",{"name":5,"metadata":44,"description":50},{"processkit":45},{"id":46,"created":47,"version":48,"category":31,"apiVersion":49},"SKILL-logging-strategy",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Structured logging strategy — levels, correlation IDs, context propagation, PII avoidance. Use when designing a logging approach, reviewing log statements, setting up log aggregation (ELK, Loki, CloudWatch), adding correlation IDs to a distributed system, or deciding what to log and what to keep out.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fdevops\u002Flogging-strategy","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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add projectious-work\u002Fprocesskit --skill logging-strategy",{"tool":64,"command":65},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill logging-strategy",{"tool":67,"command":68},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill logging-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fdevops\u002Flogging-strategy\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fstructured-logging.md","REFERENCE","参考文档",4591,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.22.0\u002Fcontext\u002Fskills\u002Fdevops\u002Flogging-strategy\u002Freferences\u002Fstructured-logging.md",[79,105,125,145,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":90,"publishedAt":39},"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":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[91,92,93,94,95,96,33,97,98,99,81,100,101,102,24,103,104],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":39},"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",[111],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},[91,113,114,115,116,117,96,33,118,119,98,120,121,122,100,123,124],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":39},"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",[],[91,132,133,93,94,134,96,33,29,135,136,137,100,138,139,140,141,142,143,144],"proposition","proposition management","index","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":39},"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",[],[91,99,152,93,96,153,154,118,155,29,98,156,157,100,158,25,139,159,24,160],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","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":39},"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,96,172,173,174,33,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":39},"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",[],[91,186,187,93,94,134,96,153,33,97,29,188,98,136,100,25,139,140,189,104],"capability","capability management","queries","changes"]