[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WWKBQK7V251B25FV41FKB0":3,"skill-same:01M6WWKBQK7V251B25FV41FKB0":128},{"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":73,"commitSha":74,"skillDirectory":75,"forksCount":14,"repositoryHtmlUrl":76,"repositoryHomepageUrl":77,"ownerHtmlUrl":78,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":79,"install":80,"resources":93},"01M6WWKBQK7V251B25FV41FKB0","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\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],"index management","index","management","list","errors","events","get","project","query","files","up","MCP","read","work","text","sqlite","server","search","status","mcp server","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\u002Fv2\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,\n            semantic_status, semantic_search_entities, hybrid_search_entities,\n            query_events, list_errors, 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 may reach it directly from this skill's\n> `mcp\u002Fmcp-config.json` or through the processkit gateway. Gateway\n> deployments must surface only the processkit servers present in the\n> installed\u002Fmerged MCP configuration; this skill does not imply that\n> unrelated processkit tools are available.\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?)`** — FTS5 search across titles, bodies, specs\n- **`semantic_status()`** — report semantic chunk\u002Fvector availability\n- **`semantic_search_entities(text, limit?)`** — sqlite-vec semantic search when available\n- **`hybrid_search_entities(text, limit?)`** — RRF over FTS5 + semantic results, with FTS-only fallback\n- **`query_events(event_type?, subject?, actor?, limit?)`** — query the event log\n- **`list_errors(limit?)`** — files that failed to parse during the last reindex\n- **`stats()`** — counts of entities\u002Fevents\u002Ferrors in the index\n\nList\u002Fsearch tools clamp caller-provided limits before querying the\ndatabase. Broad unfiltered event queries are capped more tightly than\nfiltered event queries, and long event summaries are returned as\npreviews. Fetch a specific entity by ID when full detail is needed.\n\n### When to use\n\nAgents call the MCP server whenever they need fast lookup. Other MCP\nservers (`workitem-management`, `decision-record`, etc.) refresh the\nindex after writing a new entity to keep reads current. In gateway\ndeployments, the gateway only routes to index-management if this server\nis present in the installed MCP configuration.\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 ranked FTS5 search over parsed content, with a fallback substring\n  search for invalid FTS syntax. Use `get_entity(id)` for exact lookup.\n- **Assuming semantic search is always active.** The semantic chunk table\n  is always rebuilt, but vector KNN requires the optional `sqlite-vec`\n  extension to load. Check `semantic_status()`; use\n  `hybrid_search_entities()` when you want an FTS-backed fallback.\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, storage_location, created, updated, title, state, labels_json, spec_json, body)\nentities_fts(id, kind, state, title, body, spec_json)\nsemantic_chunks(rowid, chunk_id, entity_id, kind, state, path, ordinal, text)\nentity_vec(embedding)\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. `storage_location` is `NULL` for hot-tree files and points at cold\narchive payloads for archived entities. `entities` and `events` overlap for\nLogEntry rows: a LogEntry appears in both, with the `events` table\ndenormalizing the event-specific fields for fast filtering.\n\n`entities_fts` is a rebuildable SQLite FTS5 virtual table. It mirrors\nthe searchable fields from `entities` and is cleared\u002Frebuilt during\n`reindex()`. If a stripped-down SQLite build lacks FTS5, the index still\nopens and `search_entities` falls back to the previous `LIKE %text%`\nbehaviour.\n\n`semantic_chunks` is a rebuildable chunk table. When the optional\n`sqlite-vec` package can be imported and loaded, `entity_vec` is created\nas a `vec0` virtual table containing deterministic local embeddings for\nthose chunks. The initial embedding strategy is provider-neutral\n`local-hashed-bag-of-words`; it gives a stable offline baseline and a\nstorage contract for later provider\u002Flocal embedding model upgrades.\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(limit?)` returns a bounded window so\nthe agent can fix them in batches. The errors table is cleared at the\nstart of each reindex.\n\n### Tools that other servers call\n\n`workitem-management`, `decision-record`, `binding-management`, and\n`event-log` all call the shared index library after writing a new file.\nThis keeps the index in sync without a full reindex on every mutation.\nFrom an MCP-protocol perspective each configured server has its own\nprocess, or is reached through the gateway, and they communicate by\nsharing the same SQLite database file.\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- **FTS5 search.** Search uses SQLite FTS5 ranking when available and\n  falls back to `LIKE %text%` for invalid FTS syntax or unsupported\n  SQLite builds.\n- **Optional sqlite-vec.** Semantic search uses sqlite-vec only when the\n  extension is installed and loadable; otherwise semantic search returns\n  no vector results and hybrid search falls back to FTS5.\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 may reach it directly from this skill's\n> `mcp\u002Fmcp-config.json` or through the processkit gateway. Gateway\n> deployments must surface only the processkit servers present in the\n> installed\u002Fmerged MCP configuration; this skill does not imply that\n> unrelated processkit tools are available.\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?)`** — FTS5 search across titles, bodies, specs\n- **`semantic_status()`** — report semantic chunk\u002Fvector availability\n- **`semantic_search_entities(text, limit?)`** — sqlite-vec semantic search when available\n- **`hybrid_search_entities(text, limit?)`** — RRF over FTS5 + semantic results, with FTS-only fallback\n- **`query_events(event_type?, subject?, actor?, limit?)`** — query the event log\n- **`list_errors(limit?)`** — files that failed to parse during the last reindex\n- **`stats()`** — counts of entities\u002Fevents\u002Ferrors in the index\n\nList\u002Fsearch tools clamp caller-provided limits before querying the\ndatabase. Broad unfiltered event queries are capped more tightly than\nfiltered event queries, and long event summaries are returned as\npreviews. Fetch a specific entity by ID when full detail is needed.\n\n### When to use\n\nAgents call the MCP server whenever they need fast lookup. Other MCP\nservers (`workitem-management`, `decision-record`, etc.) refresh the\nindex after writing a new entity to keep reads current. In gateway\ndeployments, the gateway only routes to index-management if this server\nis present in the installed MCP configuration.\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 ranked FTS5 search over parsed content, with a fallback substring\n  search for invalid FTS syntax. Use `get_entity(id)` for exact lookup.\n- **Assuming semantic search is always active.** The semantic chunk table\n  is always rebuilt, but vector KNN requires the optional `sqlite-vec`\n  extension to load. Check `semantic_status()`; use\n  `hybrid_search_entities()` when you want an FTS-backed fallback.\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, storage_location, created, updated, title, state, labels_json, spec_json, body)\nentities_fts(id, kind, state, title, body, spec_json)\nsemantic_chunks(rowid, chunk_id, entity_id, kind, state, path, ordinal, text)\nentity_vec(embedding)\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. `storage_location` is `NULL` for hot-tree files and points at cold\narchive payloads for archived entities. `entities` and `events` overlap for\nLogEntry rows: a LogEntry appears in both, with the `events` table\ndenormalizing the event-specific fields for fast filtering.\n\n`entities_fts` is a rebuildable SQLite FTS5 virtual table. It mirrors\nthe searchable fields from `entities` and is cleared\u002Frebuilt during\n`reindex()`. If a stripped-down SQLite build lacks FTS5, the index still\nopens and `search_entities` falls back to the previous `LIKE %text%`\nbehaviour.\n\n`semantic_chunks` is a rebuildable chunk table. When the optional\n`sqlite-vec` package can be imported and loaded, `entity_vec` is created\nas a `vec0` virtual table containing deterministic local embeddings for\nthose chunks. The initial embedding strategy is provider-neutral\n`local-hashed-bag-of-words`; it gives a stable offline baseline and a\nstorage contract for later provider\u002Flocal embedding model upgrades.\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(limit?)` returns a bounded window so\nthe agent can fix them in batches. The errors table is cleared at the\nstart of each reindex.\n\n### Tools that other servers call\n\n`workitem-management`, `decision-record`, `binding-management`, and\n`event-log` all call the shared index library after writing a new file.\nThis keeps the index in sync without a full reindex on every mutation.\nFrom an MCP-protocol perspective each configured server has its own\nprocess, or is reached through the gateway, and they communicate by\nsharing the same SQLite database file.\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- **FTS5 search.** Search uses SQLite FTS5 ranking when available and\n  falls back to `LIKE %text%` for invalid FTS syntax or unsupported\n  SQLite builds.\n- **Optional sqlite-vec.** Semantic search uses sqlite-vec only when the\n  extension is installed and loadable; otherwise semantic search returns\n  no vector results and hybrid search falls back to FTS5.\n- **No incremental indexing.** Every reindex is a full sweep.\n",{"name":5,"metadata":52,"description":72},{"processkit":53},{"id":54,"layer":14,"created":55,"version":56,"category":57,"provides":58,"apiVersion":71},"SKILL-index-management",1775433600000,"1.0.0","processkit",{"mcp_tools":59,"primitives":70},[60,61,62,63,64,65,66,67,68,69],"reindex","query_entities","get_entity","search_entities","semantic_status","semantic_search_entities","hybrid_search_entities","query_events","list_errors","stats",[],"processkit.projectious.work\u002Fv2","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\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-11 23:24:18",{"source":8,"skillName":5,"commands":81,"prompt":91,"zipAvailable":92},[82,85,88],{"tool":83,"command":84},"npx","npx skills add projectious-work\u002Fprocesskit --skill index-management",{"tool":86,"command":87},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill index-management",{"tool":89,"command":90},"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\u002Fskills\u002Fprocesskit\u002Findex-management\u002FSKILL.md",true,[94,100,106,110,116,120,124],{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"config\u002Fsettings.toml","OTHER","其他",1289,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fconfig\u002Fsettings.toml",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"mcp\u002Fmcp-config.json","REFERENCE","参考文档",235,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fmcp\u002Fmcp-config.json",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"mcp\u002FSERVER.md",3411,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fmcp\u002FSERVER.md",{"path":111,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":114,"sourceHtmlUrl":115},"mcp\u002Fserver.py","SCRIPT","脚本",20582,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fmcp\u002Fserver.py",{"path":117,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":118,"sourceHtmlUrl":119},"scripts\u002Ftest_db_result_limits.py",3236,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fscripts\u002Ftest_db_result_limits.py",{"path":121,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Ftest_get_entity_by_path_and_list_entities.py",9657,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fscripts\u002Ftest_get_entity_by_path_and_list_entities.py",{"path":125,"resourceType":112,"resourceTypeDesc":113,"sizeBytes":126,"sourceHtmlUrl":127},"scripts\u002Ftest_index_management_v1_penalty.py",12753,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Fskills\u002Fprocesskit\u002Findex-management\u002Fscripts\u002Ftest_index_management_v1_penalty.py",[129,149,168,187,204,222],{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"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",[135],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,137,138,139,140,141,40,30,142,143,131,33,144,145,146,147,148],"skill management","create","update","package","alpha","manage","ontology","as","manifests","v1","skill package","transition",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"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",[155],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,157,158,38,159,160,141,40,161,162,142,163,164,165,33,166,167],"schema","schema management","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"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",[],[29,175,176,138,139,28,141,40,177,178,179,35,33,180,181,182,183,184,185,186],"proposition","proposition management","log","world","record","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"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",[],[29,143,194,138,141,195,196,161,197,177,142,198,199,33,200,201,181,202,146,203],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":210,"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",[],[211,212,213,214,141,215,216,217,40,218,219,220,221],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":228,"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",[],[29,229,230,138,139,28,141,195,40,30,177,231,142,179,33,201,181,182,232,148],"capability","capability management","queries","changes"]