[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0C6CVEPDMS4P4X0XRAQJ2":3,"skill-same:01M6X0C6CVEPDMS4P4X0XRAQJ2":113},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":14,"repositoryHtmlUrl":73,"repositoryHomepageUrl":74,"ownerHtmlUrl":75,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":76,"install":77,"resources":90},"01M6X0C6CVEPDMS4P4X0XRAQJ2","index-management",null,"SQLite-backed index over all entity files in the project. The read-side foundation for every other MCP server. Use whenever an agent needs to look up entities by ID, kind, state, or text — instead of grepping the filesystem.","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.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"management","index management","index","up","mcp server","for","errors","events","get","project","query","files","MCP","list","read","work","text","sqlite","server","search","2026-11-10 10:12:30",false,"---\nname: index-management\ndescription: |\n  SQLite-backed index over all entity files in the project. The read-side foundation for every other MCP server. Use whenever an agent needs to look up entities by ID, kind, state, or text — instead of grepping the filesystem.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-index-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: processkit\n    layer: 0\n    provides:\n      primitives: []\n      mcp_tools: [reindex, query_entities, get_entity, search_entities, query_events, list_errors, \n            stats]\n---\n\n# Index Management\n\n## Intro\n\n`index-management` is the **read-side** foundation. It walks the project's\n`context\u002F` directory, parses every entity file, and writes a SQLite\ndatabase that other tools query. Its peer at Layer 0 is `id-management`\n(the write side, which allocates new IDs). Both are foundational to\nevery entity-creating skill.\n\n> **MCP server.** This skill ships a self-contained MCP server at\n> `mcp\u002Fserver.py` (PEP 723 script — requires `uv` and Python ≥ 3.10 on\n> PATH). Agent harnesses reach its tools by reading a single MCP config\n> file at startup, so the contents of `mcp\u002Fmcp-config.json` must be merged\n> into the harness's MCP config and placed at the harness-specific path\n> before this skill is usable. If processkit was installed by an installer,\n> that wiring is the installer's responsibility; if processkit was\n> installed manually, the project owner must do it by hand.\n\n## Overview\n\n### What it provides\n\n- **`reindex()`** — rebuild the SQLite index from scratch\n- **`query_entities(kind?, state?, limit?)`** — list entities matching filters\n- **`get_entity(id)`** — fetch a single entity by ID\n- **`search_entities(text, limit?)`** — full-text search across IDs, titles, bodies, specs\n- **`query_events(event_type?, subject?, actor?, limit?)`** — query the event log\n- **`list_errors()`** — files that failed to parse during the last reindex\n- **`stats()`** — counts of entities\u002Fevents\u002Ferrors in the index\n\n### When to use\n\nThe MCP server runs continuously inside the dev container. Agents call it\nwhenever they need fast lookup. Other MCP servers (`workitem-management`,\n`decision-record`, etc.) call `reindex` after writing a new entity to\nkeep the index fresh.\n\n### Where the database lives\n\n`\u003Cproject-root>\u002Fcontext\u002F.cache\u002Fprocesskit\u002Findex.sqlite`. Gitignored.\nRebuildable from source files at any time via `reindex()`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Grepping the filesystem instead of calling `query_entities`.** The\n  index is faster, context-cheaper, and reflects parsed semantics\n  (state, kind, links) that grep can't see. Reach for `query_entities`\n  first; fall back to grep only if the query you need isn't supported.\n- **Trusting the index immediately after a hand-edit.** When you edit\n  an entity file directly (bypassing the MCP write tools), the index\n  is stale until the next `reindex()` call. Either go through the\n  write tools, or call `reindex()` yourself before querying.\n- **Forgetting to call `reindex` after writing a new entity.** Every\n  entity-creating MCP server should call `index_management.reindex`\n  (or the lighter `upsert_entity`) after a write. Not doing so means\n  the next query won't see the just-created entity.\n- **Treating index queries as transactional.** The index is eventually\n  consistent. A query immediately after a write may or may not return\n  the new row depending on whether reindex completed. If you need\n  strict consistency, reindex explicitly first.\n- **Trusting `list_errors()` as proof of correctness.** A clean errors\n  table means parsing succeeded, not that the entities are\n  semantically valid. Schema validation is a separate concern from\n  parse success.\n- **Using `search_entities` for exact-ID lookup.** `search_entities`\n  is full-text — it ranks by relevance and may miss exact ID matches\n  if the ID appears in many bodies. Use `get_entity(id)` for exact\n  lookup.\n- **Re-indexing inside a hot loop.** A full reindex walks the whole\n  `context\u002F` tree and is expensive. Batch your writes and reindex\n  once at the end, not after every entity.\n\n## Full reference\n\n### Database schema\n\nThree tables — see `src\u002Flib\u002Fprocesskit\u002Findex.py` for the DDL.\n\n```sql\nentities(id, kind, api_version, path, created, updated, title, state, labels_json, spec_json, body)\nevents(id, timestamp, event_type, actor, subject, subject_kind, summary, details_json, correlation_id, path)\nerrors(path, message)\n```\n\n`spec_json` holds the full `spec` block as JSON for queries we did not\nanticipate. `entities` and `events` overlap for LogEntry rows: a LogEntry\nappears in both, with the `events` table denormalizing the event-specific\nfields for fast filtering.\n\n### Reindex strategy\n\n`reindex()` is **destructive and atomic** — it deletes all rows and\nre-inserts. For typical projects this is fast (sub-second). For very\nlarge projects, an incremental update mode lands later (Phase 4+).\n\n### Errors table\n\nFiles that fail to parse get a row in the `errors` table instead of\ncrashing the reindex. `list_errors()` returns all such rows so the agent\ncan fix them. The errors table is cleared at the start of each reindex.\n\n### Tools that other servers call\n\n`workitem-management`, `decision-record`, `binding-management`, and\n`event-log` all call `index_management.upsert_entity` after writing a\nnew file. This keeps the index in sync without a full reindex on every\nmutation. From an MCP-protocol perspective each server has its own\nprocess — they communicate by sharing the same SQLite database file\n(WAL mode would be enabled in a future release for concurrent writes).\n\n### Configuration\n\nThe index database path is configurable via:\n\n- `processkit.toml` `[index] path = \"...\"` (relative to project root)\n- The `PROCESSKIT_INDEX_DB` environment variable\n- Default: `context\u002F.cache\u002Fprocesskit\u002Findex.sqlite` (gitignored cache)\n\n### Limitations at v0.3.0\n\n- **WAL mode enabled (v0.4.0+).** Multiple readers and a single writer\n  are safe; concurrent writes still serialize via WAL. Typical\n  AI-assisted sessions are single-writer anyway.\n- **No FTS.** Search uses `LIKE %text%`. SQLite FTS5 integration lands\n  in a later release.\n- **No incremental indexing.** Every reindex is a full sweep.\n","# Index Management\n\n## Intro\n\n`index-management` is the **read-side** foundation. It walks the project's\n`context\u002F` directory, parses every entity file, and writes a SQLite\ndatabase that other tools query. Its peer at Layer 0 is `id-management`\n(the write side, which allocates new IDs). Both are foundational to\nevery entity-creating skill.\n\n> **MCP server.** This skill ships a self-contained MCP server at\n> `mcp\u002Fserver.py` (PEP 723 script — requires `uv` and Python ≥ 3.10 on\n> PATH). Agent harnesses reach its tools by reading a single MCP config\n> file at startup, so the contents of `mcp\u002Fmcp-config.json` must be merged\n> into the harness's MCP config and placed at the harness-specific path\n> before this skill is usable. If processkit was installed by an installer,\n> that wiring is the installer's responsibility; if processkit was\n> installed manually, the project owner must do it by hand.\n\n## Overview\n\n### What it provides\n\n- **`reindex()`** — rebuild the SQLite index from scratch\n- **`query_entities(kind?, state?, limit?)`** — list entities matching filters\n- **`get_entity(id)`** — fetch a single entity by ID\n- **`search_entities(text, limit?)`** — full-text search across IDs, titles, bodies, specs\n- **`query_events(event_type?, subject?, actor?, limit?)`** — query the event log\n- **`list_errors()`** — files that failed to parse during the last reindex\n- **`stats()`** — counts of entities\u002Fevents\u002Ferrors in the index\n\n### When to use\n\nThe MCP server runs continuously inside the dev container. Agents call it\nwhenever they need fast lookup. Other MCP servers (`workitem-management`,\n`decision-record`, etc.) call `reindex` after writing a new entity to\nkeep the index fresh.\n\n### Where the database lives\n\n`\u003Cproject-root>\u002Fcontext\u002F.cache\u002Fprocesskit\u002Findex.sqlite`. Gitignored.\nRebuildable from source files at any time via `reindex()`.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Grepping the filesystem instead of calling `query_entities`.** The\n  index is faster, context-cheaper, and reflects parsed semantics\n  (state, kind, links) that grep can't see. Reach for `query_entities`\n  first; fall back to grep only if the query you need isn't supported.\n- **Trusting the index immediately after a hand-edit.** When you edit\n  an entity file directly (bypassing the MCP write tools), the index\n  is stale until the next `reindex()` call. Either go through the\n  write tools, or call `reindex()` yourself before querying.\n- **Forgetting to call `reindex` after writing a new entity.** Every\n  entity-creating MCP server should call `index_management.reindex`\n  (or the lighter `upsert_entity`) after a write. Not doing so means\n  the next query won't see the just-created entity.\n- **Treating index queries as transactional.** The index is eventually\n  consistent. A query immediately after a write may or may not return\n  the new row depending on whether reindex completed. If you need\n  strict consistency, reindex explicitly first.\n- **Trusting `list_errors()` as proof of correctness.** A clean errors\n  table means parsing succeeded, not that the entities are\n  semantically valid. Schema validation is a separate concern from\n  parse success.\n- **Using `search_entities` for exact-ID lookup.** `search_entities`\n  is full-text — it ranks by relevance and may miss exact ID matches\n  if the ID appears in many bodies. Use `get_entity(id)` for exact\n  lookup.\n- **Re-indexing inside a hot loop.** A full reindex walks the whole\n  `context\u002F` tree and is expensive. Batch your writes and reindex\n  once at the end, not after every entity.\n\n## Full reference\n\n### Database schema\n\nThree tables — see `src\u002Flib\u002Fprocesskit\u002Findex.py` for the DDL.\n\n```sql\nentities(id, kind, api_version, path, created, updated, title, state, labels_json, spec_json, body)\nevents(id, timestamp, event_type, actor, subject, subject_kind, summary, details_json, correlation_id, path)\nerrors(path, message)\n```\n\n`spec_json` holds the full `spec` block as JSON for queries we did not\nanticipate. `entities` and `events` overlap for LogEntry rows: a LogEntry\nappears in both, with the `events` table denormalizing the event-specific\nfields for fast filtering.\n\n### Reindex strategy\n\n`reindex()` is **destructive and atomic** — it deletes all rows and\nre-inserts. For typical projects this is fast (sub-second). For very\nlarge projects, an incremental update mode lands later (Phase 4+).\n\n### Errors table\n\nFiles that fail to parse get a row in the `errors` table instead of\ncrashing the reindex. `list_errors()` returns all such rows so the agent\ncan fix them. The errors table is cleared at the start of each reindex.\n\n### Tools that other servers call\n\n`workitem-management`, `decision-record`, `binding-management`, and\n`event-log` all call `index_management.upsert_entity` after writing a\nnew file. This keeps the index in sync without a full reindex on every\nmutation. From an MCP-protocol perspective each server has its own\nprocess — they communicate by sharing the same SQLite database file\n(WAL mode would be enabled in a future release for concurrent writes).\n\n### Configuration\n\nThe index database path is configurable via:\n\n- `processkit.toml` `[index] path = \"...\"` (relative to project root)\n- The `PROCESSKIT_INDEX_DB` environment variable\n- Default: `context\u002F.cache\u002Fprocesskit\u002Findex.sqlite` (gitignored cache)\n\n### Limitations at v0.3.0\n\n- **WAL mode enabled (v0.4.0+).** Multiple readers and a single writer\n  are safe; concurrent writes still serialize via WAL. Typical\n  AI-assisted sessions are single-writer anyway.\n- **No FTS.** Search uses `LIKE %text%`. SQLite FTS5 integration lands\n  in a later release.\n- **No incremental indexing.** Every reindex is a full sweep.\n",{"name":5,"metadata":52,"description":69},{"processkit":53},{"id":54,"layer":14,"created":55,"version":56,"category":57,"provides":58,"apiVersion":68},"SKILL-index-management",1775433600000,"1.0.0","processkit",{"mcp_tools":59,"primitives":67},[60,61,62,63,64,65,66],"reindex","query_entities","get_entity","search_entities","query_events","list_errors","stats",[],"processkit.projectious.work\u002Fv1","SQLite-backed index over all entity files in the project. The read-side foundation for every other MCP server. Use whenever an agent needs to look up entities by ID, kind, state, or text — instead of grepping the filesystem.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":78,"prompt":88,"zipAvailable":89},[79,82,85],{"tool":80,"command":81},"npx","npx skills add projectious-work\u002Fprocesskit --skill index-management",{"tool":83,"command":84},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill index-management",{"tool":86,"command":87},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill index-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002FSKILL.md",true,[91,97,103,107],{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"config\u002Fsettings.toml","OTHER","其他",705,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fconfig\u002Fsettings.toml",{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"mcp\u002Fmcp-config.json","REFERENCE","参考文档",215,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fmcp\u002Fmcp-config.json",{"path":104,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":105,"sourceHtmlUrl":106},"mcp\u002FSERVER.md",2336,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fmcp\u002FSERVER.md",{"path":108,"resourceType":109,"resourceTypeDesc":110,"sizeBytes":111,"sourceHtmlUrl":112},"mcp\u002Fserver.py","SCRIPT","脚本",6622,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fmcp\u002Fserver.py",[114,134,153,172,189,207],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":47},"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",[120],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[27,122,123,124,125,126,42,40,127,128,116,35,129,130,131,132,133],"skill management","create","update","package","alpha","manage","ontology","as","manifests","v1","skill package","transition",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":47},"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",[140],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[27,142,143,39,144,145,126,42,146,147,127,148,149,150,35,151,152],"schema","schema management","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":47},"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",[],[27,160,161,123,124,29,126,42,162,163,164,37,35,165,166,167,168,169,170,171],"proposition","proposition management","log","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":47},"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",[],[27,128,179,123,126,180,181,146,182,162,127,183,184,35,185,186,166,187,131,188],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":47},"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",[],[196,197,198,199,126,200,201,202,42,203,204,205,206],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":213,"publishedAt":47},"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",[],[27,214,215,123,124,29,126,180,42,40,162,216,127,164,35,186,166,167,217,133],"capability","capability management","queries","changes"]