[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0AZSDM847GVBBTFND868Z":3,"skill-same:01M6X0AZSDM847GVBBTFND868Z":82},{"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":61,"commitSha":62,"skillDirectory":63,"forksCount":14,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M6X0AZSDM847GVBBTFND868Z","cross-reference-management",null,"Conventions and helpers for lightweight relationships between entities expressed as frontmatter references (not first-class Binding entities). Use when linking two entities with a simple, unscoped, untemporal relationship — 'this work item blocks that one', 'this decision relates to that work item'. For scoped\u002Ftemporal relationships, use binding-management instead.","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\u002Fprocesskit\u002Fcross-reference-management\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"management","reference","cross reference management","keep","work item","when","audit trail","scoped","for","v1","with","event","decision","as","relationship","references","simple","log","use","work","2026-11-10 10:12:30",false,"---\nname: cross-reference-management\ndescription: |\n  Conventions and helpers for lightweight relationships between entities expressed as frontmatter references (not first-class Binding entities). Use when linking two entities with a simple, unscoped, untemporal relationship — 'this work item blocks that one', 'this decision relates to that work item'. For scoped\u002Ftemporal relationships, use binding-management instead.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-cross-reference-management\n    version: \"1.0.0\"\n    created: 2026-04-06T00:00:00Z\n    category: processkit\n    layer: 2\n    uses:\n      - skill: event-log\n        purpose: Log events to keep the audit trail accurate after every write.\n    provides:\n      primitives: [CrossReference]\n      templates: []\n---\n\n# Cross-Reference Management\n\n## Intro\n\nA CrossReference is a lightweight typed link between two entities, expressed\nas a field in the subject's frontmatter rather than as its own file. It is\nthe right choice for simple, unscoped, permanent relationships — \"A blocks\nB\", \"decision X is related to work item Y\". When a relationship needs scope,\ntime, or its own attributes, use a Binding instead.\n\n## Overview\n\n### CrossReference is not a file\n\nUnlike every other primitive, CrossReference does not get its own file.\nIt is a **convention for frontmatter fields** — a typed list of pointers.\n\n```yaml\n# In a WorkItem's frontmatter:\nspec:\n  blocks: [BACK-swift-oak]\n  blocked_by: [BACK-calm-fox]\n  related_decisions: [DEC-023]\n```\n\nEach field name encodes the relationship type. The *fields* vary per primitive;\nthe *convention* is shared.\n\n### Conventional cross-reference field names\n\n| Field               | Meaning                                             |\n|---------------------|-----------------------------------------------------|\n| `parent`            | This entity is a child of another                   |\n| `children`          | This entity has sub-items                           |\n| `blocks`            | This entity blocks others until resolved            |\n| `blocked_by`        | This entity is blocked by others                    |\n| `related`           | Generic \"see also\" — use only when no better field fits |\n| `related_workitems` | Typed relationship specifically to WorkItems        |\n| `related_decisions` | Typed relationship specifically to DecisionRecords  |\n| `supersedes`        | This entity replaces an older one                   |\n| `superseded_by`     | This entity has been replaced by a newer one        |\n| `implements`        | This entity implements something (e.g. a decision)  |\n| `motivates`         | This entity motivated another (e.g. bug → decision) |\n\n### Workflow\n\n1. Pick the field that best fits the relationship. Prefer specific over generic.\n2. Add the target ID(s) to that field in the subject's frontmatter.\n3. For bidirectional relationships (`blocks` ↔ `blocked_by`), update both sides.\n4. Log `workitem.linked` (or similar) with `details.relation` + `details.target`.\n\n### Cross-reference vs Binding\n\n| Situation                                           | Use         |\n|-----------------------------------------------------|-------------|\n| \"A blocks B\"                                        | cross-ref   |\n| \"A is related to B\"                                 | cross-ref   |\n| \"A is the parent of B\"                              | cross-ref   |\n| \"A fills role R in scope S for time T\"              | **Binding** |\n| \"A applies to B only on main branch\"                | **Binding** |\n| \"A and B are linked AND the link has its own metadata\" | **Binding** |\n\nIf the link has its own properties worth querying, it's a Binding. Otherwise,\nit's a cross-reference.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Using a cross-reference when scope or time matters.** If the\n  relationship is \"Alice owns this for sprint 42\" or \"this gate\n  applies on main only\", that's a Binding, not a cross-reference.\n  Cross-references can't carry temporal validity or scoping —\n  reaching for one when you need a Binding silently loses the\n  qualification.\n- **Forgetting to add the inverse side of an asymmetric pair.**\n  `blocks` \u002F `blocked_by`, `parent` \u002F `children`, `supersedes` \u002F\n  `superseded_by` are all bidirectional. If you set one side\n  without setting the other, the index ends up with a broken\n  half-edge. Always set both.\n- **Cross-referencing a non-existent entity ID.** A typo in a\n  reference (`BACK-1234` vs `BACK-12345`) silently breaks\n  navigation and produces a dangling edge. Verify the target\n  exists via `index-management.get_entity` before writing the\n  reference.\n- **Treating cross-references as authoritative state.** A\n  cross-reference is metadata about a relationship; the\n  authoritative state lives on the entity itself. If a workitem's\n  `parent` says it's part of an epic but the epic's `children`\n  doesn't include it, the parent reference is wrong, not the\n  epic.\n- **Cross-referencing aggressively just because you can.** Every\n  cross-reference is graph clutter for queries. Reserve them for\n  relationships a future agent or human will actually need to\n  navigate, not for \"these two things vaguely relate\".\n- **Adding cross-references to entities you don't own the schema\n  for.** If you're tempted to put a custom field on a primitive's\n  frontmatter, consider whether it belongs in `metadata.tags` or\n  in a Binding instead. Schema drift across primitives breaks\n  validation.\n- **Confusing cross-references with discussions\u002Fdecisions.** A\n  cross-reference says \"these are related\"; it does not capture\n  WHY. If the why matters, write a Discussion or DecisionRecord\n  and cross-reference THAT, not the underlying entities directly.\n\n## Full reference\n\n### Bidirectional integrity\n\nSome cross-references are inherently bidirectional (`blocks`\u002F`blocked_by`,\n`parent`\u002F`children`, `supersedes`\u002F`superseded_by`). Agents should update\nboth sides when adding or removing. The index MCP server (Phase 3) will\nsurface one-sided references as lint warnings.\n\n### Typed vs generic `related`\n\nPrefer typed fields (`related_decisions`, `related_workitems`) over the\ngeneric `related` — they make queries and rendering much cleaner. Only fall\nback to `related` when there is no natural typed field.\n\n### Field naming convention\n\nCross-reference field names are lowercase snake_case, use plural form for\nlists, and describe the relationship from the subject's perspective. \"A\nblocks B\" is expressed as `blocks: [B]` on A, not `blocker_of: [B]`.\n\n### Resolving a cross-reference\n\nTo find all entities that reference X:\n- By field scan: grep all frontmatter for X's ID appearing in any list.\n- Via index MCP server: `query(target=X)` returns all cross-references\n  across all entity kinds.\n\n### Migration to Binding\n\nIf a cross-reference grows attributes over time (\"this block has a reason\nand an expiry date\"), migrate to a Binding:\n\n1. Create a Binding with `type: blocking`, `subject: A`, `target: B`, plus\n   the new attributes.\n2. Remove the cross-reference field from A.\n3. Log `workitem.link.migrated`.\n\nThis is the only case where removing a cross-reference is routine; normally\nyou keep them forever.\n","# Cross-Reference Management\n\n## Intro\n\nA CrossReference is a lightweight typed link between two entities, expressed\nas a field in the subject's frontmatter rather than as its own file. It is\nthe right choice for simple, unscoped, permanent relationships — \"A blocks\nB\", \"decision X is related to work item Y\". When a relationship needs scope,\ntime, or its own attributes, use a Binding instead.\n\n## Overview\n\n### CrossReference is not a file\n\nUnlike every other primitive, CrossReference does not get its own file.\nIt is a **convention for frontmatter fields** — a typed list of pointers.\n\n```yaml\n# In a WorkItem's frontmatter:\nspec:\n  blocks: [BACK-swift-oak]\n  blocked_by: [BACK-calm-fox]\n  related_decisions: [DEC-023]\n```\n\nEach field name encodes the relationship type. The *fields* vary per primitive;\nthe *convention* is shared.\n\n### Conventional cross-reference field names\n\n| Field               | Meaning                                             |\n|---------------------|-----------------------------------------------------|\n| `parent`            | This entity is a child of another                   |\n| `children`          | This entity has sub-items                           |\n| `blocks`            | This entity blocks others until resolved            |\n| `blocked_by`        | This entity is blocked by others                    |\n| `related`           | Generic \"see also\" — use only when no better field fits |\n| `related_workitems` | Typed relationship specifically to WorkItems        |\n| `related_decisions` | Typed relationship specifically to DecisionRecords  |\n| `supersedes`        | This entity replaces an older one                   |\n| `superseded_by`     | This entity has been replaced by a newer one        |\n| `implements`        | This entity implements something (e.g. a decision)  |\n| `motivates`         | This entity motivated another (e.g. bug → decision) |\n\n### Workflow\n\n1. Pick the field that best fits the relationship. Prefer specific over generic.\n2. Add the target ID(s) to that field in the subject's frontmatter.\n3. For bidirectional relationships (`blocks` ↔ `blocked_by`), update both sides.\n4. Log `workitem.linked` (or similar) with `details.relation` + `details.target`.\n\n### Cross-reference vs Binding\n\n| Situation                                           | Use         |\n|-----------------------------------------------------|-------------|\n| \"A blocks B\"                                        | cross-ref   |\n| \"A is related to B\"                                 | cross-ref   |\n| \"A is the parent of B\"                              | cross-ref   |\n| \"A fills role R in scope S for time T\"              | **Binding** |\n| \"A applies to B only on main branch\"                | **Binding** |\n| \"A and B are linked AND the link has its own metadata\" | **Binding** |\n\nIf the link has its own properties worth querying, it's a Binding. Otherwise,\nit's a cross-reference.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Using a cross-reference when scope or time matters.** If the\n  relationship is \"Alice owns this for sprint 42\" or \"this gate\n  applies on main only\", that's a Binding, not a cross-reference.\n  Cross-references can't carry temporal validity or scoping —\n  reaching for one when you need a Binding silently loses the\n  qualification.\n- **Forgetting to add the inverse side of an asymmetric pair.**\n  `blocks` \u002F `blocked_by`, `parent` \u002F `children`, `supersedes` \u002F\n  `superseded_by` are all bidirectional. If you set one side\n  without setting the other, the index ends up with a broken\n  half-edge. Always set both.\n- **Cross-referencing a non-existent entity ID.** A typo in a\n  reference (`BACK-1234` vs `BACK-12345`) silently breaks\n  navigation and produces a dangling edge. Verify the target\n  exists via `index-management.get_entity` before writing the\n  reference.\n- **Treating cross-references as authoritative state.** A\n  cross-reference is metadata about a relationship; the\n  authoritative state lives on the entity itself. If a workitem's\n  `parent` says it's part of an epic but the epic's `children`\n  doesn't include it, the parent reference is wrong, not the\n  epic.\n- **Cross-referencing aggressively just because you can.** Every\n  cross-reference is graph clutter for queries. Reserve them for\n  relationships a future agent or human will actually need to\n  navigate, not for \"these two things vaguely relate\".\n- **Adding cross-references to entities you don't own the schema\n  for.** If you're tempted to put a custom field on a primitive's\n  frontmatter, consider whether it belongs in `metadata.tags` or\n  in a Binding instead. Schema drift across primitives breaks\n  validation.\n- **Confusing cross-references with discussions\u002Fdecisions.** A\n  cross-reference says \"these are related\"; it does not capture\n  WHY. If the why matters, write a Discussion or DecisionRecord\n  and cross-reference THAT, not the underlying entities directly.\n\n## Full reference\n\n### Bidirectional integrity\n\nSome cross-references are inherently bidirectional (`blocks`\u002F`blocked_by`,\n`parent`\u002F`children`, `supersedes`\u002F`superseded_by`). Agents should update\nboth sides when adding or removing. The index MCP server (Phase 3) will\nsurface one-sided references as lint warnings.\n\n### Typed vs generic `related`\n\nPrefer typed fields (`related_decisions`, `related_workitems`) over the\ngeneric `related` — they make queries and rendering much cleaner. Only fall\nback to `related` when there is no natural typed field.\n\n### Field naming convention\n\nCross-reference field names are lowercase snake_case, use plural form for\nlists, and describe the relationship from the subject's perspective. \"A\nblocks B\" is expressed as `blocks: [B]` on A, not `blocker_of: [B]`.\n\n### Resolving a cross-reference\n\nTo find all entities that reference X:\n- By field scan: grep all frontmatter for X's ID appearing in any list.\n- Via index MCP server: `query(target=X)` returns all cross-references\n  across all entity kinds.\n\n### Migration to Binding\n\nIf a cross-reference grows attributes over time (\"this block has a reason\nand an expiry date\"), migrate to a Binding:\n\n1. Create a Binding with `type: blocking`, `subject: A`, `target: B`, plus\n   the new attributes.\n2. Remove the cross-reference field from A.\n3. Log `workitem.link.migrated`.\n\nThis is the only case where removing a cross-reference is routine; normally\nyou keep them forever.\n",{"name":5,"metadata":44,"description":60},{"processkit":45},{"id":46,"uses":47,"layer":51,"created":52,"version":53,"category":54,"provides":55,"apiVersion":59},"SKILL-cross-reference-management",[48],{"skill":49,"purpose":50},"event-log","Log events to keep the audit trail accurate after every write.",2,1775433600000,"1.0.0","processkit",{"templates":56,"primitives":57},[],[58],"CrossReference","processkit.projectious.work\u002Fv1","Conventions and helpers for lightweight relationships between entities expressed as frontmatter references (not first-class Binding entities). Use when linking two entities with a simple, unscoped, untemporal relationship — 'this work item blocks that one', 'this decision relates to that work item'. For scoped\u002Ftemporal relationships, use binding-management instead.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcross-reference-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":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add projectious-work\u002Fprocesskit --skill cross-reference-management",{"tool":74,"command":75},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill cross-reference-management",{"tool":77,"command":78},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill cross-reference-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcross-reference-management\u002FSKILL.md",true,[],[83,107,127,146,162,180],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":94,"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",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[19,95,96,97,98,99,38,100,101,102,85,103,32,104,28,105,106],"skill management","create","update","package","alpha","list","manage","ontology","get","manifests","skill package","transition",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"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",[113],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[19,115,116,117,118,119,99,38,120,121,101,122,123,124,103,125,126],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"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",[],[19,134,135,96,97,136,99,38,36,137,138,139,103,140,30,141,142,143,144,145],"proposition","proposition management","index","world","record","query","creation","interface","updates","facts","claims","WSJF",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"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",[],[19,102,153,96,99,154,155,120,156,36,101,157,158,103,159,22,30,160,28,161],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","measurement","generic",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"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",[],[169,170,171,172,99,173,174,175,38,176,177,178,179],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"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":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",[],[19,187,188,96,97,136,99,154,38,100,36,189,101,138,103,22,30,141,190,106],"capability","capability management","queries","changes"]