[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WX6FWMMB5H4JSCE2413G9N":3,"skill-same:01M6WX6FWMMB5H4JSCE2413G9N":102},{"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":75,"commitSha":76,"skillDirectory":77,"forksCount":14,"repositoryHtmlUrl":78,"repositoryHomepageUrl":79,"ownerHtmlUrl":80,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":81,"install":82,"resources":95},"01M6WX6FWMMB5H4JSCE2413G9N","migration-management",null,"Manage Migration entities — pending, in-progress, and applied transitions between upstream source versions. Use when an upstream source bumps version (processkit, aibox, a community package), when a user wants to draft a migration plan, when an agent needs to reason about pending migrations, or when working through an in-progress migration.","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.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmigration-management\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"migration management","management","migration","community","when","audit trail","source","event","events","progress","fresh","query","workflow","log","write","work","decision","plan","sqlite","audit","2026-11-10 10:12:30",false,"---\nname: migration-management\ndescription: |\n  Manage Migration entities — pending, in-progress, and applied transitions between upstream source versions. Use when an upstream source bumps version (processkit, aibox, a community package), when a user wants to draft a migration plan, when an agent needs to reason about pending migrations, or when working through an in-progress migration.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-migration-management\n    version: \"1.0.0\"\n    created: 2026-04-07T00:00:00Z\n    category: processkit\n    layer: 3\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n      - skill: decision-record\n        purpose: Record consequential decisions made during this skill's workflow.\n      - skill: index-management\n        purpose: Query existing entities and keep the SQLite index fresh after writes.\n      - skill: id-management\n        purpose: Allocate unique entity identifiers via central ID generation.\n    provides:\n      primitives: [Migration]\n      templates: [migration]\n---\n\n# Migration Management\n\n## Intro\n\nA Migration is processkit's first-class representation of an upstream version\nbump. When `aibox sync` notices a new processkit (or aibox, or community\npackage) version, it writes a Migration entity into `context\u002Fmigrations\u002Fpending\u002F`.\nThe agent and the user work through it together over one or more sessions —\ndrafting a plan, applying changes, then archiving the result. This skill is\nhow the agent navigates that lifecycle.\n\n## Overview\n\n### The migration directory layout\n\n```\ncontext\u002Fmigrations\u002F\n├── INDEX.md                    ← always-loaded summary of all migrations\n│\n├── pending\u002F                    ← briefings waiting for human review\n│   └── MIG-\u003Cid>.md\n│\n├── in-progress\u002F                ← migrations being worked on\n│   └── MIG-\u003Cid>.md\n│\n└── applied\u002F                    ← completed migrations (historical record)\n    └── MIG-\u003Cid>.md\n```\n\nThe directory the file lives in **mirrors** the entity's `spec.state`. Moving\nthe file is part of the state transition — `transition_migration` does both\nthe file move and the spec update atomically.\n\n### The lifecycle\n\n```\n                ┌──────────────┐\n                │   pending    │ ← aibox sync writes new migrations here\n                └──────┬───────┘\n                       │ user reviews briefing, approves a plan\n                       ▼\n                ┌──────────────┐\n                │ in-progress  │ ← agent works through plan, updates progress_notes\n                └──────┬───────┘\n                       │ all plan items done, user accepts\n                       ▼\n                ┌──────────────┐\n                │   applied    │ ← terminal, kept as history\n                └──────────────┘\n\n      Either pending or in-progress can transition to `rejected`\n      (terminal side branch — \"we looked at this and decided not to take it\")\n```\n\n### Always-loaded INDEX.md\n\n`context\u002Fmigrations\u002FINDEX.md` is a small file the agent loads at session start.\nIt summarizes every migration's state and the next action. Update it whenever\nyou transition a migration. Sample shape:\n\n```markdown\n# Migrations Index\n\n## Pending (2)\n\n- **MIG-bright-owl** — processkit v0.3.0 → v0.4.0 (generated 2026-04-15)\n  4 affected skills, 2 affected processes, 8 new entities, 1 removal\n- **MIG-calm-river** — aibox 0.14.4 → 0.15.0 (generated 2026-04-12)\n\n## In progress (1)\n\n- **MIG-quick-hawk** — processkit v0.2.0 → v0.3.0 (started 2026-04-08)\n  Plan: 6 items, 4 done. Next: migrate workitem-management overrides.\n\n## Applied (4)\n\n| Date       | Migration                                |\n|------------|------------------------------------------|\n| 2026-04-15 | MIG-... — processkit v0.1.0 → v0.2.0     |\n| 2026-03-20 | MIG-... — aibox 0.13.0 → 0.14.0          |\n```\n\n### Workflow when starting a session\n\n1. Read `context\u002Fmigrations\u002FINDEX.md` — get the migration state at a glance.\n2. If anything is in `pending\u002F` and the user hasn't asked about something\n   else, surface it: \"There's a pending migration MIG-bright-owl from\n   processkit v0.3.0 to v0.4.0. Do you want to review it now?\"\n3. If anything is in `in-progress\u002F`, surface it: \"We're 4\u002F6 of the way\n   through MIG-quick-hawk. Want to continue?\"\n4. Otherwise proceed with the user's request.\n\n### Workflow for a pending migration\n\n1. **Read the briefing** — open the file in `pending\u002F`. The body has a\n   summary, list of affected files (with classification), new additions,\n   removals.\n2. **Draft a plan** — propose a project-specific migration plan to the\n   user. Keep it small: each item is one concrete action (\"update the\n   release process to call the new gate\", \"rename `foo` references in\n   our overrides\", etc.). Prefer many small items over a few big ones.\n3. **Get approval** — show the plan, ask for explicit approval. Do NOT\n   start changing files until approved.\n4. **Transition** — when approved, set `spec.state: in-progress`, set\n   `spec.plan: \u003Capproved plan>`, and **move the file** from `pending\u002F`\n   to `in-progress\u002F`.\n5. **Update INDEX.md**.\n\n### Workflow for an in-progress migration\n\n1. Read `spec.plan` and `spec.progress_notes` — figure out where you are.\n2. Pick the next plan item, do the work, get user confirmation per item\n   if non-trivial.\n3. Append a `progress_note` to `spec.progress_notes` after each completed\n   item — date, actor, what was done.\n4. When all items are done, ask the user to accept. On acceptance:\n   - Set `spec.state: applied`, set `spec.applied_at` and `spec.applied_by`\n   - Move the file from `in-progress\u002F` to `applied\u002F`\n   - Update INDEX.md\n   - Optionally write a `LogEntry` (`event_type: migration.applied`)\n\n### Rejecting a migration\n\nIf the user decides not to take an upstream change:\n- Set `spec.state: rejected`, `spec.rejected_reason: \"...\"`\n- Move the file from `pending\u002F` (or `in-progress\u002F`) to `applied\u002F`\n  (rejected migrations live in `applied\u002F` because that's their terminal home —\n  \"applied\" here means \"decision finalized\", not \"code applied\")\n- Future `aibox sync` runs see this migration in `applied\u002F` and do NOT\n  re-propose the same transition.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Drafting a Migration without a rollback plan.** Every Migration\n  must answer \"what happens if this fails halfway through\". A\n  Migration without rollback is a one-way door — and one-way\n  doors deserve much more scrutiny than the typical Migration\n  flow allows. State the rollback explicitly even when it's\n  \"manual restore from backup\".\n- **Running a Migration without a dry-run pass.** Always preview\n  the changes before applying. A dry-run that shows the diff\n  surfaces typos, ordering issues, and unintended scope before\n  they hit the live tree.\n- **Forgetting to log `migration.applied` (and `migration.failed`).**\n  The audit trail is how the next Migration knows where the last\n  one stopped. Skipping the log strands future maintainers.\n- **Sequencing dependent Migrations wrong.** If Migration B\n  assumes the state Migration A produced, applying B before A is\n  guaranteed corruption. Use the `depends_on` field and verify\n  the dependency graph before scheduling.\n- **Migration markers without actual diffs.** Don't create a\n  Migration entity for \"fix the thing\" if there's no concrete\n  before\u002Fafter state. Migrations are records of mechanical\n  transitions, not aspirational notes.\n- **Treating \"no-op migrations\" as harmless.** A Migration that\n  does nothing should not exist — delete it. Otherwise it\n  pollutes the audit trail with phantom transitions.\n- **Editing an applied Migration after the fact.** Migrations are\n  immutable history. If the Migration was wrong, write a NEW\n  Migration that corrects it (`migration.corrected`), don't\n  rewrite the old one.\n\n## Full reference\n\n### Migration entity shape\n\nSee `src\u002Fprimitives\u002Fschemas\u002Fmigration.yaml` for the authoritative schema.\nFrequently-used fields:\n\n| Field | Type | Notes |\n|---|---|---|\n| `source` | string | `aibox`, `processkit`, `processkit-acme`, ... |\n| `from_version` | string | semver tag |\n| `to_version` | string | semver tag |\n| `state` | enum | `pending` \u002F `in-progress` \u002F `applied` \u002F `rejected` |\n| `summary` | string | one-line for INDEX.md |\n| `affected_files` | list[object] | path + classification per file |\n| `affected_groups` | list[string] | logical groups touched |\n| `plan` | string | the approved migration plan (markdown) |\n| `progress_notes` | list[object] | append-only progress log |\n\n### The five file classifications\n\n| Classification | Meaning |\n|---|---|\n| `changed-upstream-only` | Upstream changed it, the user has not touched it. Safe to take the new version with one approval. |\n| `changed-locally-only` | The user has edited it, upstream is unchanged. No-op for this migration — but worth flagging that the file diverges. |\n| `conflict` | Both have changed. Must be resolved by hand (or by agent + user). Highest priority. |\n| `new-upstream` | Upstream added a new file. Decide whether to take it. |\n| `removed-upstream` | Upstream removed a file the project still uses. Decide whether to remove locally or keep as a project-local fork. |\n\n### Why migrations are entities, not just markdown files\n\nThree reasons:\n1. **Queryable.** The `index-management` MCP server indexes them. An agent can\n   ask \"what migrations are pending?\" without filesystem walking.\n2. **State machine validation.** Transitions are validated by the migration\n   state machine — you cannot accidentally move a file from `applied\u002F` back\n   to `pending\u002F`.\n3. **Cross-referenceable.** A `WorkItem` can reference a `Migration`\n   (`spec.related_migrations: [MIG-bright-owl]`), so if a migration spawns\n   work, the agent can find the linkage. Same for `DecisionRecord`.\n\n### Interaction with PROVENANCE.toml\n\nWhen `aibox sync` generates a Migration, it diffs the `PROVENANCE.toml` files\nof the old and new upstream versions. This gives the change set without having\nto walk every file. The diff script (`scripts\u002Fprocesskit-diff.sh`) is the\ncanonical implementation; aibox calls it (or reimplements its logic in Rust)\nduring sync.\n\n### Interaction with the upstream reference templates\n\nThe project's `context\u002Ftemplates\u002Fprocesskit\u002F\u003Cversion>\u002F` directory holds\na verbatim copy of every file shipped by the pinned processkit release\n(installed by `aibox init`, refreshed by `aibox sync`). The migration's\n`affected_files` classification is computed by comparing three SHAs\non the fly:\n\n- **template SHA** — read from\n  `context\u002Ftemplates\u002Fprocesskit\u002F\u003Cversion>\u002F\u003Cfile>` (the as-installed\n  reference)\n- **cache SHA** — what upstream NOW says (from aibox's runtime cache,\n  fetched from the pinned processkit tag)\n- **live SHA** — what's in the project right now\n\nThree SHAs → five classifications. See the migration generation logic\nin `aibox sync` for the truth table. The pinned source URL + version +\nresolved commit live in `aibox.lock` at the project root (Cargo-style),\nnot in a separate manifest file.\n\n### What this skill does NOT do (yet, in v0.4.0)\n\n- **Generate** migrations — that's `aibox sync`'s job.\n- **Apply file changes** — the agent does the actual edits as part of\n  walking the plan. This skill describes the workflow but doesn't ship a\n  tool that auto-edits.\n- **MCP server** — none yet. v0.4.0 is markdown-only. A future release may\n  add an MCP server with tools like `transition_migration`,\n  `add_progress_note`, `query_migrations` (the index-management MCP server\n  already supports the last via `query_entities(kind=\"Migration\")`).\n","# Migration Management\n\n## Intro\n\nA Migration is processkit's first-class representation of an upstream version\nbump. When `aibox sync` notices a new processkit (or aibox, or community\npackage) version, it writes a Migration entity into `context\u002Fmigrations\u002Fpending\u002F`.\nThe agent and the user work through it together over one or more sessions —\ndrafting a plan, applying changes, then archiving the result. This skill is\nhow the agent navigates that lifecycle.\n\n## Overview\n\n### The migration directory layout\n\n```\ncontext\u002Fmigrations\u002F\n├── INDEX.md                    ← always-loaded summary of all migrations\n│\n├── pending\u002F                    ← briefings waiting for human review\n│   └── MIG-\u003Cid>.md\n│\n├── in-progress\u002F                ← migrations being worked on\n│   └── MIG-\u003Cid>.md\n│\n└── applied\u002F                    ← completed migrations (historical record)\n    └── MIG-\u003Cid>.md\n```\n\nThe directory the file lives in **mirrors** the entity's `spec.state`. Moving\nthe file is part of the state transition — `transition_migration` does both\nthe file move and the spec update atomically.\n\n### The lifecycle\n\n```\n                ┌──────────────┐\n                │   pending    │ ← aibox sync writes new migrations here\n                └──────┬───────┘\n                       │ user reviews briefing, approves a plan\n                       ▼\n                ┌──────────────┐\n                │ in-progress  │ ← agent works through plan, updates progress_notes\n                └──────┬───────┘\n                       │ all plan items done, user accepts\n                       ▼\n                ┌──────────────┐\n                │   applied    │ ← terminal, kept as history\n                └──────────────┘\n\n      Either pending or in-progress can transition to `rejected`\n      (terminal side branch — \"we looked at this and decided not to take it\")\n```\n\n### Always-loaded INDEX.md\n\n`context\u002Fmigrations\u002FINDEX.md` is a small file the agent loads at session start.\nIt summarizes every migration's state and the next action. Update it whenever\nyou transition a migration. Sample shape:\n\n```markdown\n# Migrations Index\n\n## Pending (2)\n\n- **MIG-bright-owl** — processkit v0.3.0 → v0.4.0 (generated 2026-04-15)\n  4 affected skills, 2 affected processes, 8 new entities, 1 removal\n- **MIG-calm-river** — aibox 0.14.4 → 0.15.0 (generated 2026-04-12)\n\n## In progress (1)\n\n- **MIG-quick-hawk** — processkit v0.2.0 → v0.3.0 (started 2026-04-08)\n  Plan: 6 items, 4 done. Next: migrate workitem-management overrides.\n\n## Applied (4)\n\n| Date       | Migration                                |\n|------------|------------------------------------------|\n| 2026-04-15 | MIG-... — processkit v0.1.0 → v0.2.0     |\n| 2026-03-20 | MIG-... — aibox 0.13.0 → 0.14.0          |\n```\n\n### Workflow when starting a session\n\n1. Read `context\u002Fmigrations\u002FINDEX.md` — get the migration state at a glance.\n2. If anything is in `pending\u002F` and the user hasn't asked about something\n   else, surface it: \"There's a pending migration MIG-bright-owl from\n   processkit v0.3.0 to v0.4.0. Do you want to review it now?\"\n3. If anything is in `in-progress\u002F`, surface it: \"We're 4\u002F6 of the way\n   through MIG-quick-hawk. Want to continue?\"\n4. Otherwise proceed with the user's request.\n\n### Workflow for a pending migration\n\n1. **Read the briefing** — open the file in `pending\u002F`. The body has a\n   summary, list of affected files (with classification), new additions,\n   removals.\n2. **Draft a plan** — propose a project-specific migration plan to the\n   user. Keep it small: each item is one concrete action (\"update the\n   release process to call the new gate\", \"rename `foo` references in\n   our overrides\", etc.). Prefer many small items over a few big ones.\n3. **Get approval** — show the plan, ask for explicit approval. Do NOT\n   start changing files until approved.\n4. **Transition** — when approved, set `spec.state: in-progress`, set\n   `spec.plan: \u003Capproved plan>`, and **move the file** from `pending\u002F`\n   to `in-progress\u002F`.\n5. **Update INDEX.md**.\n\n### Workflow for an in-progress migration\n\n1. Read `spec.plan` and `spec.progress_notes` — figure out where you are.\n2. Pick the next plan item, do the work, get user confirmation per item\n   if non-trivial.\n3. Append a `progress_note` to `spec.progress_notes` after each completed\n   item — date, actor, what was done.\n4. When all items are done, ask the user to accept. On acceptance:\n   - Set `spec.state: applied`, set `spec.applied_at` and `spec.applied_by`\n   - Move the file from `in-progress\u002F` to `applied\u002F`\n   - Update INDEX.md\n   - Optionally write a `LogEntry` (`event_type: migration.applied`)\n\n### Rejecting a migration\n\nIf the user decides not to take an upstream change:\n- Set `spec.state: rejected`, `spec.rejected_reason: \"...\"`\n- Move the file from `pending\u002F` (or `in-progress\u002F`) to `applied\u002F`\n  (rejected migrations live in `applied\u002F` because that's their terminal home —\n  \"applied\" here means \"decision finalized\", not \"code applied\")\n- Future `aibox sync` runs see this migration in `applied\u002F` and do NOT\n  re-propose the same transition.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Drafting a Migration without a rollback plan.** Every Migration\n  must answer \"what happens if this fails halfway through\". A\n  Migration without rollback is a one-way door — and one-way\n  doors deserve much more scrutiny than the typical Migration\n  flow allows. State the rollback explicitly even when it's\n  \"manual restore from backup\".\n- **Running a Migration without a dry-run pass.** Always preview\n  the changes before applying. A dry-run that shows the diff\n  surfaces typos, ordering issues, and unintended scope before\n  they hit the live tree.\n- **Forgetting to log `migration.applied` (and `migration.failed`).**\n  The audit trail is how the next Migration knows where the last\n  one stopped. Skipping the log strands future maintainers.\n- **Sequencing dependent Migrations wrong.** If Migration B\n  assumes the state Migration A produced, applying B before A is\n  guaranteed corruption. Use the `depends_on` field and verify\n  the dependency graph before scheduling.\n- **Migration markers without actual diffs.** Don't create a\n  Migration entity for \"fix the thing\" if there's no concrete\n  before\u002Fafter state. Migrations are records of mechanical\n  transitions, not aspirational notes.\n- **Treating \"no-op migrations\" as harmless.** A Migration that\n  does nothing should not exist — delete it. Otherwise it\n  pollutes the audit trail with phantom transitions.\n- **Editing an applied Migration after the fact.** Migrations are\n  immutable history. If the Migration was wrong, write a NEW\n  Migration that corrects it (`migration.corrected`), don't\n  rewrite the old one.\n\n## Full reference\n\n### Migration entity shape\n\nSee `src\u002Fprimitives\u002Fschemas\u002Fmigration.yaml` for the authoritative schema.\nFrequently-used fields:\n\n| Field | Type | Notes |\n|---|---|---|\n| `source` | string | `aibox`, `processkit`, `processkit-acme`, ... |\n| `from_version` | string | semver tag |\n| `to_version` | string | semver tag |\n| `state` | enum | `pending` \u002F `in-progress` \u002F `applied` \u002F `rejected` |\n| `summary` | string | one-line for INDEX.md |\n| `affected_files` | list[object] | path + classification per file |\n| `affected_groups` | list[string] | logical groups touched |\n| `plan` | string | the approved migration plan (markdown) |\n| `progress_notes` | list[object] | append-only progress log |\n\n### The five file classifications\n\n| Classification | Meaning |\n|---|---|\n| `changed-upstream-only` | Upstream changed it, the user has not touched it. Safe to take the new version with one approval. |\n| `changed-locally-only` | The user has edited it, upstream is unchanged. No-op for this migration — but worth flagging that the file diverges. |\n| `conflict` | Both have changed. Must be resolved by hand (or by agent + user). Highest priority. |\n| `new-upstream` | Upstream added a new file. Decide whether to take it. |\n| `removed-upstream` | Upstream removed a file the project still uses. Decide whether to remove locally or keep as a project-local fork. |\n\n### Why migrations are entities, not just markdown files\n\nThree reasons:\n1. **Queryable.** The `index-management` MCP server indexes them. An agent can\n   ask \"what migrations are pending?\" without filesystem walking.\n2. **State machine validation.** Transitions are validated by the migration\n   state machine — you cannot accidentally move a file from `applied\u002F` back\n   to `pending\u002F`.\n3. **Cross-referenceable.** A `WorkItem` can reference a `Migration`\n   (`spec.related_migrations: [MIG-bright-owl]`), so if a migration spawns\n   work, the agent can find the linkage. Same for `DecisionRecord`.\n\n### Interaction with PROVENANCE.toml\n\nWhen `aibox sync` generates a Migration, it diffs the `PROVENANCE.toml` files\nof the old and new upstream versions. This gives the change set without having\nto walk every file. The diff script (`scripts\u002Fprocesskit-diff.sh`) is the\ncanonical implementation; aibox calls it (or reimplements its logic in Rust)\nduring sync.\n\n### Interaction with the upstream reference templates\n\nThe project's `context\u002Ftemplates\u002Fprocesskit\u002F\u003Cversion>\u002F` directory holds\na verbatim copy of every file shipped by the pinned processkit release\n(installed by `aibox init`, refreshed by `aibox sync`). The migration's\n`affected_files` classification is computed by comparing three SHAs\non the fly:\n\n- **template SHA** — read from\n  `context\u002Ftemplates\u002Fprocesskit\u002F\u003Cversion>\u002F\u003Cfile>` (the as-installed\n  reference)\n- **cache SHA** — what upstream NOW says (from aibox's runtime cache,\n  fetched from the pinned processkit tag)\n- **live SHA** — what's in the project right now\n\nThree SHAs → five classifications. See the migration generation logic\nin `aibox sync` for the truth table. The pinned source URL + version +\nresolved commit live in `aibox.lock` at the project root (Cargo-style),\nnot in a separate manifest file.\n\n### What this skill does NOT do (yet, in v0.4.0)\n\n- **Generate** migrations — that's `aibox sync`'s job.\n- **Apply file changes** — the agent does the actual edits as part of\n  walking the plan. This skill describes the workflow but doesn't ship a\n  tool that auto-edits.\n- **MCP server** — none yet. v0.4.0 is markdown-only. A future release may\n  add an MCP server with tools like `transition_migration`,\n  `add_progress_note`, `query_migrations` (the index-management MCP server\n  already supports the last via `query_entities(kind=\"Migration\")`).\n",{"name":5,"metadata":49,"description":74},{"processkit":50},{"id":51,"uses":52,"layer":65,"created":66,"version":67,"category":68,"provides":69,"apiVersion":73},"SKILL-migration-management",[53,56,59,62],{"skill":54,"purpose":55},"event-log","Log events to keep the audit trail accurate after every write.",{"skill":57,"purpose":58},"decision-record","Record consequential decisions made during this skill's workflow.",{"skill":60,"purpose":61},"index-management","Query existing entities and keep the SQLite index fresh after writes.",{"skill":63,"purpose":64},"id-management","Allocate unique entity identifiers via central ID generation.",3,1775520000000,"1.0.0","processkit",{"templates":70,"primitives":71},[26],[72],"Migration","processkit.projectious.work\u002Fv1","Manage Migration entities — pending, in-progress, and applied transitions between upstream source versions. Use when an upstream source bumps version (processkit, aibox, a community package), when a user wants to draft a migration plan, when an agent needs to reason about pending migrations, or when working through an in-progress migration.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmigration-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":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add projectious-work\u002Fprocesskit --skill migration-management",{"tool":88,"command":89},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill migration-management",{"tool":91,"command":92},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill migration-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmigration-management\u002FSKILL.md",true,[96],{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"assets\u002Fmigration.yaml","ASSET","资产文件",1149,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.10.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmigration-management\u002Fassets\u002Fmigration.yaml",[103,125,145,163,180,198],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"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",[109],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,111,112,113,114,115,39,116,117,118,105,119,120,121,122,123,124],"skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"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",[131],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,133,134,135,136,137,115,39,138,139,117,140,141,142,119,143,144],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"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",[],[25,152,153,112,113,154,115,39,37,155,156,35,119,157,31,158,159,160,161,162],"proposition","proposition management","index","world","record","creation","interface","updates","facts","claims","WSJF",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"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",[],[25,118,170,112,115,171,172,138,173,37,117,174,175,119,176,177,31,178,122,179],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"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",[],[187,188,189,190,115,191,192,193,39,194,195,196,197],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"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",[],[25,205,206,112,113,154,115,171,39,116,37,207,117,156,119,177,31,158,208,124],"capability","capability management","queries","changes"]