[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WX43R3EZPV2G1RR0M9RFJR":3,"skill-same:01M6WX43R3EZPV2G1RR0M9RFJR":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},"01M6WX43R3EZPV2G1RR0M9RFJR","typescript-patterns",null,"TypeScript patterns — strict mode, discriminated unions, runtime validation, Result types. Use when writing or reviewing TypeScript, setting up a project's tsconfig, or designing type-safe data flows.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ftypescript-patterns\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"typescript","typescript patterns","patterns","when","writing","result","v1","mode","flows","types","type","runtime","project","up","use","work","data","validation","runtime validation","safe","2026-11-10 10:12:30",false,"---\nname: typescript-patterns\ndescription: |\n  TypeScript patterns — strict mode, discriminated unions, runtime validation, Result types. Use when writing or reviewing TypeScript, setting up a project's tsconfig, or designing type-safe data flows.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-typescript-patterns\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# TypeScript Patterns\n\n## Intro\n\nTypeScript earns its keep in strict mode with no `any`.\nDiscriminated unions model state, `zod` validates external data at\nthe boundary, and Result types keep library code from throwing on\nexpected failures.\n\n## Overview\n\n### Project setup\n\nEnable strict mode in `tsconfig.json`:\n\n```json\n{\n  \"compilerOptions\": {\n    \"strict\": true,\n    \"noUncheckedIndexedAccess\": true\n  }\n}\n```\n\n`strict` turns on a family of checks including `noImplicitAny`,\n`strictNullChecks`, and `strictFunctionTypes`.\n`noUncheckedIndexedAccess` makes array and object index access\nreturn `T | undefined`, which catches a whole class of bugs.\nCommit your lockfile whether you use `pnpm`, `npm`, or `yarn`.\n\n### Type safety\n\n- Avoid `any`. Use `unknown` and narrow with type guards or `zod`.\n- Give public functions explicit return types so inference\n  changes can't silently reshape the API.\n- Model state with discriminated unions:\n\n```ts\ntype Result\u003CT> =\n  | { ok: true; value: T }\n  | { ok: false; error: string }\n```\n\n- Prefer `interface` for object shapes (they can be extended and\n  merged) and `type` for unions and intersections.\n\n### Common patterns\n\n- `as const` for literal-type locking and exhaustive switches.\n- `satisfies` for checking a value against a type without\n  widening it — you keep the narrow literal types for inference\n  downstream.\n- `Map\u003CK, V>` over `Record\u003Cstring, V>` when keys are dynamic and\n  iteration matters.\n- `zod` (or similar) for runtime validation of anything crossing\n  a process boundary: API responses, user input, environment\n  variables.\n\n### Error handling\n\n- Define custom error classes extending `Error` and set the\n  `name` property so logs identify them.\n- In library code, prefer Result types over throwing for\n  *expected* failure modes. Throw for programmer errors and\n  unrecoverable state.\n- Validate external inputs at the boundary — once a value is\n  inside your type system, the types should be trustworthy.\n\n### Testing\n\nUse `vitest` or `jest` for runtime tests. For type tests, use\n`expectTypeOf` (vitest) or similar to assert that types behave\ncorrectly — catching regressions in generic helpers before they\nreach callers.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Using `any` instead of `unknown` for untyped boundaries.** `any` disables type checking for the variable and everything it touches downstream. `unknown` forces you to narrow before use — it's the type-safe alternative for values whose shape is genuinely unknown.\n- **Disabling strict mode \"temporarily\" in a new project.** A TypeScript project without `strict: true` is a JavaScript project with extra syntax. Enabling strict mode later is painful because the whole codebase has accumulated implicit nulls and anys. Enable it on day one.\n- **Type assertions (`x as Foo`) as a refactoring shortcut.** `as` bypasses the type checker. It is appropriate for narrow cases like DOM element access or JSON parsing, not as a way to silence type errors without fixing them. Fix the real type mismatch.\n- **Skipping runtime validation at process boundaries.** TypeScript's types exist only at compile time. A REST API response, environment variable, or user input that passes type-checking at compile time can still have the wrong shape at runtime. Validate external data with `zod` or equivalent at every boundary.\n- **Using `Record\u003Cstring, V>` when a `Map\u003CK, V>` is semantically correct.** `Record` is for objects with a known finite set of keys. Dynamic keys, iteration in insertion order, presence checks, and non-string keys all call for `Map`. The wrong choice leads to surprising behavior with `hasOwnProperty` and `for...in`.\n- **`Optional` field (`?:`) when the property is actually required.** Marking a property optional (`email?: string`) says \"this property may be absent\". If the property is always present but sometimes has no value, use `email: string | null` instead — the distinction affects how callers narrow the type.\n- **No `never` check in `switch` exhaustiveness.** Without an explicit `const _exhaustive: never = s` in the `default` branch, adding a new variant to a discriminated union compiles without error, producing a silent runtime gap. Always add the exhaustiveness check.\n\n## Full reference\n\n### Discriminated unions with exhaustive checks\n\n```ts\ntype Shape =\n  | { kind: \"circle\"; radius: number }\n  | { kind: \"square\"; side: number }\n  | { kind: \"rect\"; width: number; height: number }\n\nfunction area(s: Shape): number {\n  switch (s.kind) {\n    case \"circle\": return Math.PI * s.radius ** 2\n    case \"square\": return s.side ** 2\n    case \"rect\":   return s.width * s.height\n    default: {\n      const _exhaustive: never = s\n      return _exhaustive\n    }\n  }\n}\n```\n\nThe `never` assignment makes adding a new variant a compile error\nat every consumer. This is the TypeScript equivalent of Java's\nsealed types or Rust's exhaustive `match`.\n\n### Runtime validation with zod\n\n```ts\nimport { z } from \"zod\"\n\nconst UserSchema = z.object({\n  id: z.string().uuid(),\n  email: z.string().email(),\n  createdAt: z.coerce.date(),\n})\ntype User = z.infer\u003Ctypeof UserSchema>\n\nasync function fetchUser(id: string): Promise\u003CUser> {\n  const res = await fetch(`\u002Fusers\u002F${id}`)\n  return UserSchema.parse(await res.json())\n}\n```\n\nValidate at the boundary; trust the types everywhere inside.\nNever pass raw `any` \u002F `unknown` API payloads into business\nlogic.\n\n### `satisfies` vs type annotation\n\n```ts\n\u002F\u002F Widens to Record\u003Cstring, string> — you lose the literal keys\nconst routesWide: Record\u003Cstring, string> = {\n  home: \"\u002F\",\n  about: \"\u002Fabout\",\n}\n\n\u002F\u002F Keeps literal types for keys and values; still type-checked\nconst routes = {\n  home: \"\u002F\",\n  about: \"\u002Fabout\",\n} satisfies Record\u003Cstring, string>\n\ntype RouteName = keyof typeof routes  \u002F\u002F \"home\" | \"about\"\n```\n\n### Anti-patterns\n\n- `any` anywhere it isn't strictly required to interop with\n  untyped code. Use `unknown` and narrow.\n- `Optional` field types via `T | undefined` when the property is\n  actually required — use the `?` form only when the property\n  may be absent.\n- Type assertions (`x as Foo`) used as a refactoring shortcut\n  instead of fixing the real type mismatch.\n- Returning different shapes from the same function based on\n  arguments — use overloads or discriminated unions.\n- Catching `Error` and losing the type — re-throw or convert to\n  a Result.\n- Using `Record\u003Cstring, V>` when you actually need a `Map\u003CK, V>`\n  (iteration order, non-string keys, presence checks).\n- Disabling strict mode \"temporarily\" in a new project.\n\n### Custom error class\n\n```ts\nexport class NotFoundError extends Error {\n  constructor(public readonly resource: string, id: string) {\n    super(`${resource} ${id} not found`)\n    this.name = \"NotFoundError\"\n  }\n}\n```\n\nSet `name` explicitly — the default is `\"Error\"`, which makes\nlog filtering and `instanceof` checks across realms unreliable.\n","# TypeScript Patterns\n\n## Intro\n\nTypeScript earns its keep in strict mode with no `any`.\nDiscriminated unions model state, `zod` validates external data at\nthe boundary, and Result types keep library code from throwing on\nexpected failures.\n\n## Overview\n\n### Project setup\n\nEnable strict mode in `tsconfig.json`:\n\n```json\n{\n  \"compilerOptions\": {\n    \"strict\": true,\n    \"noUncheckedIndexedAccess\": true\n  }\n}\n```\n\n`strict` turns on a family of checks including `noImplicitAny`,\n`strictNullChecks`, and `strictFunctionTypes`.\n`noUncheckedIndexedAccess` makes array and object index access\nreturn `T | undefined`, which catches a whole class of bugs.\nCommit your lockfile whether you use `pnpm`, `npm`, or `yarn`.\n\n### Type safety\n\n- Avoid `any`. Use `unknown` and narrow with type guards or `zod`.\n- Give public functions explicit return types so inference\n  changes can't silently reshape the API.\n- Model state with discriminated unions:\n\n```ts\ntype Result\u003CT> =\n  | { ok: true; value: T }\n  | { ok: false; error: string }\n```\n\n- Prefer `interface` for object shapes (they can be extended and\n  merged) and `type` for unions and intersections.\n\n### Common patterns\n\n- `as const` for literal-type locking and exhaustive switches.\n- `satisfies` for checking a value against a type without\n  widening it — you keep the narrow literal types for inference\n  downstream.\n- `Map\u003CK, V>` over `Record\u003Cstring, V>` when keys are dynamic and\n  iteration matters.\n- `zod` (or similar) for runtime validation of anything crossing\n  a process boundary: API responses, user input, environment\n  variables.\n\n### Error handling\n\n- Define custom error classes extending `Error` and set the\n  `name` property so logs identify them.\n- In library code, prefer Result types over throwing for\n  *expected* failure modes. Throw for programmer errors and\n  unrecoverable state.\n- Validate external inputs at the boundary — once a value is\n  inside your type system, the types should be trustworthy.\n\n### Testing\n\nUse `vitest` or `jest` for runtime tests. For type tests, use\n`expectTypeOf` (vitest) or similar to assert that types behave\ncorrectly — catching regressions in generic helpers before they\nreach callers.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Using `any` instead of `unknown` for untyped boundaries.** `any` disables type checking for the variable and everything it touches downstream. `unknown` forces you to narrow before use — it's the type-safe alternative for values whose shape is genuinely unknown.\n- **Disabling strict mode \"temporarily\" in a new project.** A TypeScript project without `strict: true` is a JavaScript project with extra syntax. Enabling strict mode later is painful because the whole codebase has accumulated implicit nulls and anys. Enable it on day one.\n- **Type assertions (`x as Foo`) as a refactoring shortcut.** `as` bypasses the type checker. It is appropriate for narrow cases like DOM element access or JSON parsing, not as a way to silence type errors without fixing them. Fix the real type mismatch.\n- **Skipping runtime validation at process boundaries.** TypeScript's types exist only at compile time. A REST API response, environment variable, or user input that passes type-checking at compile time can still have the wrong shape at runtime. Validate external data with `zod` or equivalent at every boundary.\n- **Using `Record\u003Cstring, V>` when a `Map\u003CK, V>` is semantically correct.** `Record` is for objects with a known finite set of keys. Dynamic keys, iteration in insertion order, presence checks, and non-string keys all call for `Map`. The wrong choice leads to surprising behavior with `hasOwnProperty` and `for...in`.\n- **`Optional` field (`?:`) when the property is actually required.** Marking a property optional (`email?: string`) says \"this property may be absent\". If the property is always present but sometimes has no value, use `email: string | null` instead — the distinction affects how callers narrow the type.\n- **No `never` check in `switch` exhaustiveness.** Without an explicit `const _exhaustive: never = s` in the `default` branch, adding a new variant to a discriminated union compiles without error, producing a silent runtime gap. Always add the exhaustiveness check.\n\n## Full reference\n\n### Discriminated unions with exhaustive checks\n\n```ts\ntype Shape =\n  | { kind: \"circle\"; radius: number }\n  | { kind: \"square\"; side: number }\n  | { kind: \"rect\"; width: number; height: number }\n\nfunction area(s: Shape): number {\n  switch (s.kind) {\n    case \"circle\": return Math.PI * s.radius ** 2\n    case \"square\": return s.side ** 2\n    case \"rect\":   return s.width * s.height\n    default: {\n      const _exhaustive: never = s\n      return _exhaustive\n    }\n  }\n}\n```\n\nThe `never` assignment makes adding a new variant a compile error\nat every consumer. This is the TypeScript equivalent of Java's\nsealed types or Rust's exhaustive `match`.\n\n### Runtime validation with zod\n\n```ts\nimport { z } from \"zod\"\n\nconst UserSchema = z.object({\n  id: z.string().uuid(),\n  email: z.string().email(),\n  createdAt: z.coerce.date(),\n})\ntype User = z.infer\u003Ctypeof UserSchema>\n\nasync function fetchUser(id: string): Promise\u003CUser> {\n  const res = await fetch(`\u002Fusers\u002F${id}`)\n  return UserSchema.parse(await res.json())\n}\n```\n\nValidate at the boundary; trust the types everywhere inside.\nNever pass raw `any` \u002F `unknown` API payloads into business\nlogic.\n\n### `satisfies` vs type annotation\n\n```ts\n\u002F\u002F Widens to Record\u003Cstring, string> — you lose the literal keys\nconst routesWide: Record\u003Cstring, string> = {\n  home: \"\u002F\",\n  about: \"\u002Fabout\",\n}\n\n\u002F\u002F Keeps literal types for keys and values; still type-checked\nconst routes = {\n  home: \"\u002F\",\n  about: \"\u002Fabout\",\n} satisfies Record\u003Cstring, string>\n\ntype RouteName = keyof typeof routes  \u002F\u002F \"home\" | \"about\"\n```\n\n### Anti-patterns\n\n- `any` anywhere it isn't strictly required to interop with\n  untyped code. Use `unknown` and narrow.\n- `Optional` field types via `T | undefined` when the property is\n  actually required — use the `?` form only when the property\n  may be absent.\n- Type assertions (`x as Foo`) used as a refactoring shortcut\n  instead of fixing the real type mismatch.\n- Returning different shapes from the same function based on\n  arguments — use overloads or discriminated unions.\n- Catching `Error` and losing the type — re-throw or convert to\n  a Result.\n- Using `Record\u003Cstring, V>` when you actually need a `Map\u003CK, V>`\n  (iteration order, non-string keys, presence checks).\n- Disabling strict mode \"temporarily\" in a new project.\n\n### Custom error class\n\n```ts\nexport class NotFoundError extends Error {\n  constructor(public readonly resource: string, id: string) {\n    super(`${resource} ${id} not found`)\n    this.name = \"NotFoundError\"\n  }\n}\n```\n\nSet `name` explicitly — the default is `\"Error\"`, which makes\nlog filtering and `instanceof` checks across realms unreliable.\n",{"name":5,"metadata":44,"description":51},{"processkit":45},{"id":46,"created":47,"version":48,"category":49,"apiVersion":50},"SKILL-typescript-patterns",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","TypeScript patterns — strict mode, discriminated unions, runtime validation, Result types. Use when writing or reviewing TypeScript, setting up a project's tsconfig, or designing type-safe data flows.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ftypescript-patterns","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 typescript-patterns",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill typescript-patterns",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill typescript-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ftypescript-patterns\u002FSKILL.md",true,[],[74,100,118,139,156,174],{"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,34,92,93,94,76,95,96,97,25,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,36,91,34,112,113,93,114,115,116,95,117,26],"schema","schema management","MCP","workflows","generated","rebuild","contracts","wed","deterministic","contract",{"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":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,125,126,88,89,127,91,34,128,129,130,131,95,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":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,146,88,91,147,148,112,149,128,93,150,151,95,152,153,133,154,25,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":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",[],[163,164,165,166,91,167,168,169,34,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":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,181,182,88,89,127,91,147,34,92,128,183,93,130,95,153,133,134,184,99],"capability","capability management","queries","changes"]