[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZWKSA183P2CSGDT3HSR4E":3,"skill-same:01M6WZWKSA183P2CSGDT3HSR4E":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},"01M6WZWKSA183P2CSGDT3HSR4E","embedding-vectordb",null,"Vector embeddings and vector DB patterns — model choice, similarity metrics, index tuning. Use when choosing an embedding model, picking or migrating between vector databases, optimizing semantic search quality or latency, or building a hybrid (dense + sparse) retrieval pipeline.","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\u002Fdata-ai\u002Fembedding-vectordb\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"embedding vectordb","embedding","latency","when","vector db patterns","hybrid","v1","retrieval","similarity","db","semantic search","databases","use","work","choice","quality","model","pipeline","vector","search","2026-11-10 10:12:30",false,"---\nname: embedding-vectordb\ndescription: |\n  Vector embeddings and vector DB patterns — model choice, similarity metrics, index tuning. Use when choosing an embedding model, picking or migrating between vector databases, optimizing semantic search quality or latency, or building a hybrid (dense + sparse) retrieval pipeline.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-embedding-vectordb\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: data-ai\n---\n\n# Embedding and Vector Database Patterns\n\n## Intro\n\nSemantic search lives or dies on three choices: the embedding model,\nthe vector store, and the index parameters. Default to cosine\nsimilarity, hybrid retrieval (dense + BM25), and HNSW indexes — then\nbenchmark on your own eval set before tuning.\n\n## Overview\n\n### Embedding model selection\n\nPick on domain match, dimensionality, context window, latency, and\ncost. MTEB scores are general — benchmark on YOUR data. Smaller\nmodels (MiniLM) suit real-time; larger ones (e5-mistral) suit batch.\nOpen-source is free to run but needs GPU infrastructure.\n\nCommercial:\n\n| Model | Dims | Max tokens | Strengths |\n|---|---|---|---|\n| OpenAI text-embedding-3-small | 1536 | 8191 | Good default, low cost |\n| OpenAI text-embedding-3-large | 3072 | 8191 | Higher quality, Matryoshka |\n| Cohere embed-v3 | 1024 | 512 | Multilingual, search\u002Fclassify |\n| Voyage voyage-3 | 1024 | 32000 | Long context, strong on code |\n\nOpen-source:\n\n| Model | Dims | Max tokens | Strengths |\n|---|---|---|---|\n| nomic-embed-text-v1.5 | 768 | 8192 | Strong MTEB, Matryoshka |\n| bge-large-en-v1.5 | 1024 | 512 | English, well-tested |\n| e5-mistral-7b-instruct | 4096 | 32768 | Best open quality, high compute |\n| all-MiniLM-L6-v2 | 384 | 256 | Tiny, fast, prototyping |\n\n### Dimensionality and Matryoshka\n\nMatryoshka embeddings (OpenAI text-embedding-3, nomic-embed) allow\ntruncating dimensions without retraining: 3072 → 1024 or 512 trades\nmodest quality loss for faster search. Test at each dimension on\nyour eval set before committing. Rule of thumb: 256–512 dims is\nenough for most retrieval; 1024+ for fine-grained similarity.\n\n### Similarity metrics\n\n| Metric | Range | Best for |\n|---|---|---|\n| Cosine similarity | [-1, 1] | Normalized embeddings (most common) |\n| Dot product | (-inf, inf) | When magnitude matters |\n| Euclidean (L2) | [0, inf) | Spatial clustering |\n\nDefault is cosine — most embedding models are trained with it. For\nunit-length embeddings, cosine equals dot product.\n\n### Vector database selection\n\n| Database | Architecture | Best for | Scaling |\n|---|---|---|---|\n| FAISS | In-memory library | Prototyping, \u003C 10M | Single machine |\n| pgvector | Postgres extension | Postgres shops, joins + filtering | Vertical |\n| Chroma | Embedded DB | Local dev, quick experiments | Single, \u003C 1M |\n| Qdrant | Rust client-server | Production, advanced filtering | Horizontal |\n| Weaviate | Go, built-in vectorizers | Multimodal, auto-vectorization | Horizontal |\n| Pinecone | Managed SaaS | Zero-ops, serverless | Fully managed |\n| Milvus | Distributed cloud-native | Billions of vectors | Horizontal |\n\nDecision flow: prototyping → Chroma or FAISS. Already on Postgres →\npgvector. Production with advanced filtering → Qdrant or Weaviate.\nZero ops → Pinecone. Billions of vectors → Milvus.\n\n### Index types\n\n**HNSW** is the default for most vector DBs. Key params: `M`\n(connections per node, default 16), `ef_construction` (build quality,\ndefault 200), `ef_search` (query quality, default 100). Higher M and\nef = better recall, more memory, slower build. Start with defaults;\ntune `ef_search` up for recall, down for latency.\n\n**IVF** clusters vectors and searches only relevant clusters. Params:\n`nlist` ≈ sqrt(N), `nprobe` ≈ nlist\u002F10 to nlist\u002F5. Faster than HNSW\nabove ~100M vectors.\n\n**PQ (Product Quantization)** compresses vectors with slight quality\nloss. Use when the dataset will not fit in memory. Often combined as\nIVF-PQ.\n\n### Hybrid search\n\nCombine dense (semantic) and sparse (keyword\u002FBM25) retrieval: dense\ncatches \"automobile\" matching \"car,\" sparse catches exact matches\n(product IDs, acronyms, proper nouns). Fuse with Reciprocal Rank\nFusion: `RRF = sum(1 \u002F (k + rank_i))` with k typically 60. Hybrid\nalmost always outperforms either method alone. Qdrant and Weaviate\nhave built-in hybrid; for others, run BM25\n(Elasticsearch\u002FOpenSearch) and vector search separately and fuse.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Choosing an embedding model based solely on MTEB leaderboard scores.** MTEB benchmarks general-purpose retrieval; your domain may have different vocabulary, query patterns, or document lengths. Always benchmark candidate models on a small eval set from your own data before committing to one.\n- **Using L2 (Euclidean) distance with embeddings trained for cosine similarity.** Most embedding models are trained with cosine similarity as the loss. Using L2 distance with them produces incorrect similarity rankings. Check the model card for the intended distance metric before configuring the vector store index.\n- **Embedding raw documents and chunking after the fact.** An embedding represents the full input as a single vector. Embedding a 10,000-word document produces one vector that represents everything and nothing specifically. Chunk first, then embed each chunk.\n- **Pure dense retrieval for catalogs with exact identifiers.** Dense (semantic) retrieval fails on product SKUs, proper nouns, acronyms, and precise version numbers — it is too fuzzy. Combine with sparse (BM25 \u002F keyword) retrieval using reciprocal rank fusion for these use cases.\n- **No eval set to detect retrieval regressions.** Without a golden set of queries with expected results, there is no way to know whether a change to chunking, embedding model, or index parameters improved or degraded retrieval quality. Build an eval set before the first production deployment.\n- **Single embedding model for both query and document without asymmetric fine-tuning.** Queries and documents have different linguistic patterns. Some models (e.g., Voyage, `e5-instruct`) require instruction prefixes like `\"Represent this document:\"` for passages and `\"Represent this query:\"` for queries. Using the wrong prefix produces poorer retrieval.\n- **Sharing one DataLoader (or equivalent batch object) instance across search requests.** Results from a cached retrieval object may belong to a different request's context. Always create per-request retrieval objects when batching or caching at the database layer.\n\n## Full reference\n\n### Metadata filtering and multi-tenancy\n\nStore metadata alongside vectors: source, date, category, tenant_id.\nPre-filter (filter before vector search) is more efficient than\npost-filter. For multi-tenancy, use a metadata filter on tenant_id\nor separate collections per tenant. Index metadata fields used in\nfilters for performance.\n\n### Embedding pipeline best practices\n\n- **Batch processing** — embed in batches of 100–500 for API\n  efficiency\n- **Caching** — cache by content hash to skip re-embedding unchanged\n  content\n- **Normalization** — normalize to unit length when using cosine\n- **Chunking alignment** — chunk text before embedding, never embed\n  then chunk\n- **Monitoring** — track embedding latency, cache hit rate, and\n  index size over time\n\n### Worked examples\n\n- **Semantic search for a docs site:** `text-embedding-3-small` for\n  cost-effective embedding; pgvector if already on Postgres,\n  otherwise Qdrant. Hybrid search (BM25 + dense). Chunk by section\n  headers at 512 tokens. Build a 50-query eval set with expected\n  results to tune retrieval.\n- **Slow vector search at 5M vectors (> 500ms):** If flat index,\n  switch to HNSW. If HNSW, lower `ef_search` (recall vs speed).\n  Consider Matryoshka 3072 → 1024. Enable metadata pre-filtering to\n  shrink the search space. Benchmark each change against the eval\n  set.\n- **Migrating Chroma → Qdrant:** Export vectors and metadata.\n  Create Qdrant collection with matching distance metric and\n  dimensions. Batch-upload. Verify record count. Run the eval set\n  against both for recall and latency. Configure Qdrant replication\n  for HA.\n\n### Anti-patterns\n\n- Picking a model from MTEB without benchmarking on your domain\n- Using L2 distance with embeddings trained for cosine\n- Embedding raw documents and chunking after the fact\n- Pure dense retrieval for catalogs full of SKUs and proper nouns\n- Production vector store with no eval set to detect regressions\n","# Embedding and Vector Database Patterns\n\n## Intro\n\nSemantic search lives or dies on three choices: the embedding model,\nthe vector store, and the index parameters. Default to cosine\nsimilarity, hybrid retrieval (dense + BM25), and HNSW indexes — then\nbenchmark on your own eval set before tuning.\n\n## Overview\n\n### Embedding model selection\n\nPick on domain match, dimensionality, context window, latency, and\ncost. MTEB scores are general — benchmark on YOUR data. Smaller\nmodels (MiniLM) suit real-time; larger ones (e5-mistral) suit batch.\nOpen-source is free to run but needs GPU infrastructure.\n\nCommercial:\n\n| Model | Dims | Max tokens | Strengths |\n|---|---|---|---|\n| OpenAI text-embedding-3-small | 1536 | 8191 | Good default, low cost |\n| OpenAI text-embedding-3-large | 3072 | 8191 | Higher quality, Matryoshka |\n| Cohere embed-v3 | 1024 | 512 | Multilingual, search\u002Fclassify |\n| Voyage voyage-3 | 1024 | 32000 | Long context, strong on code |\n\nOpen-source:\n\n| Model | Dims | Max tokens | Strengths |\n|---|---|---|---|\n| nomic-embed-text-v1.5 | 768 | 8192 | Strong MTEB, Matryoshka |\n| bge-large-en-v1.5 | 1024 | 512 | English, well-tested |\n| e5-mistral-7b-instruct | 4096 | 32768 | Best open quality, high compute |\n| all-MiniLM-L6-v2 | 384 | 256 | Tiny, fast, prototyping |\n\n### Dimensionality and Matryoshka\n\nMatryoshka embeddings (OpenAI text-embedding-3, nomic-embed) allow\ntruncating dimensions without retraining: 3072 → 1024 or 512 trades\nmodest quality loss for faster search. Test at each dimension on\nyour eval set before committing. Rule of thumb: 256–512 dims is\nenough for most retrieval; 1024+ for fine-grained similarity.\n\n### Similarity metrics\n\n| Metric | Range | Best for |\n|---|---|---|\n| Cosine similarity | [-1, 1] | Normalized embeddings (most common) |\n| Dot product | (-inf, inf) | When magnitude matters |\n| Euclidean (L2) | [0, inf) | Spatial clustering |\n\nDefault is cosine — most embedding models are trained with it. For\nunit-length embeddings, cosine equals dot product.\n\n### Vector database selection\n\n| Database | Architecture | Best for | Scaling |\n|---|---|---|---|\n| FAISS | In-memory library | Prototyping, \u003C 10M | Single machine |\n| pgvector | Postgres extension | Postgres shops, joins + filtering | Vertical |\n| Chroma | Embedded DB | Local dev, quick experiments | Single, \u003C 1M |\n| Qdrant | Rust client-server | Production, advanced filtering | Horizontal |\n| Weaviate | Go, built-in vectorizers | Multimodal, auto-vectorization | Horizontal |\n| Pinecone | Managed SaaS | Zero-ops, serverless | Fully managed |\n| Milvus | Distributed cloud-native | Billions of vectors | Horizontal |\n\nDecision flow: prototyping → Chroma or FAISS. Already on Postgres →\npgvector. Production with advanced filtering → Qdrant or Weaviate.\nZero ops → Pinecone. Billions of vectors → Milvus.\n\n### Index types\n\n**HNSW** is the default for most vector DBs. Key params: `M`\n(connections per node, default 16), `ef_construction` (build quality,\ndefault 200), `ef_search` (query quality, default 100). Higher M and\nef = better recall, more memory, slower build. Start with defaults;\ntune `ef_search` up for recall, down for latency.\n\n**IVF** clusters vectors and searches only relevant clusters. Params:\n`nlist` ≈ sqrt(N), `nprobe` ≈ nlist\u002F10 to nlist\u002F5. Faster than HNSW\nabove ~100M vectors.\n\n**PQ (Product Quantization)** compresses vectors with slight quality\nloss. Use when the dataset will not fit in memory. Often combined as\nIVF-PQ.\n\n### Hybrid search\n\nCombine dense (semantic) and sparse (keyword\u002FBM25) retrieval: dense\ncatches \"automobile\" matching \"car,\" sparse catches exact matches\n(product IDs, acronyms, proper nouns). Fuse with Reciprocal Rank\nFusion: `RRF = sum(1 \u002F (k + rank_i))` with k typically 60. Hybrid\nalmost always outperforms either method alone. Qdrant and Weaviate\nhave built-in hybrid; for others, run BM25\n(Elasticsearch\u002FOpenSearch) and vector search separately and fuse.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Choosing an embedding model based solely on MTEB leaderboard scores.** MTEB benchmarks general-purpose retrieval; your domain may have different vocabulary, query patterns, or document lengths. Always benchmark candidate models on a small eval set from your own data before committing to one.\n- **Using L2 (Euclidean) distance with embeddings trained for cosine similarity.** Most embedding models are trained with cosine similarity as the loss. Using L2 distance with them produces incorrect similarity rankings. Check the model card for the intended distance metric before configuring the vector store index.\n- **Embedding raw documents and chunking after the fact.** An embedding represents the full input as a single vector. Embedding a 10,000-word document produces one vector that represents everything and nothing specifically. Chunk first, then embed each chunk.\n- **Pure dense retrieval for catalogs with exact identifiers.** Dense (semantic) retrieval fails on product SKUs, proper nouns, acronyms, and precise version numbers — it is too fuzzy. Combine with sparse (BM25 \u002F keyword) retrieval using reciprocal rank fusion for these use cases.\n- **No eval set to detect retrieval regressions.** Without a golden set of queries with expected results, there is no way to know whether a change to chunking, embedding model, or index parameters improved or degraded retrieval quality. Build an eval set before the first production deployment.\n- **Single embedding model for both query and document without asymmetric fine-tuning.** Queries and documents have different linguistic patterns. Some models (e.g., Voyage, `e5-instruct`) require instruction prefixes like `\"Represent this document:\"` for passages and `\"Represent this query:\"` for queries. Using the wrong prefix produces poorer retrieval.\n- **Sharing one DataLoader (or equivalent batch object) instance across search requests.** Results from a cached retrieval object may belong to a different request's context. Always create per-request retrieval objects when batching or caching at the database layer.\n\n## Full reference\n\n### Metadata filtering and multi-tenancy\n\nStore metadata alongside vectors: source, date, category, tenant_id.\nPre-filter (filter before vector search) is more efficient than\npost-filter. For multi-tenancy, use a metadata filter on tenant_id\nor separate collections per tenant. Index metadata fields used in\nfilters for performance.\n\n### Embedding pipeline best practices\n\n- **Batch processing** — embed in batches of 100–500 for API\n  efficiency\n- **Caching** — cache by content hash to skip re-embedding unchanged\n  content\n- **Normalization** — normalize to unit length when using cosine\n- **Chunking alignment** — chunk text before embedding, never embed\n  then chunk\n- **Monitoring** — track embedding latency, cache hit rate, and\n  index size over time\n\n### Worked examples\n\n- **Semantic search for a docs site:** `text-embedding-3-small` for\n  cost-effective embedding; pgvector if already on Postgres,\n  otherwise Qdrant. Hybrid search (BM25 + dense). Chunk by section\n  headers at 512 tokens. Build a 50-query eval set with expected\n  results to tune retrieval.\n- **Slow vector search at 5M vectors (> 500ms):** If flat index,\n  switch to HNSW. If HNSW, lower `ef_search` (recall vs speed).\n  Consider Matryoshka 3072 → 1024. Enable metadata pre-filtering to\n  shrink the search space. Benchmark each change against the eval\n  set.\n- **Migrating Chroma → Qdrant:** Export vectors and metadata.\n  Create Qdrant collection with matching distance metric and\n  dimensions. Batch-upload. Verify record count. Run the eval set\n  against both for recall and latency. Configure Qdrant replication\n  for HA.\n\n### Anti-patterns\n\n- Picking a model from MTEB without benchmarking on your domain\n- Using L2 distance with embeddings trained for cosine\n- Embedding raw documents and chunking after the fact\n- Pure dense retrieval for catalogs full of SKUs and proper nouns\n- Production vector store with no eval set to detect regressions\n",{"name":5,"metadata":44,"description":51},{"processkit":45},{"id":46,"created":47,"version":48,"category":49,"apiVersion":50},"SKILL-embedding-vectordb",1775433600000,"1.1.0","data-ai","processkit.projectious.work\u002Fv1","Vector embeddings and vector DB patterns — model choice, similarity metrics, index tuning. Use when choosing an embedding model, picking or migrating between vector databases, optimizing semantic search quality or latency, or building a hybrid (dense + sparse) retrieval pipeline.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdata-ai\u002Fembedding-vectordb","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 embedding-vectordb",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill embedding-vectordb",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill embedding-vectordb","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fdata-ai\u002Fembedding-vectordb\u002FSKILL.md",true,[],[74,100,120,141,158,176],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":85,"publishedAt":39},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[86,87,88,89,90,91,32,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,112,91,32,113,114,93,115,116,117,95,118,119],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":39},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[86,127,128,88,89,129,91,32,130,131,132,133,95,134,135,136,137,138,139,140],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":39},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[86,94,148,88,91,149,150,113,151,130,93,152,153,95,154,155,135,156,25,157],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":39},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[165,166,167,168,91,169,170,171,32,172,173,174,175],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":39},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[86,183,184,88,89,129,91,149,32,92,130,185,93,132,95,155,135,136,186,99],"capability","capability management","queries","changes"]