[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X41ZDFRFAA3HQ4JBA2CZAY":3,"skill-same:01M6X41ZDFRFAA3HQ4JBA2CZAY":77},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6X41ZDFRFAA3HQ4JBA2CZAY","nosql-patterns",null,"NoSQL patterns for document, key-value, wide-column, and graph stores. Access-pattern-driven design and consistency models. Use when choosing between NoSQL store types, designing a document or single-table model, picking a consistency level, or migrating between relational and NoSQL.","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.7.0\u002Fskills\u002Fnosql-patterns\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"nosql","nosql patterns","patterns","store","when","single","value","for","v1","key-value","consistency","types","design","relational","document","use","work","model","access","database","2026-11-10 10:12:30",false,"---\nname: nosql-patterns\ndescription: |\n  NoSQL patterns for document, key-value, wide-column, and graph stores. Access-pattern-driven design and consistency models. Use when choosing between NoSQL store types, designing a document or single-table model, picking a consistency level, or migrating between relational and NoSQL.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-nosql-patterns\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: database\n---\n\n# NoSQL Patterns\n\n## Intro\n\nNoSQL is a family of stores, not a single technology — document,\nkey-value, wide-column, and graph databases each solve different\nproblems. The unifying design rule is the inverse of relational\nmodeling: start from the queries you must answer, then shape the\ndata to serve them.\n\n## Overview\n\n### Choose the right store type\n\nMatch the database type to the access pattern:\n\n| Type | Best for | Examples |\n|------|----------|---------|\n| Document | Variable-schema entities, nested data, content management | MongoDB, Couchbase, Firestore |\n| Key-Value | Caching, sessions, feature flags, counters | Redis, DynamoDB (simple), Memcached |\n| Wide-Column | Time-series, IoT telemetry, high-write analytics | Cassandra, ScyllaDB, HBase |\n| Graph | Relationship-heavy queries: social, recommendations, fraud | Neo4j, Neptune, ArangoDB |\n\n**Default to PostgreSQL** unless the use case clearly benefits from a\nspecialized store. Signs that NoSQL is warranted:\n\n- Schema varies significantly per record (document store).\n- Sub-millisecond latency for simple lookups (key-value).\n- Write volume exceeds what a single relational node can handle\n  (wide-column).\n- Queries traverse many relationships at variable depth (graph).\n\n### Design for access patterns, not entities\n\nRelational modeling normalizes around entities. NoSQL inverts this:\n\n1. List every read and write the application performs.\n2. For each read, define the exact key or query that retrieves it.\n3. Shape documents, rows, or keys so each read is one lookup or one\n   bounded scan.\n4. Accept duplication as a feature — the cost of a denormalized read\n   is paid by writes, which you can control.\n\n### Consistency models\n\n| Model | Guarantee | Use when |\n|-------|-----------|----------|\n| Strong | Read always returns latest write | Financial, inventory |\n| Eventual | Reads may be briefly stale | Feeds, analytics, caches |\n| Causal | Respects happens-before ordering | Chat, collaborative edit |\n| Read-your-writes | Writer sees own updates immediately | Profile updates, forms |\n\nCAP forces a choice during a network partition: availability (AP) or\nconsistency (CP). Most NoSQL stores default to AP with tunable\nconsistency. Use strong consistency where stale reads cause harm,\neventual elsewhere, and make writes idempotent so retries are safe.\n\n### Example: caching layer in Redis\n\nA cache-aside pattern with TTL-based expiration. Keys follow\n`resource:id:variant` naming, individual resources use `SET` with\n`EX`, paginated lists go in sorted sets, and writes invalidate via\n`DEL`. A circuit breaker keeps the API alive when Redis is\nunreachable.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Modeling a document store with a relational schema.** Designing documents as flat, normalized records and then joining them in application code recreates the worst of both worlds — no join support from the database and no embedding benefit from the document model. If entities are always queried together, embed them; if they are queried independently, separate them.\n- **Unbounded arrays inside documents.** Storing all comments, tags, or events inside a parent document's array field means the document grows without limit over time, eventually exceeding document size limits and causing reads to return megabytes of data for a simple lookup. Apply a growth bound: cap the array, move to a sub-collection, or use a separate collection for high-cardinality child entities.\n- **Hot partition keys in distributed stores.** Choosing a partition key like `date` or `country_code` concentrates write traffic on one shard when writes cluster by time or geography. Distribute load with a high-cardinality key — user ID, entity UUID — or composite key with a random suffix. A hot partition is a throughput ceiling that is expensive to undo after data is written.\n- **Requesting strong consistency by default everywhere.** Strong consistency requires coordination across replicas, adding latency and reducing availability. Most reads tolerate eventual consistency — a profile page, a product listing — and should use it. Reserve strong consistency for operations where stale reads would produce incorrect behavior (e.g., inventory decrement, financial balances).\n- **Using Pub\u002FSub or a message queue as a durable event store.** Message brokers designed for fan-out have limited retention and no replay-from-offset semantics in the same sense as an append-only log. Replaying events after a consumer bug, or querying historical event sequences, requires a separate event store. Use a dedicated event store when durability and replay are requirements.\n- **Forgetting that NoSQL writes require idempotency.** Retries under network failures can result in duplicate writes to a document store that has no unique constraint by default. Design write operations to be idempotent by using a client-generated idempotency key, a conditional write (update-if-version), or an upsert pattern so re-running the operation produces the same state.\n- **Choosing a NoSQL store without measuring the relational database's limitation.** The assumption \"SQL won't scale\" is often made without load testing the relational option with proper indexing and connection pooling. Most applications under 10M rows and moderate write rates perform well on a relational database. Choose NoSQL for a specific, measured reason — not as a default for new projects.\n\n## Full reference\n\n### Document stores (MongoDB)\n\n**Embed vs reference:**\n\n- **Embed** when child data is always read with the parent, child\n  count is bounded, and the child is not shared across parents.\n- **Reference** when the child is shared, the count is unbounded, or\n  the child is updated independently.\n\n```javascript\n\u002F\u002F Embedded: order with line items (always read together, bounded)\n{\n  _id: ObjectId(\"...\"),\n  customer_id: \"cust_123\",\n  status: \"shipped\",\n  items: [\n    { product_id: \"prod_456\", name: \"Widget\", qty: 2, price: 9.99 },\n    { product_id: \"prod_789\", name: \"Gadget\", qty: 1, price: 24.99 }\n  ],\n  created_at: ISODate(\"2025-06-15T10:30:00Z\")\n}\n\n\u002F\u002F Referenced: user with posts (unbounded, queried independently)\n{ _id: \"user_123\", name: \"Alice\", email: \"alice@example.com\" }\n{ _id: \"post_001\", author_id: \"user_123\", title: \"...\", body: \"...\" }\n```\n\n**Bucket pattern** for time-series data — group measurements into\nhourly (or similar) documents to keep document count manageable:\n\n```javascript\n{\n  sensor_id: \"temp-01\",\n  bucket: ISODate(\"2025-06-15T10:00:00Z\"),\n  measurements: [\n    { ts: ISODate(\"2025-06-15T10:00:12Z\"), value: 23.5 },\n    { ts: ISODate(\"2025-06-15T10:01:45Z\"), value: 23.7 }\n  ],\n  count: 2\n}\n```\n\n### Key-value stores (Redis)\n\nUse colons as separators for hierarchical keys so prefixes group\nnaturally:\n\n```\nuser:123:profile        -> JSON blob\nuser:123:sessions       -> Set of session IDs\nsession:abc-def-ghi     -> JSON blob with expiry\nrate_limit:api:user:123 -> Counter with TTL\n```\n\nCommon structures:\n\n- `SET`\u002F`GET` with TTL for caching and sessions.\n- `INCR` with `EXPIRE` for rate limiting.\n- Sorted sets (`ZADD`\u002F`ZRANGEBYSCORE`) for leaderboards and\n  time-ordered feeds.\n- Streams (`XADD`\u002F`XREAD`) for durable event processing.\n- Pub\u002FSub for fire-and-forget notifications (no persistence — use\n  Streams when durability matters).\n\n### DynamoDB single-table design\n\nStore multiple entity types in one table using composite keys\n(`PK` partition + `SK` sort):\n\n```\nPK                  SK                      Attributes\nUSER#123            PROFILE                 {name, email, plan}\nUSER#123            ORDER#2025-06-15#001    {status, total, items}\nUSER#123            ORDER#2025-06-15#002    {status, total, items}\nPRODUCT#456         METADATA                {name, price, category}\nPRODUCT#456         REVIEW#USER#123         {rating, comment}\n```\n\nQuery patterns served:\n\n- Get user profile: `PK = USER#123, SK = PROFILE`.\n- List user orders: `PK = USER#123, SK begins_with ORDER#`.\n- Orders in date range: `PK = USER#123,\n  SK between ORDER#2025-06-01 and ORDER#2025-06-30`.\n\nAdd Global Secondary Indexes (GSIs) for access patterns that need a\ndifferent key structure — for example, a GSI keyed on activity type\nto support admin dashboards, with a TTL attribute to age out old\nrecords.\n\n### Wide-column stores (Cassandra-style)\n\nModel one table per query. The partition key determines locality;\nthe clustering key determines on-disk order within a partition.\nAvoid hot partitions by including a high-cardinality component in\nthe partition key (often a time bucket). Wide-column stores reward\nwrite-optimized denormalization — duplicate data into multiple\ntables instead of joining at read time.\n\n### Graph stores\n\nUse a graph database when traversal depth is variable (friends-of-\nfriends, fraud rings, dependency chains) and traversal patterns\ndominate. For simple hierarchies, recursive CTEs in PostgreSQL are\nusually enough; reach for Neo4j or Neptune when you need shortest\npaths, weighted traversals, or pattern matching across many hops.\n\n### Anti-patterns\n\n- **Modeling NoSQL like a relational schema** — normalized documents\n  with cross-collection joins defeat the point.\n- **Unbounded arrays inside a document** — they grow until the\n  document hits a size limit; bucket or split.\n- **Hot partitions in DynamoDB\u002FCassandra** — concentrating writes on\n  one partition key throttles the whole table.\n- **Strong consistency by default everywhere** — costs latency and\n  availability without measurable benefit for most reads.\n- **Pub\u002FSub used for durable events** — messages are dropped if no\n  subscriber is connected; use Streams.\n- **Forgetting idempotency** — retries during failover will produce\n  duplicates without dedupe keys.\n","# NoSQL Patterns\n\n## Intro\n\nNoSQL is a family of stores, not a single technology — document,\nkey-value, wide-column, and graph databases each solve different\nproblems. The unifying design rule is the inverse of relational\nmodeling: start from the queries you must answer, then shape the\ndata to serve them.\n\n## Overview\n\n### Choose the right store type\n\nMatch the database type to the access pattern:\n\n| Type | Best for | Examples |\n|------|----------|---------|\n| Document | Variable-schema entities, nested data, content management | MongoDB, Couchbase, Firestore |\n| Key-Value | Caching, sessions, feature flags, counters | Redis, DynamoDB (simple), Memcached |\n| Wide-Column | Time-series, IoT telemetry, high-write analytics | Cassandra, ScyllaDB, HBase |\n| Graph | Relationship-heavy queries: social, recommendations, fraud | Neo4j, Neptune, ArangoDB |\n\n**Default to PostgreSQL** unless the use case clearly benefits from a\nspecialized store. Signs that NoSQL is warranted:\n\n- Schema varies significantly per record (document store).\n- Sub-millisecond latency for simple lookups (key-value).\n- Write volume exceeds what a single relational node can handle\n  (wide-column).\n- Queries traverse many relationships at variable depth (graph).\n\n### Design for access patterns, not entities\n\nRelational modeling normalizes around entities. NoSQL inverts this:\n\n1. List every read and write the application performs.\n2. For each read, define the exact key or query that retrieves it.\n3. Shape documents, rows, or keys so each read is one lookup or one\n   bounded scan.\n4. Accept duplication as a feature — the cost of a denormalized read\n   is paid by writes, which you can control.\n\n### Consistency models\n\n| Model | Guarantee | Use when |\n|-------|-----------|----------|\n| Strong | Read always returns latest write | Financial, inventory |\n| Eventual | Reads may be briefly stale | Feeds, analytics, caches |\n| Causal | Respects happens-before ordering | Chat, collaborative edit |\n| Read-your-writes | Writer sees own updates immediately | Profile updates, forms |\n\nCAP forces a choice during a network partition: availability (AP) or\nconsistency (CP). Most NoSQL stores default to AP with tunable\nconsistency. Use strong consistency where stale reads cause harm,\neventual elsewhere, and make writes idempotent so retries are safe.\n\n### Example: caching layer in Redis\n\nA cache-aside pattern with TTL-based expiration. Keys follow\n`resource:id:variant` naming, individual resources use `SET` with\n`EX`, paginated lists go in sorted sets, and writes invalidate via\n`DEL`. A circuit breaker keeps the API alive when Redis is\nunreachable.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Modeling a document store with a relational schema.** Designing documents as flat, normalized records and then joining them in application code recreates the worst of both worlds — no join support from the database and no embedding benefit from the document model. If entities are always queried together, embed them; if they are queried independently, separate them.\n- **Unbounded arrays inside documents.** Storing all comments, tags, or events inside a parent document's array field means the document grows without limit over time, eventually exceeding document size limits and causing reads to return megabytes of data for a simple lookup. Apply a growth bound: cap the array, move to a sub-collection, or use a separate collection for high-cardinality child entities.\n- **Hot partition keys in distributed stores.** Choosing a partition key like `date` or `country_code` concentrates write traffic on one shard when writes cluster by time or geography. Distribute load with a high-cardinality key — user ID, entity UUID — or composite key with a random suffix. A hot partition is a throughput ceiling that is expensive to undo after data is written.\n- **Requesting strong consistency by default everywhere.** Strong consistency requires coordination across replicas, adding latency and reducing availability. Most reads tolerate eventual consistency — a profile page, a product listing — and should use it. Reserve strong consistency for operations where stale reads would produce incorrect behavior (e.g., inventory decrement, financial balances).\n- **Using Pub\u002FSub or a message queue as a durable event store.** Message brokers designed for fan-out have limited retention and no replay-from-offset semantics in the same sense as an append-only log. Replaying events after a consumer bug, or querying historical event sequences, requires a separate event store. Use a dedicated event store when durability and replay are requirements.\n- **Forgetting that NoSQL writes require idempotency.** Retries under network failures can result in duplicate writes to a document store that has no unique constraint by default. Design write operations to be idempotent by using a client-generated idempotency key, a conditional write (update-if-version), or an upsert pattern so re-running the operation produces the same state.\n- **Choosing a NoSQL store without measuring the relational database's limitation.** The assumption \"SQL won't scale\" is often made without load testing the relational option with proper indexing and connection pooling. Most applications under 10M rows and moderate write rates perform well on a relational database. Choose NoSQL for a specific, measured reason — not as a default for new projects.\n\n## Full reference\n\n### Document stores (MongoDB)\n\n**Embed vs reference:**\n\n- **Embed** when child data is always read with the parent, child\n  count is bounded, and the child is not shared across parents.\n- **Reference** when the child is shared, the count is unbounded, or\n  the child is updated independently.\n\n```javascript\n\u002F\u002F Embedded: order with line items (always read together, bounded)\n{\n  _id: ObjectId(\"...\"),\n  customer_id: \"cust_123\",\n  status: \"shipped\",\n  items: [\n    { product_id: \"prod_456\", name: \"Widget\", qty: 2, price: 9.99 },\n    { product_id: \"prod_789\", name: \"Gadget\", qty: 1, price: 24.99 }\n  ],\n  created_at: ISODate(\"2025-06-15T10:30:00Z\")\n}\n\n\u002F\u002F Referenced: user with posts (unbounded, queried independently)\n{ _id: \"user_123\", name: \"Alice\", email: \"alice@example.com\" }\n{ _id: \"post_001\", author_id: \"user_123\", title: \"...\", body: \"...\" }\n```\n\n**Bucket pattern** for time-series data — group measurements into\nhourly (or similar) documents to keep document count manageable:\n\n```javascript\n{\n  sensor_id: \"temp-01\",\n  bucket: ISODate(\"2025-06-15T10:00:00Z\"),\n  measurements: [\n    { ts: ISODate(\"2025-06-15T10:00:12Z\"), value: 23.5 },\n    { ts: ISODate(\"2025-06-15T10:01:45Z\"), value: 23.7 }\n  ],\n  count: 2\n}\n```\n\n### Key-value stores (Redis)\n\nUse colons as separators for hierarchical keys so prefixes group\nnaturally:\n\n```\nuser:123:profile        -> JSON blob\nuser:123:sessions       -> Set of session IDs\nsession:abc-def-ghi     -> JSON blob with expiry\nrate_limit:api:user:123 -> Counter with TTL\n```\n\nCommon structures:\n\n- `SET`\u002F`GET` with TTL for caching and sessions.\n- `INCR` with `EXPIRE` for rate limiting.\n- Sorted sets (`ZADD`\u002F`ZRANGEBYSCORE`) for leaderboards and\n  time-ordered feeds.\n- Streams (`XADD`\u002F`XREAD`) for durable event processing.\n- Pub\u002FSub for fire-and-forget notifications (no persistence — use\n  Streams when durability matters).\n\n### DynamoDB single-table design\n\nStore multiple entity types in one table using composite keys\n(`PK` partition + `SK` sort):\n\n```\nPK                  SK                      Attributes\nUSER#123            PROFILE                 {name, email, plan}\nUSER#123            ORDER#2025-06-15#001    {status, total, items}\nUSER#123            ORDER#2025-06-15#002    {status, total, items}\nPRODUCT#456         METADATA                {name, price, category}\nPRODUCT#456         REVIEW#USER#123         {rating, comment}\n```\n\nQuery patterns served:\n\n- Get user profile: `PK = USER#123, SK = PROFILE`.\n- List user orders: `PK = USER#123, SK begins_with ORDER#`.\n- Orders in date range: `PK = USER#123,\n  SK between ORDER#2025-06-01 and ORDER#2025-06-30`.\n\nAdd Global Secondary Indexes (GSIs) for access patterns that need a\ndifferent key structure — for example, a GSI keyed on activity type\nto support admin dashboards, with a TTL attribute to age out old\nrecords.\n\n### Wide-column stores (Cassandra-style)\n\nModel one table per query. The partition key determines locality;\nthe clustering key determines on-disk order within a partition.\nAvoid hot partitions by including a high-cardinality component in\nthe partition key (often a time bucket). Wide-column stores reward\nwrite-optimized denormalization — duplicate data into multiple\ntables instead of joining at read time.\n\n### Graph stores\n\nUse a graph database when traversal depth is variable (friends-of-\nfriends, fraud rings, dependency chains) and traversal patterns\ndominate. For simple hierarchies, recursive CTEs in PostgreSQL are\nusually enough; reach for Neo4j or Neptune when you need shortest\npaths, weighted traversals, or pattern matching across many hops.\n\n### Anti-patterns\n\n- **Modeling NoSQL like a relational schema** — normalized documents\n  with cross-collection joins defeat the point.\n- **Unbounded arrays inside a document** — they grow until the\n  document hits a size limit; bucket or split.\n- **Hot partitions in DynamoDB\u002FCassandra** — concentrating writes on\n  one partition key throttles the whole table.\n- **Strong consistency by default everywhere** — costs latency and\n  availability without measurable benefit for most reads.\n- **Pub\u002FSub used for durable events** — messages are dropped if no\n  subscriber is connected; use Streams.\n- **Forgetting idempotency** — retries during failover will produce\n  duplicates without dedupe keys.\n",{"name":5,"metadata":49,"description":55},{"processkit":50},{"id":51,"created":52,"version":53,"category":43,"apiVersion":54},"SKILL-nosql-patterns",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","NoSQL patterns for document, key-value, wide-column, and graph stores. Access-pattern-driven design and consistency models. Use when choosing between NoSQL store types, designing a document or single-table model, picking a consistency level, or migrating between relational and NoSQL.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fnosql-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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add projectious-work\u002Fprocesskit --skill nosql-patterns",{"tool":69,"command":70},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill nosql-patterns",{"tool":72,"command":73},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill nosql-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.7.0\u002Fskills\u002Fnosql-patterns\u002FSKILL.md",true,[],[78,102,122,143,160,178],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":44},"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",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,92,93,40,94,95,96,80,97,98,99,32,100,101],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":44},"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",[108],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[88,110,111,112,113,114,93,40,115,116,95,117,118,119,97,120,121],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":44},"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",[],[88,129,130,90,91,131,93,40,132,133,134,135,97,136,137,138,139,140,141,142],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":44},"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",[],[88,96,150,90,93,151,152,115,153,132,95,154,155,97,156,157,137,158,32,159],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":44},"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",[],[167,168,169,170,93,171,172,173,40,174,175,176,177],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":44},"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",[],[88,185,186,90,91,131,93,151,40,94,132,187,95,134,97,157,137,138,188,101],"capability","capability management","queries","changes"]