[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WXERW75RPD5MVRPB0G1212":3,"skill-same:01M6WXERW75RPD5MVRPB0G1212":73},{"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":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6WXERW75RPD5MVRPB0G1212","distributed-tracing",null,"Distributed tracing with OpenTelemetry — spans, context propagation, sampling. Use when instrumenting a distributed system, debugging requests that span services, setting up OpenTelemetry, choosing a sampling strategy, or understanding latency across service boundaries.","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.11.1\u002Fcontext\u002Fskills\u002Fdevops\u002Fdistributed-tracing\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"distributed tracing","tracing","distributed","use","when","v1","requests","with","propagation","latency","across","up","sampling","strategy","work","system","OpenTelemetry","services","distributed system","debugging","2026-11-10 10:12:30",false,"---\nname: distributed-tracing\ndescription: |\n  Distributed tracing with OpenTelemetry — spans, context propagation, sampling. Use when instrumenting a distributed system, debugging requests that span services, setting up OpenTelemetry, choosing a sampling strategy, or understanding latency across service boundaries.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-distributed-tracing\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: devops\n---\n\n# Distributed Tracing\n\n## Intro\n\nDistributed tracing follows a single request through every service it\ntouches, exposing latency and error contributions per hop.\nOpenTelemetry is the vendor-neutral standard. Start with\nauto-instrumentation, propagate W3C Trace Context, and sample to\ncontrol cost.\n\n## Overview\n\n### Core concepts\n\nA **trace** is the entire journey of a request, identified by a 128-bit\n`trace_id`. A **span** is one unit of work inside a trace with a name,\nstart time, duration, status, and attributes; spans form a tree where\nevery non-root span has a parent. **Context** carries `trace_id`,\n`span_id`, and `trace_flags` across process boundaries via HTTP\nheaders, message metadata, or gRPC metadata. **Baggage** is small\nkey-value data propagated alongside context for cross-cutting concerns\nlike tenant ID — keep it tiny because every outgoing request carries it.\n\n### OpenTelemetry architecture\n\nOpenTelemetry (OTel) is the standard. The **API** is the\nvendor-neutral interface your code instruments against. The **SDK** is\nthe in-process library that creates and exports spans. **Exporters**\nship spans to backends (Jaeger, Zipkin, Tempo, Datadog). The\n**Collector** is an optional proxy that decouples apps from backends\nand is recommended for production. **Auto-instrumentation** libraries\ncreate spans for common HTTP, gRPC, database, and messaging frameworks\nwith zero code changes.\n\n### Instrumentation strategy\n\n1. Start with auto-instrumentation — it covers infrastructure for free\n2. Add manual spans for business operations (process order, validate\n   payment, generate report)\n3. Use `\u003Ccomponent>.\u003Coperation>` span names: `OrderService.createOrder`\n4. Add attributes for debugging context — HTTP method\u002Furl\u002Fstatus, DB\n   system\u002Fstatement\u002Foperation, and business fields like `order.id`\n5. Record errors by setting span status to ERROR and attaching the\n   exception as a span event\n6. Keep spans focused on one logical operation; break compound work\n   into child spans\n\n### Context propagation\n\nContext propagation is what stitches spans across service boundaries.\nUse **W3C Trace Context** (the OTel default) with `traceparent` and\n`tracestate` headers — example:\n`traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01`.\nB3 propagation (Zipkin's `X-B3-*` headers) is still supported. For\nmessage queues, propagate context in message headers or metadata, not\nin the body. For async work, pass context **explicitly** when spawning\nbackground tasks — it does not flow automatically across thread or\ngoroutine boundaries in most languages.\n\n### Sampling\n\nIn high-traffic systems, tracing every request is expensive. Pick a\nstrategy:\n\n- **Head-based probabilistic** — sample X% at trace root. Simple, can\n  miss rare errors. Good starting point at 10-20%.\n- **Head-based rate-limiting** — sample N traces per second. Prevents\n  overload but biases toward high-traffic endpoints.\n- **Tail-based** (requires the Collector) — decide after the trace\n  completes. Always keep traces with errors or above a latency\n  threshold; sample a small percentage of successes.\n- **Always-on (100%)** — only for low-traffic or critical paths.\n\nRecommended path: head-based probabilistic in apps, tail-based\nerror\u002Flatency policies in the Collector as traffic grows.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Missing context propagation at async boundaries.** Trace context does not flow automatically through message queues, goroutines, thread pools, or task schedulers. If a service publishes a message without embedding the `traceparent` header, the consumer starts a new disconnected trace — the cross-service journey is invisible. Always pass context explicitly when crossing async boundaries, and inject it into message headers or job metadata.\n- **Over-instrumentation — a span per function call.** Adding a span to every helper function generates enormous trace data, makes waterfalls unreadable, and increases cost with no debugging value. Spans should represent meaningful operations: an HTTP call, a database query, a cache lookup, a business action. Instrument at operation boundaries, not code boundaries.\n- **Sensitive data in span attributes.** Span attributes are stored in the tracing backend and may be visible to anyone with access to traces. Embedding PII (email addresses, user IDs mapped to identities), credentials, or full SQL query parameters in attributes creates a data exposure risk. Log only safe structural identifiers — numeric IDs, status codes, operation names.\n- **100% sampling in production without a plan.** Emitting a span for every request in a service handling thousands of RPS will rapidly overwhelm the tracing backend and budget. Set a sampling rate before going to production — head-based probabilistic at 10-20% is a reasonable starting point; add tail-based error\u002Flatency retention in the Collector as traffic grows.\n- **Treating trace_id and request_id as interchangeable.** A `trace_id` is created by the tracing SDK and follows the OpenTelemetry propagation standard. A `request_id` is typically generated at the API boundary for customer-facing correlation. They serve different purposes: `trace_id` links to the tracing backend; `request_id` appears in API responses and error messages. Propagate both and include `trace_id` in log lines so you can pivot from logs to traces.\n- **Ignoring the gaps between spans.** A gap between a parent span's start and its first child's start often represents scheduler delay, queue wait time, or serialization overhead — not actual work. Reading only span durations and missing gaps will misattribute latency. Look at the full waterfall including gaps when diagnosing slowness.\n- **No Collector in production.** Sending spans directly from applications to a tracing backend couples apps to the backend's endpoint, authentication, and retry behavior. A Collector decouples instrumentation from backend, enables tail-based sampling, allows backend migration without redeployment, and buffers spans during backend outages.\n\n## Full reference\n\n### Trace analysis for debugging\n\n1. Start from the symptom — find traces matching the error or latency\n2. Identify the **critical path**: the longest chain of sequential\n   spans determines total latency\n3. Look for gaps between a parent span and its children — they\n   indicate queueing or scheduling delay, not work\n4. Check span attributes for error messages, SQL queries, cache\n   hit\u002Fmiss markers\n5. Compare a fast trace with a slow one to spot divergence\n6. Read the waterfall to see parallel vs sequential execution and\n   spot serial calls that could be parallelized\n\n### Common pitfalls\n\n- **Missing context propagation** — disconnected traces almost always\n  mean a service is not forwarding `traceparent`\n- **Over-instrumentation** — a span per function call generates noise\n  and overhead; spans should be meaningful operations\n- **Sensitive data in attributes** — never put PII, credentials, or\n  full SQL parameters in spans\n- **No sampling in production** — 100% sampling at scale will\n  overwhelm your tracing backend and budget\n- **Ignoring async boundaries** — traces break when context is not\n  passed to background jobs, message consumers, or thread pools\n- **Confusing trace_id with request_id** — propagate both; logs\n  should carry trace_id so you can pivot from logs into traces\n\n### Cost-control tactics\n\nWhen tracing volume gets expensive, look at the source mix first.\nHealth checks are usually 30-50% of all spans and contribute zero\ndebugging value — exclude them via the sampler. Audit middleware that\nemits multiple spans per request and collapse to one. Deploy a\nCollector with tail-based sampling that keeps 100% of errors, 100%\nabove a latency threshold, and 5% of successful requests. This pattern\ntypically cuts span volume 70-80% while preserving every interesting\ntrace.\n","# Distributed Tracing\n\n## Intro\n\nDistributed tracing follows a single request through every service it\ntouches, exposing latency and error contributions per hop.\nOpenTelemetry is the vendor-neutral standard. Start with\nauto-instrumentation, propagate W3C Trace Context, and sample to\ncontrol cost.\n\n## Overview\n\n### Core concepts\n\nA **trace** is the entire journey of a request, identified by a 128-bit\n`trace_id`. A **span** is one unit of work inside a trace with a name,\nstart time, duration, status, and attributes; spans form a tree where\nevery non-root span has a parent. **Context** carries `trace_id`,\n`span_id`, and `trace_flags` across process boundaries via HTTP\nheaders, message metadata, or gRPC metadata. **Baggage** is small\nkey-value data propagated alongside context for cross-cutting concerns\nlike tenant ID — keep it tiny because every outgoing request carries it.\n\n### OpenTelemetry architecture\n\nOpenTelemetry (OTel) is the standard. The **API** is the\nvendor-neutral interface your code instruments against. The **SDK** is\nthe in-process library that creates and exports spans. **Exporters**\nship spans to backends (Jaeger, Zipkin, Tempo, Datadog). The\n**Collector** is an optional proxy that decouples apps from backends\nand is recommended for production. **Auto-instrumentation** libraries\ncreate spans for common HTTP, gRPC, database, and messaging frameworks\nwith zero code changes.\n\n### Instrumentation strategy\n\n1. Start with auto-instrumentation — it covers infrastructure for free\n2. Add manual spans for business operations (process order, validate\n   payment, generate report)\n3. Use `\u003Ccomponent>.\u003Coperation>` span names: `OrderService.createOrder`\n4. Add attributes for debugging context — HTTP method\u002Furl\u002Fstatus, DB\n   system\u002Fstatement\u002Foperation, and business fields like `order.id`\n5. Record errors by setting span status to ERROR and attaching the\n   exception as a span event\n6. Keep spans focused on one logical operation; break compound work\n   into child spans\n\n### Context propagation\n\nContext propagation is what stitches spans across service boundaries.\nUse **W3C Trace Context** (the OTel default) with `traceparent` and\n`tracestate` headers — example:\n`traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01`.\nB3 propagation (Zipkin's `X-B3-*` headers) is still supported. For\nmessage queues, propagate context in message headers or metadata, not\nin the body. For async work, pass context **explicitly** when spawning\nbackground tasks — it does not flow automatically across thread or\ngoroutine boundaries in most languages.\n\n### Sampling\n\nIn high-traffic systems, tracing every request is expensive. Pick a\nstrategy:\n\n- **Head-based probabilistic** — sample X% at trace root. Simple, can\n  miss rare errors. Good starting point at 10-20%.\n- **Head-based rate-limiting** — sample N traces per second. Prevents\n  overload but biases toward high-traffic endpoints.\n- **Tail-based** (requires the Collector) — decide after the trace\n  completes. Always keep traces with errors or above a latency\n  threshold; sample a small percentage of successes.\n- **Always-on (100%)** — only for low-traffic or critical paths.\n\nRecommended path: head-based probabilistic in apps, tail-based\nerror\u002Flatency policies in the Collector as traffic grows.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Missing context propagation at async boundaries.** Trace context does not flow automatically through message queues, goroutines, thread pools, or task schedulers. If a service publishes a message without embedding the `traceparent` header, the consumer starts a new disconnected trace — the cross-service journey is invisible. Always pass context explicitly when crossing async boundaries, and inject it into message headers or job metadata.\n- **Over-instrumentation — a span per function call.** Adding a span to every helper function generates enormous trace data, makes waterfalls unreadable, and increases cost with no debugging value. Spans should represent meaningful operations: an HTTP call, a database query, a cache lookup, a business action. Instrument at operation boundaries, not code boundaries.\n- **Sensitive data in span attributes.** Span attributes are stored in the tracing backend and may be visible to anyone with access to traces. Embedding PII (email addresses, user IDs mapped to identities), credentials, or full SQL query parameters in attributes creates a data exposure risk. Log only safe structural identifiers — numeric IDs, status codes, operation names.\n- **100% sampling in production without a plan.** Emitting a span for every request in a service handling thousands of RPS will rapidly overwhelm the tracing backend and budget. Set a sampling rate before going to production — head-based probabilistic at 10-20% is a reasonable starting point; add tail-based error\u002Flatency retention in the Collector as traffic grows.\n- **Treating trace_id and request_id as interchangeable.** A `trace_id` is created by the tracing SDK and follows the OpenTelemetry propagation standard. A `request_id` is typically generated at the API boundary for customer-facing correlation. They serve different purposes: `trace_id` links to the tracing backend; `request_id` appears in API responses and error messages. Propagate both and include `trace_id` in log lines so you can pivot from logs to traces.\n- **Ignoring the gaps between spans.** A gap between a parent span's start and its first child's start often represents scheduler delay, queue wait time, or serialization overhead — not actual work. Reading only span durations and missing gaps will misattribute latency. Look at the full waterfall including gaps when diagnosing slowness.\n- **No Collector in production.** Sending spans directly from applications to a tracing backend couples apps to the backend's endpoint, authentication, and retry behavior. A Collector decouples instrumentation from backend, enables tail-based sampling, allows backend migration without redeployment, and buffers spans during backend outages.\n\n## Full reference\n\n### Trace analysis for debugging\n\n1. Start from the symptom — find traces matching the error or latency\n2. Identify the **critical path**: the longest chain of sequential\n   spans determines total latency\n3. Look for gaps between a parent span and its children — they\n   indicate queueing or scheduling delay, not work\n4. Check span attributes for error messages, SQL queries, cache\n   hit\u002Fmiss markers\n5. Compare a fast trace with a slow one to spot divergence\n6. Read the waterfall to see parallel vs sequential execution and\n   spot serial calls that could be parallelized\n\n### Common pitfalls\n\n- **Missing context propagation** — disconnected traces almost always\n  mean a service is not forwarding `traceparent`\n- **Over-instrumentation** — a span per function call generates noise\n  and overhead; spans should be meaningful operations\n- **Sensitive data in attributes** — never put PII, credentials, or\n  full SQL parameters in spans\n- **No sampling in production** — 100% sampling at scale will\n  overwhelm your tracing backend and budget\n- **Ignoring async boundaries** — traces break when context is not\n  passed to background jobs, message consumers, or thread pools\n- **Confusing trace_id with request_id** — propagate both; logs\n  should carry trace_id so you can pivot from logs into traces\n\n### Cost-control tactics\n\nWhen tracing volume gets expensive, look at the source mix first.\nHealth checks are usually 30-50% of all spans and contribute zero\ndebugging value — exclude them via the sampler. Audit middleware that\nemits multiple spans per request and collapse to one. Deploy a\nCollector with tail-based sampling that keeps 100% of errors, 100%\nabove a latency threshold, and 5% of successful requests. This pattern\ntypically cuts span volume 70-80% while preserving every interesting\ntrace.\n",{"name":5,"metadata":44,"description":51},{"processkit":45},{"id":46,"created":47,"version":48,"category":49,"apiVersion":50},"SKILL-distributed-tracing",1775433600000,"1.1.0","devops","processkit.projectious.work\u002Fv1","Distributed tracing with OpenTelemetry — spans, context propagation, sampling. Use when instrumenting a distributed system, debugging requests that span services, setting up OpenTelemetry, choosing a sampling strategy, or understanding latency across service boundaries.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fdevops\u002Fdistributed-tracing","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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add projectious-work\u002Fprocesskit --skill distributed-tracing",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill distributed-tracing",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill distributed-tracing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fdevops\u002Fdistributed-tracing\u002FSKILL.md",true,[],[74,100,120,141,158,176],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":85,"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",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[86,87,88,89,90,91,33,92,93,94,76,95,96,97,24,98,99],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"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",[106],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},[86,108,109,110,111,112,91,33,113,114,93,115,116,117,95,118,119],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"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",[],[86,127,128,88,89,129,91,33,130,131,132,133,95,134,135,136,137,138,139,140],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"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",[],[86,94,148,88,91,149,150,113,151,130,93,152,153,95,154,155,135,156,24,157],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"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",[],[165,166,167,168,91,169,170,171,33,172,173,174,175],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"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",[],[86,183,184,88,89,129,91,149,33,92,130,185,93,132,95,155,135,136,186,99],"capability","capability management","queries","changes"]