[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NPW7HEX0FT7TM64BH9PFEX":3,"skill-same:01M6NPW7HEX0FT7TM64BH9PFEX":87},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":14,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M6NPW7HEX0FT7TM64BH9PFEX","database-migration",null,"Schema migration workflows — zero-downtime expand\u002Fcontract, batched backfills, and rollback strategies. Use when planning a schema migration, reviewing migration scripts, troubleshooting a slow or failed migration, or rolling back a deployed change.","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\u002Fsrc\u002Fcontext\u002Fskills\u002Fengineering\u002Fdatabase-migration\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"database","database migration","migration","work","scripts","expand","contract","strategies","zero-downtime","back","schema","use","workflows","rollback","troubleshooting","ZeRO","engineering","planning","schema migration","change","2026-11-10 10:12:30",false,"---\nname: database-migration\ndescription: |\n  Schema migration workflows — zero-downtime expand\u002Fcontract, batched backfills, and rollback strategies. Use when planning a schema migration, reviewing migration scripts, troubleshooting a slow or failed migration, or rolling back a deployed change.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv2\n    id: SKILL-database-migration\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Database Migration\n\n## Intro\n\nSchema changes are deploys against live state, so they need the same\ndiscipline as application releases. Use immutable, reversible\nmigrations and the expand\u002Fcontract pattern to keep production reads\nand writes flowing while the schema moves underneath them.\n\n## Overview\n\n### Migration file structure\n\nEvery migration has an `up` (apply) and `down` (revert) script. Tools\norder them by sequential version or timestamp:\n\n```\nmigrations\u002F\n  001_create_users.up.sql\n  001_create_users.down.sql\n  002_add_user_email_index.up.sql\n  002_add_user_email_index.down.sql\n```\n\nRules of the road:\n\n- One logical change per migration; do not mix unrelated alterations.\n- The `down` migration must fully reverse the `up` migration.\n- Migrations are immutable once applied — never edit a deployed\n  migration; write a new one.\n- Test both directions: `up` then `down` then `up` again must leave\n  the schema intact.\n\n### Expand \u002F migrate \u002F contract\n\nNever make a breaking change in a single step. The expand\u002Fcontract\npattern decouples schema and code so each can ship independently.\n\n**Phase 1 — Expand:** add the new structure alongside the old.\n\n```sql\nALTER TABLE users ADD COLUMN display_name TEXT;\n```\n\n**Phase 2 — Migrate:** backfill data and update the application to\nwrite to both columns and read from the new one.\n\n```sql\nUPDATE users SET display_name = name\nWHERE display_name IS NULL AND id BETWEEN 1 AND 10000;\n```\n\n**Phase 3 — Contract:** remove the old structure once all readers\nhave moved over.\n\n```sql\nALTER TABLE users ALTER COLUMN display_name SET NOT NULL;\n-- Later, in a separate migration:\nALTER TABLE users DROP COLUMN name;\n```\n\n### Batched backfills\n\nLarge backfills must be batched to avoid long locks, replication lag,\nand runaway WAL growth. Process 1,000–10,000 rows at a time, commit\nbetween batches, and add a short sleep so replicas can catch up. Run\nduring low-traffic windows for very large tables and monitor lag the\nwhole way.\n\n### Version tracking\n\nMigration tools record applied versions in a metadata table:\n\n```sql\nCREATE TABLE schema_migrations (\n    version TEXT PRIMARY KEY,\n    applied_at TIMESTAMPTZ NOT NULL DEFAULT NOW()\n);\n```\n\nCommon tools — Flyway, Liquibase, golang-migrate, Alembic, Knex,\nDiesel, Ecto — all follow the same pattern: ordered files plus a\ntracking table.\n\n### Example: rename a column with no downtime\n\nTo rename `username` to `handle`:\n\n1. Add `handle` (nullable), backfill from `username` in batches.\n2. Deploy code that writes both columns and reads from `handle`.\n3. Add `NOT NULL` on `handle`, then drop `username` in a later\n   migration once nothing reads it.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Locking a large table with ADD COLUMN ... DEFAULT.** In databases that rewrite the table to fill in the default (older PostgreSQL, MySQL without INSTANT algorithm), adding a column with a non-null default on a multi-million-row table takes a full table lock for minutes. Use a nullable column first, backfill in batches, then add the NOT NULL constraint once all rows are populated.\n- **Missing index on a foreign key column.** Adding a foreign key constraint without a corresponding index on the referencing column means every delete or update on the referenced table causes a full sequential scan of the child table to check referential integrity. Always create the index before or with the foreign key.\n- **DDL inside a long transaction with other writes.** A migration that runs inside the same transaction as application writes holds DDL locks for the entire transaction duration, blocking all other writers. Run DDL in short, isolated transactions; use concurrent index builds where the database supports them.\n- **Forgetting NULL during a backfill before NOT NULL constraint.** The sequence is: add column nullable → backfill → add NOT NULL. If the backfill script misses any rows (e.g., soft-deleted records, rows in an archive table), adding NOT NULL will fail or silently coerce nulls to a default. Verify zero nulls remain before adding the constraint.\n- **Irreversible migrations without a backup or rollback plan.** A migration that drops a column, truncates a table, or changes a type destructively cannot be undone after the fact. Always take a point-in-time backup, write a down migration before running the up migration, and validate the down migration on a staging copy before touching production.\n- **Editing a deployed migration instead of writing a new one.** Changing a migration file that has already run on any environment means that environment's schema history no longer matches the file. Write a new corrective migration; treat deployed migrations as immutable history.\n- **No dry-run on staging before production.** Running a migration directly on production without first running it on a staging environment of similar size means that unexpected lock durations, constraint violations, or data issues surface in production. Always run on staging with production-representative data volume first.\n\n## Full reference\n\n### Safe operations by database\n\nNot all `ALTER TABLE` operations are safe; the same statement can be\nfree on one engine and table-rewriting on another.\n\n| Operation | PostgreSQL | MySQL (InnoDB) |\n|-----------|-----------|----------------|\n| Add nullable column | Fast, no lock | Fast (8.0+), locks in 5.7 |\n| Add column with default | Fast (11+) | Rewrites table in 5.7, fast in 8.0+ |\n| Drop column | Fast (marks invisible) | Rewrites table |\n| Add index | `CONCURRENTLY` avoids lock | `ALGORITHM=INPLACE` for online |\n| Rename column | Fast | Fast (8.0+) |\n| Change column type | Rewrites table, locks | Rewrites table, locks |\n\nPostgreSQL-specific tips:\n\n- Always use `CREATE INDEX CONCURRENTLY` to avoid blocking writes.\n- `CONCURRENTLY` cannot run inside a transaction; configure the\n  migration tool to disable transaction wrapping for that file.\n- Add `NOT NULL` constraints with `NOT VALID` to skip checking\n  existing rows, then `VALIDATE CONSTRAINT` later in a separate step.\n\n### Backfill recipe\n\n```sql\nDO $$\nDECLARE\n    batch_size INT := 5000;\n    max_id BIGINT;\nBEGIN\n    SELECT MAX(id) INTO max_id FROM users;\n    FOR i IN 0..max_id\u002Fbatch_size LOOP\n        UPDATE users\n        SET display_name = name\n        WHERE display_name IS NULL\n          AND id BETWEEN i * batch_size + 1 AND (i + 1) * batch_size;\n        COMMIT;\n        PERFORM pg_sleep(0.1);  -- throttle to reduce load\n    END LOOP;\nEND $$;\n```\n\nMost teams run backfills from application code or a one-off script\nrather than inside the migration tool, so they can pause, resume, and\nreport progress.\n\n### Rollback strategies\n\nPlan for failure before running anything in production:\n\n- **Down migration** — the standard path. Must be tested before\n  deploying.\n- **Forward-fix** — sometimes rolling back is riskier than fixing\n  forward (especially after a destructive migration). Write a new\n  migration that corrects the issue.\n- **Point-in-time recovery (PITR)** — last resort. Restores the entire\n  database to a timestamp; everything written after that point is\n  lost.\n\nPre-flight checklist:\n\n1. Take a backup or confirm PITR is enabled.\n2. Run the migration on a staging copy with production-like data.\n3. Measure execution time on staging — a 2-second migration on\n   staging may take 20 minutes on production.\n4. Have the rollback command ready to execute before you start.\n\n### Concurrent index example\n\n```sql\n-- up\nCREATE INDEX CONCURRENTLY idx_orders_customer\n    ON orders (customer_id);\n\n-- down\nDROP INDEX CONCURRENTLY idx_orders_customer;\n```\n\n### Anti-patterns\n\n- **Locking a large table** with `ADD COLUMN ... DEFAULT x` on older\n  PostgreSQL\u002FMySQL. Use nullable + backfill instead.\n- **Missing index on a new foreign key.** PostgreSQL does not create\n  one automatically; deletes on the parent table will become slow\n  scans.\n- **DDL inside a long transaction.** PostgreSQL DDL takes\n  `ACCESS EXCLUSIVE` locks; combined with long-running queries this\n  cascades into lock waits across the cluster.\n- **Forgetting NULL during backfill.** Application code deployed\n  before the backfill completes must handle NULL in the new column.\n- **Irreversible migrations without a backup.** Dropping columns or\n  tables with no down migration and no PITR is data loss waiting to\n  happen.\n- **Editing a deployed migration.** Add a new one instead — staging\n  and production hashes will diverge otherwise.\n","# Database Migration\n\n## Intro\n\nSchema changes are deploys against live state, so they need the same\ndiscipline as application releases. Use immutable, reversible\nmigrations and the expand\u002Fcontract pattern to keep production reads\nand writes flowing while the schema moves underneath them.\n\n## Overview\n\n### Migration file structure\n\nEvery migration has an `up` (apply) and `down` (revert) script. Tools\norder them by sequential version or timestamp:\n\n```\nmigrations\u002F\n  001_create_users.up.sql\n  001_create_users.down.sql\n  002_add_user_email_index.up.sql\n  002_add_user_email_index.down.sql\n```\n\nRules of the road:\n\n- One logical change per migration; do not mix unrelated alterations.\n- The `down` migration must fully reverse the `up` migration.\n- Migrations are immutable once applied — never edit a deployed\n  migration; write a new one.\n- Test both directions: `up` then `down` then `up` again must leave\n  the schema intact.\n\n### Expand \u002F migrate \u002F contract\n\nNever make a breaking change in a single step. The expand\u002Fcontract\npattern decouples schema and code so each can ship independently.\n\n**Phase 1 — Expand:** add the new structure alongside the old.\n\n```sql\nALTER TABLE users ADD COLUMN display_name TEXT;\n```\n\n**Phase 2 — Migrate:** backfill data and update the application to\nwrite to both columns and read from the new one.\n\n```sql\nUPDATE users SET display_name = name\nWHERE display_name IS NULL AND id BETWEEN 1 AND 10000;\n```\n\n**Phase 3 — Contract:** remove the old structure once all readers\nhave moved over.\n\n```sql\nALTER TABLE users ALTER COLUMN display_name SET NOT NULL;\n-- Later, in a separate migration:\nALTER TABLE users DROP COLUMN name;\n```\n\n### Batched backfills\n\nLarge backfills must be batched to avoid long locks, replication lag,\nand runaway WAL growth. Process 1,000–10,000 rows at a time, commit\nbetween batches, and add a short sleep so replicas can catch up. Run\nduring low-traffic windows for very large tables and monitor lag the\nwhole way.\n\n### Version tracking\n\nMigration tools record applied versions in a metadata table:\n\n```sql\nCREATE TABLE schema_migrations (\n    version TEXT PRIMARY KEY,\n    applied_at TIMESTAMPTZ NOT NULL DEFAULT NOW()\n);\n```\n\nCommon tools — Flyway, Liquibase, golang-migrate, Alembic, Knex,\nDiesel, Ecto — all follow the same pattern: ordered files plus a\ntracking table.\n\n### Example: rename a column with no downtime\n\nTo rename `username` to `handle`:\n\n1. Add `handle` (nullable), backfill from `username` in batches.\n2. Deploy code that writes both columns and reads from `handle`.\n3. Add `NOT NULL` on `handle`, then drop `username` in a later\n   migration once nothing reads it.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Locking a large table with ADD COLUMN ... DEFAULT.** In databases that rewrite the table to fill in the default (older PostgreSQL, MySQL without INSTANT algorithm), adding a column with a non-null default on a multi-million-row table takes a full table lock for minutes. Use a nullable column first, backfill in batches, then add the NOT NULL constraint once all rows are populated.\n- **Missing index on a foreign key column.** Adding a foreign key constraint without a corresponding index on the referencing column means every delete or update on the referenced table causes a full sequential scan of the child table to check referential integrity. Always create the index before or with the foreign key.\n- **DDL inside a long transaction with other writes.** A migration that runs inside the same transaction as application writes holds DDL locks for the entire transaction duration, blocking all other writers. Run DDL in short, isolated transactions; use concurrent index builds where the database supports them.\n- **Forgetting NULL during a backfill before NOT NULL constraint.** The sequence is: add column nullable → backfill → add NOT NULL. If the backfill script misses any rows (e.g., soft-deleted records, rows in an archive table), adding NOT NULL will fail or silently coerce nulls to a default. Verify zero nulls remain before adding the constraint.\n- **Irreversible migrations without a backup or rollback plan.** A migration that drops a column, truncates a table, or changes a type destructively cannot be undone after the fact. Always take a point-in-time backup, write a down migration before running the up migration, and validate the down migration on a staging copy before touching production.\n- **Editing a deployed migration instead of writing a new one.** Changing a migration file that has already run on any environment means that environment's schema history no longer matches the file. Write a new corrective migration; treat deployed migrations as immutable history.\n- **No dry-run on staging before production.** Running a migration directly on production without first running it on a staging environment of similar size means that unexpected lock durations, constraint violations, or data issues surface in production. Always run on staging with production-representative data volume first.\n\n## Full reference\n\n### Safe operations by database\n\nNot all `ALTER TABLE` operations are safe; the same statement can be\nfree on one engine and table-rewriting on another.\n\n| Operation | PostgreSQL | MySQL (InnoDB) |\n|-----------|-----------|----------------|\n| Add nullable column | Fast, no lock | Fast (8.0+), locks in 5.7 |\n| Add column with default | Fast (11+) | Rewrites table in 5.7, fast in 8.0+ |\n| Drop column | Fast (marks invisible) | Rewrites table |\n| Add index | `CONCURRENTLY` avoids lock | `ALGORITHM=INPLACE` for online |\n| Rename column | Fast | Fast (8.0+) |\n| Change column type | Rewrites table, locks | Rewrites table, locks |\n\nPostgreSQL-specific tips:\n\n- Always use `CREATE INDEX CONCURRENTLY` to avoid blocking writes.\n- `CONCURRENTLY` cannot run inside a transaction; configure the\n  migration tool to disable transaction wrapping for that file.\n- Add `NOT NULL` constraints with `NOT VALID` to skip checking\n  existing rows, then `VALIDATE CONSTRAINT` later in a separate step.\n\n### Backfill recipe\n\n```sql\nDO $$\nDECLARE\n    batch_size INT := 5000;\n    max_id BIGINT;\nBEGIN\n    SELECT MAX(id) INTO max_id FROM users;\n    FOR i IN 0..max_id\u002Fbatch_size LOOP\n        UPDATE users\n        SET display_name = name\n        WHERE display_name IS NULL\n          AND id BETWEEN i * batch_size + 1 AND (i + 1) * batch_size;\n        COMMIT;\n        PERFORM pg_sleep(0.1);  -- throttle to reduce load\n    END LOOP;\nEND $$;\n```\n\nMost teams run backfills from application code or a one-off script\nrather than inside the migration tool, so they can pause, resume, and\nreport progress.\n\n### Rollback strategies\n\nPlan for failure before running anything in production:\n\n- **Down migration** — the standard path. Must be tested before\n  deploying.\n- **Forward-fix** — sometimes rolling back is riskier than fixing\n  forward (especially after a destructive migration). Write a new\n  migration that corrects the issue.\n- **Point-in-time recovery (PITR)** — last resort. Restores the entire\n  database to a timestamp; everything written after that point is\n  lost.\n\nPre-flight checklist:\n\n1. Take a backup or confirm PITR is enabled.\n2. Run the migration on a staging copy with production-like data.\n3. Measure execution time on staging — a 2-second migration on\n   staging may take 20 minutes on production.\n4. Have the rollback command ready to execute before you start.\n\n### Concurrent index example\n\n```sql\n-- up\nCREATE INDEX CONCURRENTLY idx_orders_customer\n    ON orders (customer_id);\n\n-- down\nDROP INDEX CONCURRENTLY idx_orders_customer;\n```\n\n### Anti-patterns\n\n- **Locking a large table** with `ADD COLUMN ... DEFAULT x` on older\n  PostgreSQL\u002FMySQL. Use nullable + backfill instead.\n- **Missing index on a new foreign key.** PostgreSQL does not create\n  one automatically; deletes on the parent table will become slow\n  scans.\n- **DDL inside a long transaction.** PostgreSQL DDL takes\n  `ACCESS EXCLUSIVE` locks; combined with long-running queries this\n  cascades into lock waits across the cluster.\n- **Forgetting NULL during backfill.** Application code deployed\n  before the backfill completes must handle NULL in the new column.\n- **Irreversible migrations without a backup.** Dropping columns or\n  tables with no down migration and no PITR is data loss waiting to\n  happen.\n- **Editing a deployed migration.** Add a new one instead — staging\n  and production hashes will diverge otherwise.\n",{"name":5,"metadata":54,"description":60},{"processkit":55},{"id":56,"created":57,"version":58,"category":45,"apiVersion":59},"SKILL-database-migration",1775433600000,"1.1.0","processkit.projectious.work\u002Fv2","Schema migration workflows — zero-downtime expand\u002Fcontract, batched backfills, and rollback strategies. Use when planning a schema migration, reviewing migration scripts, troubleshooting a slow or failed migration, or rolling back a deployed change.\n","main","7231f100e266e30d2c1699ecde5c00602471dc3c","src\u002Fcontext\u002Fskills\u002Fengineering\u002Fdatabase-migration","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":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add projectious-work\u002Fprocesskit --skill database-migration",{"tool":74,"command":75},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill database-migration",{"tool":77,"command":78},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill database-migration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fengineering\u002Fdatabase-migration\u002FSKILL.md",true,[82],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":14,"sourceHtmlUrl":86},"scripts\u002F.gitkeep","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fengineering\u002Fdatabase-migration\u002Fscripts\u002F.gitkeep",[88,113,130,151,168,186],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":97,"publishedAt":49},"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",[94],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[98,99,100,101,102,103,32,104,105,106,90,107,108,109,110,111,112],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":49},"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",[119],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},[98,39,121,122,41,123,103,32,124,125,105,126,127,128,107,35,129],"schema management","MCP","validation","generated","rebuild","contracts","wed","deterministic","mode",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":49},"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",[],[98,137,138,100,101,139,103,32,140,141,142,143,107,144,145,146,147,148,149,150],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":49},"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",[],[98,106,158,100,103,159,160,124,161,140,105,162,163,107,164,165,145,166,110,167],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"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":49},"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",[],[175,176,177,178,103,179,180,181,32,182,183,184,185],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":49},"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",[],[98,193,194,100,101,139,103,159,32,104,140,195,105,142,107,165,145,146,196,112],"capability","capability management","queries","changes"]