[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X2CK3S9G2P7NK6FPFP50BY":3,"skill-same:01M6X2CK3S9G2P7NK6FPFP50BY":81},{"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":60,"commitSha":61,"skillDirectory":62,"forksCount":14,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":66,"install":67,"resources":80},"01M6X2CK3S9G2P7NK6FPFP50BY","status-update-writer",null,"Generates clear, structured status updates for stakeholders — from project context, backlog state, or a brief description of recent work. Use when asked to write a status update, weekly report, progress summary, or team briefing about a project or initiative.","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.23.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstatus-update-writer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"status","status update writer","writer","update","query","when","workitem","weekly","updates","briefing","progress","project","priorities","brief","wed","status updates","context","write","work","team","2026-11-10 10:12:30",false,"---\nname: status-update-writer\ndescription: |\n  Generates clear, structured status updates for stakeholders — from project context, backlog state, or a brief description of recent work. Use when asked to write a status update, weekly report, progress summary, or team briefing about a project or initiative.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-status-update-writer\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: processkit\n    layer: 4\n    uses:\n      - skill: workitem-management\n        purpose: Query current workitem state and priorities to populate the update accurately.\n      - skill: agent-management\n        purpose: Extract recent session context when generating periodic updates.\n---\n\n# Status Update Writer\n\n## Intro\n\nA status update answers three questions for someone who hasn't been\nin the room: what happened, what comes next, and what (if anything)\nneeds their attention. Write it at the audience's level of detail —\nan executive wants headline + blockers; a team wants specifics.\nSource from actual project state, not from memory.\n\n## Overview\n\n### Source the data first\n\nBefore writing anything, read the project state:\n\n```\n# If in a processkit project:\ncontext\u002FBACKLOG.md      # in-progress and next items\ncontext\u002FSTANDUPS.md     # last 1-2 entries\ncontext\u002FHANDOVER.md     # most recent session summary\n\n# From git:\ngit log --oneline -10   # recent commits\ngit diff --stat HEAD~3  # what changed in the last few commits\n```\n\nIf the update is for a non-processkit project, ask the user to\nprovide recent output, commits, or notes.\n\n### Choose the format for the audience\n\n| Audience | Format | Length | Key emphasis |\n|---|---|---|---|\n| **Executive \u002F leadership** | Headline + bullets | ½ page | Status, blockers, decisions needed |\n| **Team \u002F peers** | Section-per-area | 1 page | Work done, in-progress, next steps |\n| **Stakeholder brief** | Narrative + table | 1-2 pages | Context, progress, risks, timeline |\n| **Stand-up (async)** | 3-line Done\u002FNext\u002FBlockers | 3-5 lines | Brevity — one line per item |\n\nDefault to the team format unless the audience is specified.\n\n### Executive \u002F leadership format\n\n```markdown\n## [Project] Status — [Date]\n\n**Overall:** ? On track \u002F ? At risk \u002F ? Blocked\n\n**This week:**\n- [Completed milestone or delivered item]\n- [Second key outcome]\n\n**Next week:**\n- [Next milestone with expected completion]\n\n**Needs your attention:**\n- [Decision or unblock required, with deadline]\n```\n\nUse ?\u002F?\u002F? (or \"On track \u002F At risk \u002F Blocked\" in plain text).\nLead with status before detail — executives read left-to-right and\nstop as soon as they know whether to be concerned.\n\n### Team \u002F peer format\n\n```markdown\n## [Project] Update — [Date or Sprint N]\n\n### Done\n- [Completed items, linked to tickets or PRs where applicable]\n- [Each item on its own line]\n\n### In Progress\n- [What is being actively worked, with owner and estimated completion]\n\n### Blocked \u002F At Risk\n- [Blocker description] — **owner:** [name], **needs:** [what unblocks it]\n\n### Next Up\n- [Upcoming work, in priority order]\n\n### Metrics (if applicable)\n- [Key number] — [interpretation] (was [prior value])\n```\n\nLink to specific tickets, commits, or docs wherever possible —\nreaders should be able to drill down without asking follow-up\nquestions.\n\n### Stakeholder brief (longer form)\n\n```markdown\n## [Project] — [Phase\u002FQuarter] Status Brief\n\n**Executive summary:** [2-3 sentence narrative — what we set out to\ndo, where we are, what the outlook is]\n\n### Progress against plan\n\n| Milestone | Target | Status | Notes |\n|---|---|---|---|\n| [M1] | [Date] | ✅ Complete | |\n| [M2] | [Date] | ? In progress | ETA [Date] |\n| [M3] | [Date] | ⏳ Not started | |\n\n### Key accomplishments this period\n- [Specific, measurable outcome]\n\n### Risks and mitigations\n| Risk | Likelihood | Impact | Mitigation |\n|---|---|---|---|\n| [Risk] | Medium | High | [Action] |\n\n### Decisions needed\n- [Decision] — **due by:** [Date], **owner:** [Name]\n\n### Next period plan\n- [Major focus areas and expected outcomes]\n```\n\n### Calibrating length and detail\n\nThe right update is the shortest one that gives the reader everything\nthey need to make decisions or stay confident. Rules of thumb:\n\n- **One status per item.** Never say \"we're making progress on X, Y,\n  and Z.\" Tell them where each stands.\n- **Blockers need owners and deadlines.** \"We're blocked on infra\" is\n  useless. \"We're waiting on firewall rule approval from IT; Jake is\n  following up by Thursday\" is actionable.\n- **Numbers over adjectives.** \"Good progress\" means nothing;\n  \"shipped 3 of the 5 planned features\" means something.\n- **Lead with changes, not constants.** If something hasn't moved,\n  keep it in one line — readers don't need to re-read stable facts.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Writing from memory instead of reading the actual project state.** A status update that contradicts the backlog or misses completed work is worse than no update. Always read `context\u002FBACKLOG.md`, recent git log, or the last handover note before writing. Never synthesize from recall alone.\n- **Reporting activity instead of outcomes.** \"We held three meetings and reviewed the architecture\" describes effort; \"We finalized the data model and unblocked the API team\" describes outcome. Status updates are for outcomes — what changed, what was delivered, what moved.\n- **Omitting blockers to avoid delivering bad news.** A status update without blockers implies everything is on track. Silently omitting a blocker delays the moment when it can be resolved. Report blockers with owner, impact, and what would unblock them — that's what stakeholders need to help.\n- **Using the same format for every audience.** An executive update with 40 bullets loses the reader; a 3-line async standup for a stakeholder brief leaves them confused about project health. Always ask \"who will read this and what do they need to decide or know?\" before choosing the format.\n- **Using vague status signals.** \"In progress\" on every item provides no information. Distinguish: \"on track to complete by [date]\", \"at risk — depends on [X]\", \"blocked since [date] by [reason]\". The reader should be able to tell whether to be concerned without reading the body.\n- **Not including the decision or action needed.** A status update that describes problems without stating what the reader should do creates anxiety without resolution. Every risk or blocker in the update must include who owns it and what action would help.\n- **Writing updates in first person plural without specifying owners.** \"We will finalize the contract by Thursday\" creates no accountability. Name the person: \"Alice will finalize the contract by Thursday.\" Stakeholders reading updates need to know who to follow up with.\n\n## Full reference\n\n### Pulling data from processkit primitives\n\nWhen running inside a processkit project with the index MCP server:\n\n```python\n# Get in-progress items\nquery_entities(kind=\"WorkItem\", state=\"in_progress\")\n\n# Get recent log entries\nquery_entities(kind=\"LogEntry\", limit=10)\n\n# Get open decisions\nquery_entities(kind=\"DecisionRecord\", state=\"open\")\n```\n\nUse these queries to populate the \"In Progress\", \"Done (this week)\",\nand \"Decisions needed\" sections with accurate data.\n\n### Cadence templates\n\n**Weekly update (team):** Every Friday, source from the week's commits\nand the current backlog. Send by end of day. Archive the prior week's\nupdate in `context\u002Farchive\u002Fstatus-updates\u002F`.\n\n**Sprint review:** At the end of each sprint, compare committed items\nagainst delivered items and explain any gap.\n\n**Quarterly briefing:** Pull the quarter's highlights from the\narchived weekly updates + log entries. Summarize three things:\nwhat we shipped, what we learned, what we're doing next quarter.\n\n### Status emoji guide (for teams using emoji status)\n\n| Symbol | Meaning |\n|---|---|\n| ✅ | Complete — shipped and verified |\n| ? | In progress — actively being worked |\n| ⏳ | Not started — planned but not yet begun |\n| ? | At risk — on track but a dependency is uncertain |\n| ? | Blocked — cannot proceed without external action |\n| ❌ | Cancelled \u002F removed from scope |\n","# Status Update Writer\n\n## Intro\n\nA status update answers three questions for someone who hasn't been\nin the room: what happened, what comes next, and what (if anything)\nneeds their attention. Write it at the audience's level of detail —\nan executive wants headline + blockers; a team wants specifics.\nSource from actual project state, not from memory.\n\n## Overview\n\n### Source the data first\n\nBefore writing anything, read the project state:\n\n```\n# If in a processkit project:\ncontext\u002FBACKLOG.md      # in-progress and next items\ncontext\u002FSTANDUPS.md     # last 1-2 entries\ncontext\u002FHANDOVER.md     # most recent session summary\n\n# From git:\ngit log --oneline -10   # recent commits\ngit diff --stat HEAD~3  # what changed in the last few commits\n```\n\nIf the update is for a non-processkit project, ask the user to\nprovide recent output, commits, or notes.\n\n### Choose the format for the audience\n\n| Audience | Format | Length | Key emphasis |\n|---|---|---|---|\n| **Executive \u002F leadership** | Headline + bullets | ½ page | Status, blockers, decisions needed |\n| **Team \u002F peers** | Section-per-area | 1 page | Work done, in-progress, next steps |\n| **Stakeholder brief** | Narrative + table | 1-2 pages | Context, progress, risks, timeline |\n| **Stand-up (async)** | 3-line Done\u002FNext\u002FBlockers | 3-5 lines | Brevity — one line per item |\n\nDefault to the team format unless the audience is specified.\n\n### Executive \u002F leadership format\n\n```markdown\n## [Project] Status — [Date]\n\n**Overall:** ? On track \u002F ? At risk \u002F ? Blocked\n\n**This week:**\n- [Completed milestone or delivered item]\n- [Second key outcome]\n\n**Next week:**\n- [Next milestone with expected completion]\n\n**Needs your attention:**\n- [Decision or unblock required, with deadline]\n```\n\nUse ?\u002F?\u002F? (or \"On track \u002F At risk \u002F Blocked\" in plain text).\nLead with status before detail — executives read left-to-right and\nstop as soon as they know whether to be concerned.\n\n### Team \u002F peer format\n\n```markdown\n## [Project] Update — [Date or Sprint N]\n\n### Done\n- [Completed items, linked to tickets or PRs where applicable]\n- [Each item on its own line]\n\n### In Progress\n- [What is being actively worked, with owner and estimated completion]\n\n### Blocked \u002F At Risk\n- [Blocker description] — **owner:** [name], **needs:** [what unblocks it]\n\n### Next Up\n- [Upcoming work, in priority order]\n\n### Metrics (if applicable)\n- [Key number] — [interpretation] (was [prior value])\n```\n\nLink to specific tickets, commits, or docs wherever possible —\nreaders should be able to drill down without asking follow-up\nquestions.\n\n### Stakeholder brief (longer form)\n\n```markdown\n## [Project] — [Phase\u002FQuarter] Status Brief\n\n**Executive summary:** [2-3 sentence narrative — what we set out to\ndo, where we are, what the outlook is]\n\n### Progress against plan\n\n| Milestone | Target | Status | Notes |\n|---|---|---|---|\n| [M1] | [Date] | ✅ Complete | |\n| [M2] | [Date] | ? In progress | ETA [Date] |\n| [M3] | [Date] | ⏳ Not started | |\n\n### Key accomplishments this period\n- [Specific, measurable outcome]\n\n### Risks and mitigations\n| Risk | Likelihood | Impact | Mitigation |\n|---|---|---|---|\n| [Risk] | Medium | High | [Action] |\n\n### Decisions needed\n- [Decision] — **due by:** [Date], **owner:** [Name]\n\n### Next period plan\n- [Major focus areas and expected outcomes]\n```\n\n### Calibrating length and detail\n\nThe right update is the shortest one that gives the reader everything\nthey need to make decisions or stay confident. Rules of thumb:\n\n- **One status per item.** Never say \"we're making progress on X, Y,\n  and Z.\" Tell them where each stands.\n- **Blockers need owners and deadlines.** \"We're blocked on infra\" is\n  useless. \"We're waiting on firewall rule approval from IT; Jake is\n  following up by Thursday\" is actionable.\n- **Numbers over adjectives.** \"Good progress\" means nothing;\n  \"shipped 3 of the 5 planned features\" means something.\n- **Lead with changes, not constants.** If something hasn't moved,\n  keep it in one line — readers don't need to re-read stable facts.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Writing from memory instead of reading the actual project state.** A status update that contradicts the backlog or misses completed work is worse than no update. Always read `context\u002FBACKLOG.md`, recent git log, or the last handover note before writing. Never synthesize from recall alone.\n- **Reporting activity instead of outcomes.** \"We held three meetings and reviewed the architecture\" describes effort; \"We finalized the data model and unblocked the API team\" describes outcome. Status updates are for outcomes — what changed, what was delivered, what moved.\n- **Omitting blockers to avoid delivering bad news.** A status update without blockers implies everything is on track. Silently omitting a blocker delays the moment when it can be resolved. Report blockers with owner, impact, and what would unblock them — that's what stakeholders need to help.\n- **Using the same format for every audience.** An executive update with 40 bullets loses the reader; a 3-line async standup for a stakeholder brief leaves them confused about project health. Always ask \"who will read this and what do they need to decide or know?\" before choosing the format.\n- **Using vague status signals.** \"In progress\" on every item provides no information. Distinguish: \"on track to complete by [date]\", \"at risk — depends on [X]\", \"blocked since [date] by [reason]\". The reader should be able to tell whether to be concerned without reading the body.\n- **Not including the decision or action needed.** A status update that describes problems without stating what the reader should do creates anxiety without resolution. Every risk or blocker in the update must include who owns it and what action would help.\n- **Writing updates in first person plural without specifying owners.** \"We will finalize the contract by Thursday\" creates no accountability. Name the person: \"Alice will finalize the contract by Thursday.\" Stakeholders reading updates need to know who to follow up with.\n\n## Full reference\n\n### Pulling data from processkit primitives\n\nWhen running inside a processkit project with the index MCP server:\n\n```python\n# Get in-progress items\nquery_entities(kind=\"WorkItem\", state=\"in_progress\")\n\n# Get recent log entries\nquery_entities(kind=\"LogEntry\", limit=10)\n\n# Get open decisions\nquery_entities(kind=\"DecisionRecord\", state=\"open\")\n```\n\nUse these queries to populate the \"In Progress\", \"Done (this week)\",\nand \"Decisions needed\" sections with accurate data.\n\n### Cadence templates\n\n**Weekly update (team):** Every Friday, source from the week's commits\nand the current backlog. Send by end of day. Archive the prior week's\nupdate in `context\u002Farchive\u002Fstatus-updates\u002F`.\n\n**Sprint review:** At the end of each sprint, compare committed items\nagainst delivered items and explain any gap.\n\n**Quarterly briefing:** Pull the quarter's highlights from the\narchived weekly updates + log entries. Summarize three things:\nwhat we shipped, what we learned, what we're doing next quarter.\n\n### Status emoji guide (for teams using emoji status)\n\n| Symbol | Meaning |\n|---|---|\n| ✅ | Complete — shipped and verified |\n| ? | In progress — actively being worked |\n| ⏳ | Not started — planned but not yet begun |\n| ? | At risk — on track but a dependency is uncertain |\n| ? | Blocked — cannot proceed without external action |\n| ❌ | Cancelled \u002F removed from scope |\n",{"name":5,"metadata":44,"description":59},{"processkit":45},{"id":46,"uses":47,"layer":54,"created":55,"version":56,"category":57,"apiVersion":58},"SKILL-status-update-writer",[48,51],{"skill":49,"purpose":50},"workitem-management","Query current workitem state and priorities to populate the update accurately.",{"skill":52,"purpose":53},"agent-management","Extract recent session context when generating periodic updates.",4,1775606400000,"1.0.0","processkit","processkit.projectious.work\u002Fv1","Generates clear, structured status updates for stakeholders — from project context, backlog state, or a brief description of recent work. Use when asked to write a status update, weekly report, progress summary, or team briefing about a project or initiative.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstatus-update-writer","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":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add projectious-work\u002Fprocesskit --skill status-update-writer",{"tool":73,"command":74},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill status-update-writer",{"tool":76,"command":77},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill status-update-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fstatus-update-writer\u002FSKILL.md",true,[],[82,108,127,146,163,181],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"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",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[94,95,96,22,97,98,37,99,100,101,84,102,103,104,105,106,107],"management","skill management","create","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"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",[114],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[94,116,117,118,119,120,98,37,121,122,100,123,33,124,102,125,126],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","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",[],[94,134,135,96,22,136,98,37,137,138,139,23,102,140,141,142,27,143,144,145],"proposition","proposition management","index","log","world","record","creation","event","interface","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",[],[94,101,153,96,98,154,155,121,156,137,100,157,158,102,159,160,141,161,105,162],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"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":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",[],[170,171,172,173,98,174,175,176,37,177,178,179,180],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"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",[],[94,188,189,96,22,136,98,154,37,99,137,190,100,139,102,160,141,142,191,107],"capability","capability management","queries","changes"]