[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X1T0TMXKQEPXW8NSSXWCS7":3,"skill-same:01M6X1T0TMXKQEPXW8NSSXWCS7":71},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6X1T0TMXKQEPXW8NSSXWCS7","error-handling",null,"Error handling across languages — Result types, exceptions, retries, circuit breakers, and structured error responses. Use when designing error handling for a module or service, choosing between Result types and exceptions, building error hierarchies, implementing retries or circuit breakers, or reviewing code for missing or poor error handling.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ferror-handling\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,5,36,37],"error handling","error","retries","when","result","for","implementing","v1","circuit","reviewing code","types","engineering","code","missing","module","service","across","use","work","2026-11-10 10:12:30",false,"---\nname: error-handling\ndescription: |\n  Error handling across languages — Result types, exceptions, retries, circuit breakers, and structured error responses. Use when designing error handling for a module or service, choosing between Result types and exceptions, building error hierarchies, implementing retries or circuit breakers, or reviewing code for missing or poor error handling.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-error-handling\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Error Handling\n\n## Intro\n\nErrors are part of the type system, not an afterthought. Make\nfailure paths explicit, separate user-facing messages from internal\ndiagnostics, and reach for retries and circuit breakers only when\nthe failure is genuinely transient.\n\n## Overview\n\n### Result types vs exceptions\n\nUse algebraic types where the language supports them — they make\nerror paths explicit in the signature.\n\n- **Rust:** `Result\u003CT, E>` for recoverable errors, `Option\u003CT>` for\n  missing values. Propagate with `?`. Define domain error enums\n  with `thiserror`.\n- **TypeScript:** discriminated unions or a `Result\u003CT, E>` library.\n  Avoid `throw` for expected failures (validation, not-found).\n  Reserve exceptions for truly unexpected conditions.\n- **Python:** exceptions are idiomatic, but consider returning\n  `None` or a result tuple in tight loops where try\u002Fexcept overhead\n  matters.\n- **Java:** checked exceptions for recoverable conditions the\n  caller must handle, unchecked (`RuntimeException`) for\n  programming errors. Prefer specific types over `Exception`.\n\n### Error hierarchies\n\nDesign errors in layers:\n\n1. **Domain errors** — business rule violations\n   (`InsufficientFunds`, `ItemOutOfStock`).\n2. **Application errors** — workflow failures (`OrderNotFound`,\n   `Unauthorized`).\n3. **Infrastructure errors** — external system failures\n   (`DatabaseUnavailable`, `TimeoutError`).\n\nEach layer exposes only errors meaningful at that level.\nInfrastructure errors are mapped to application errors before\nreaching the domain.\n\n### User-facing vs internal\n\nNever leak stack traces, SQL, or file paths to end users.\n\n- **Internal errors:** full context for debugging — stack trace,\n  request ID, input values.\n- **User-facing errors:** human-readable message, error code,\n  optional field-level details.\n- Map at the boundary (HTTP handler, CLI output). Log the internal\n  error with a correlation ID; return the ID to the user for\n  support.\n\n### Error codes and structured responses\n\nUse namespaced, stable error codes (`PAYMENT.DECLINED`,\n`AUTH.TOKEN_EXPIRED`, `VALIDATION.FIELD_REQUIRED`). Document them\nin a central registry. Never reuse or rename codes once shipped.\n\nFor APIs, return a consistent error shape:\n\n```json\n{\n  \"error\": {\n    \"code\": \"VALIDATION.FIELD_REQUIRED\",\n    \"message\": \"The 'email' field is required.\",\n    \"details\": [\n      { \"field\": \"email\", \"reason\": \"required\" }\n    ],\n    \"request_id\": \"req-abc123\"\n  }\n}\n```\n\n### Retries and circuit breakers\n\nRetry only transient failures (network timeouts, 503s, lock\ncontention). Use exponential backoff with jitter: base delay\n100–500ms, multiply by 2 each attempt, add random jitter (0–100% of\ndelay) to prevent thundering herd. Cap retries (3–5) and total\ntimeout. **Never retry** 4xx client errors (except 429), validation\nfailures, or auth errors.\n\nCircuit breakers prevent cascading failures when a downstream\nservice is unhealthy:\n\n- **Closed** (normal): requests flow through; track failure rate.\n- **Open** (tripped): requests fail immediately; return a fallback.\n- **Half-open** (probing): allow one request after a timeout. On\n  success, close. On failure, reopen.\n\nConfigure failure threshold (e.g. 5 failures in 30s), open duration\n(e.g. 60s), and half-open probe count.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Catching `Exception` (or bare `except:`) and swallowing it.** Silent error swallowing is the most common cause of production mysteries where \"nothing went wrong, but nothing worked either.\" Catch specific error types; log and re-raise everything else.\n- **Leaking stack traces, SQL, or file paths in HTTP responses.** Internal error details in user-facing responses are both a security vulnerability and a poor user experience. Map internal errors to user-facing codes at the boundary; log the full context internally with a correlation ID.\n- **Retrying non-idempotent operations without a deduplication key.** Retrying a payment, an email send, or an inventory decrement without idempotency protection causes double-charges and double-sends. Add an idempotency key at the call site before wiring retry logic.\n- **Retrying 4xx errors as if they were transient.** A 400 (bad request) or 401 (unauthorized) will not change on retry — it reflects a problem with the request, not the server. Retry only transient failures: 429, 500, 502, 503, 504, and network-level errors.\n- **Retrying without exponential backoff and jitter.** Fixed-interval retries on a struggling service create a thundering herd that prevents recovery. Use exponential backoff with random jitter; cap the total number of retries and the total elapsed time.\n- **Sentinel return values instead of explicit errors.** Returning `-1`, `null`, or an empty string to signal failure requires every caller to know and check the convention. Make failure explicit in the type: `Result\u003CT, E>`, `Option\u003CT>`, or a domain error type.\n- **Renaming or reusing error codes after shipping.** Error codes are a public contract. Consumers build conditional logic on them. Renaming `PAYMENT.DECLINED` or reusing a retired code silently breaks consumer error handling.\n\n## Full reference\n\n### Error reporting\n\n- Log with structured fields: `level`, `error_code`, `message`,\n  `stack`, `request_id`, `user_id`.\n- Send unhandled exceptions to an error tracker (Sentry, Datadog,\n  Honeybadger).\n- Alert on error rate spikes, not individual errors.\n- Group errors by root cause, not by message string.\n\n### Domain error enum (Rust)\n\n```rust\nuse thiserror::Error;\n\n#[derive(Error, Debug)]\npub enum PaymentError {\n    #[error(\"insufficient funds: required {required}, available {available}\")]\n    InsufficientFunds { required: u64, available: u64 },\n\n    #[error(\"card declined: {reason}\")]\n    CardDeclined { reason: String },\n\n    #[error(\"payment provider unavailable\")]\n    ProviderUnavailable(#[source] reqwest::Error),\n}\n\npub fn charge(amount: u64, balance: u64) -> Result\u003CReceipt, PaymentError> {\n    if amount > balance {\n        return Err(PaymentError::InsufficientFunds {\n            required: amount,\n            available: balance,\n        });\n    }\n    Ok(Receipt { amount })\n}\n```\n\n### Retry with backoff (Python)\n\n```python\nimport time\nimport random\nimport httpx\n\ndef fetch_with_retry(url: str, max_retries: int = 4) -> httpx.Response:\n    base_delay = 0.3\n    for attempt in range(max_retries + 1):\n        try:\n            resp = httpx.get(url, timeout=5.0)\n            if resp.status_code == 429:\n                retry_after = float(resp.headers.get(\"Retry-After\", base_delay))\n                time.sleep(retry_after + random.uniform(0, 0.5))\n                continue\n            resp.raise_for_status()\n            return resp\n        except httpx.TransportError:\n            if attempt == max_retries:\n                raise\n            delay = base_delay * (2 ** attempt) + random.uniform(0, base_delay)\n            time.sleep(delay)\n    raise httpx.HTTPError(f\"Failed after {max_retries} retries\")\n```\n\n### Structured API error response (TypeScript)\n\n```typescript\nclass AppError extends Error {\n  constructor(\n    public code: string,\n    message: string,\n    public statusCode: number = 500,\n    public details?: { field: string; reason: string }[],\n  ) {\n    super(message);\n  }\n}\n\n\u002F\u002F In route handler\napp.post(\"\u002Forders\", async (req, res) => {\n  try {\n    const order = await createOrder(req.body);\n    res.status(201).json(order);\n  } catch (err) {\n    if (err instanceof AppError) {\n      res.status(err.statusCode).json({\n        error: {\n          code: err.code,\n          message: err.message,\n          details: err.details,\n          request_id: req.id,\n        },\n      });\n    } else {\n      console.error(\"Unhandled error\", { request_id: req.id, err });\n      res.status(500).json({\n        error: {\n          code: \"INTERNAL.UNEXPECTED\",\n          message: \"An unexpected error occurred.\",\n          request_id: req.id,\n        },\n      });\n    }\n  }\n});\n```\n\n### Anti-patterns\n\n- Catching `Exception` (or bare `except:`) and swallowing it\n- Returning sentinel values (`-1`, empty string) instead of an\n  explicit error\n- Leaking SQL, stack traces, or filesystem paths in HTTP responses\n- Retrying non-idempotent operations without a deduplication key\n- Retrying 4xx errors as if they were transient\n- Renaming or reusing error codes after shipping them\n- Alerting on every individual error instead of rate spikes\n","# Error Handling\n\n## Intro\n\nErrors are part of the type system, not an afterthought. Make\nfailure paths explicit, separate user-facing messages from internal\ndiagnostics, and reach for retries and circuit breakers only when\nthe failure is genuinely transient.\n\n## Overview\n\n### Result types vs exceptions\n\nUse algebraic types where the language supports them — they make\nerror paths explicit in the signature.\n\n- **Rust:** `Result\u003CT, E>` for recoverable errors, `Option\u003CT>` for\n  missing values. Propagate with `?`. Define domain error enums\n  with `thiserror`.\n- **TypeScript:** discriminated unions or a `Result\u003CT, E>` library.\n  Avoid `throw` for expected failures (validation, not-found).\n  Reserve exceptions for truly unexpected conditions.\n- **Python:** exceptions are idiomatic, but consider returning\n  `None` or a result tuple in tight loops where try\u002Fexcept overhead\n  matters.\n- **Java:** checked exceptions for recoverable conditions the\n  caller must handle, unchecked (`RuntimeException`) for\n  programming errors. Prefer specific types over `Exception`.\n\n### Error hierarchies\n\nDesign errors in layers:\n\n1. **Domain errors** — business rule violations\n   (`InsufficientFunds`, `ItemOutOfStock`).\n2. **Application errors** — workflow failures (`OrderNotFound`,\n   `Unauthorized`).\n3. **Infrastructure errors** — external system failures\n   (`DatabaseUnavailable`, `TimeoutError`).\n\nEach layer exposes only errors meaningful at that level.\nInfrastructure errors are mapped to application errors before\nreaching the domain.\n\n### User-facing vs internal\n\nNever leak stack traces, SQL, or file paths to end users.\n\n- **Internal errors:** full context for debugging — stack trace,\n  request ID, input values.\n- **User-facing errors:** human-readable message, error code,\n  optional field-level details.\n- Map at the boundary (HTTP handler, CLI output). Log the internal\n  error with a correlation ID; return the ID to the user for\n  support.\n\n### Error codes and structured responses\n\nUse namespaced, stable error codes (`PAYMENT.DECLINED`,\n`AUTH.TOKEN_EXPIRED`, `VALIDATION.FIELD_REQUIRED`). Document them\nin a central registry. Never reuse or rename codes once shipped.\n\nFor APIs, return a consistent error shape:\n\n```json\n{\n  \"error\": {\n    \"code\": \"VALIDATION.FIELD_REQUIRED\",\n    \"message\": \"The 'email' field is required.\",\n    \"details\": [\n      { \"field\": \"email\", \"reason\": \"required\" }\n    ],\n    \"request_id\": \"req-abc123\"\n  }\n}\n```\n\n### Retries and circuit breakers\n\nRetry only transient failures (network timeouts, 503s, lock\ncontention). Use exponential backoff with jitter: base delay\n100–500ms, multiply by 2 each attempt, add random jitter (0–100% of\ndelay) to prevent thundering herd. Cap retries (3–5) and total\ntimeout. **Never retry** 4xx client errors (except 429), validation\nfailures, or auth errors.\n\nCircuit breakers prevent cascading failures when a downstream\nservice is unhealthy:\n\n- **Closed** (normal): requests flow through; track failure rate.\n- **Open** (tripped): requests fail immediately; return a fallback.\n- **Half-open** (probing): allow one request after a timeout. On\n  success, close. On failure, reopen.\n\nConfigure failure threshold (e.g. 5 failures in 30s), open duration\n(e.g. 60s), and half-open probe count.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Catching `Exception` (or bare `except:`) and swallowing it.** Silent error swallowing is the most common cause of production mysteries where \"nothing went wrong, but nothing worked either.\" Catch specific error types; log and re-raise everything else.\n- **Leaking stack traces, SQL, or file paths in HTTP responses.** Internal error details in user-facing responses are both a security vulnerability and a poor user experience. Map internal errors to user-facing codes at the boundary; log the full context internally with a correlation ID.\n- **Retrying non-idempotent operations without a deduplication key.** Retrying a payment, an email send, or an inventory decrement without idempotency protection causes double-charges and double-sends. Add an idempotency key at the call site before wiring retry logic.\n- **Retrying 4xx errors as if they were transient.** A 400 (bad request) or 401 (unauthorized) will not change on retry — it reflects a problem with the request, not the server. Retry only transient failures: 429, 500, 502, 503, 504, and network-level errors.\n- **Retrying without exponential backoff and jitter.** Fixed-interval retries on a struggling service create a thundering herd that prevents recovery. Use exponential backoff with random jitter; cap the total number of retries and the total elapsed time.\n- **Sentinel return values instead of explicit errors.** Returning `-1`, `null`, or an empty string to signal failure requires every caller to know and check the convention. Make failure explicit in the type: `Result\u003CT, E>`, `Option\u003CT>`, or a domain error type.\n- **Renaming or reusing error codes after shipping.** Error codes are a public contract. Consumers build conditional logic on them. Renaming `PAYMENT.DECLINED` or reusing a retired code silently breaks consumer error handling.\n\n## Full reference\n\n### Error reporting\n\n- Log with structured fields: `level`, `error_code`, `message`,\n  `stack`, `request_id`, `user_id`.\n- Send unhandled exceptions to an error tracker (Sentry, Datadog,\n  Honeybadger).\n- Alert on error rate spikes, not individual errors.\n- Group errors by root cause, not by message string.\n\n### Domain error enum (Rust)\n\n```rust\nuse thiserror::Error;\n\n#[derive(Error, Debug)]\npub enum PaymentError {\n    #[error(\"insufficient funds: required {required}, available {available}\")]\n    InsufficientFunds { required: u64, available: u64 },\n\n    #[error(\"card declined: {reason}\")]\n    CardDeclined { reason: String },\n\n    #[error(\"payment provider unavailable\")]\n    ProviderUnavailable(#[source] reqwest::Error),\n}\n\npub fn charge(amount: u64, balance: u64) -> Result\u003CReceipt, PaymentError> {\n    if amount > balance {\n        return Err(PaymentError::InsufficientFunds {\n            required: amount,\n            available: balance,\n        });\n    }\n    Ok(Receipt { amount })\n}\n```\n\n### Retry with backoff (Python)\n\n```python\nimport time\nimport random\nimport httpx\n\ndef fetch_with_retry(url: str, max_retries: int = 4) -> httpx.Response:\n    base_delay = 0.3\n    for attempt in range(max_retries + 1):\n        try:\n            resp = httpx.get(url, timeout=5.0)\n            if resp.status_code == 429:\n                retry_after = float(resp.headers.get(\"Retry-After\", base_delay))\n                time.sleep(retry_after + random.uniform(0, 0.5))\n                continue\n            resp.raise_for_status()\n            return resp\n        except httpx.TransportError:\n            if attempt == max_retries:\n                raise\n            delay = base_delay * (2 ** attempt) + random.uniform(0, base_delay)\n            time.sleep(delay)\n    raise httpx.HTTPError(f\"Failed after {max_retries} retries\")\n```\n\n### Structured API error response (TypeScript)\n\n```typescript\nclass AppError extends Error {\n  constructor(\n    public code: string,\n    message: string,\n    public statusCode: number = 500,\n    public details?: { field: string; reason: string }[],\n  ) {\n    super(message);\n  }\n}\n\n\u002F\u002F In route handler\napp.post(\"\u002Forders\", async (req, res) => {\n  try {\n    const order = await createOrder(req.body);\n    res.status(201).json(order);\n  } catch (err) {\n    if (err instanceof AppError) {\n      res.status(err.statusCode).json({\n        error: {\n          code: err.code,\n          message: err.message,\n          details: err.details,\n          request_id: req.id,\n        },\n      });\n    } else {\n      console.error(\"Unhandled error\", { request_id: req.id, err });\n      res.status(500).json({\n        error: {\n          code: \"INTERNAL.UNEXPECTED\",\n          message: \"An unexpected error occurred.\",\n          request_id: req.id,\n        },\n      });\n    }\n  }\n});\n```\n\n### Anti-patterns\n\n- Catching `Exception` (or bare `except:`) and swallowing it\n- Returning sentinel values (`-1`, empty string) instead of an\n  explicit error\n- Leaking SQL, stack traces, or filesystem paths in HTTP responses\n- Retrying non-idempotent operations without a deduplication key\n- Retrying 4xx errors as if they were transient\n- Renaming or reusing error codes after shipping them\n- Alerting on every individual error instead of rate spikes\n",{"name":5,"metadata":43,"description":49},{"processkit":44},{"id":45,"created":46,"version":47,"category":30,"apiVersion":48},"SKILL-error-handling",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Error handling across languages — Result types, exceptions, retries, circuit breakers, and structured error responses. Use when designing error handling for a module or service, choosing between Result types and exceptions, building error hierarchies, implementing retries or circuit breakers, or reviewing code for missing or poor error handling.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ferror-handling","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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add projectious-work\u002Fprocesskit --skill error-handling",{"tool":63,"command":64},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill error-handling",{"tool":66,"command":67},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill error-handling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ferror-handling\u002FSKILL.md",true,[],[72,98,118,139,156,174],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":38},"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",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,85,86,87,88,89,37,90,91,92,74,93,94,95,26,96,97],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":105,"publishedAt":38},"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",[104],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},[84,106,107,108,109,110,89,37,111,112,91,113,114,115,93,116,117],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":38},"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",[],[84,125,126,86,87,127,89,37,128,129,130,131,93,132,133,134,135,136,137,138],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":38},"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",[],[84,92,146,86,89,147,148,111,149,128,91,150,151,93,152,153,133,154,26,155],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":38},"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",[],[163,164,165,166,89,167,168,169,37,170,171,172,173],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":38},"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",[],[84,181,182,86,87,127,89,147,37,90,128,183,91,130,93,153,133,134,184,97],"capability","capability management","queries","changes"]