[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X29HZR91DDVAE4KA303ABH":3,"skill-same:01M6X29HZR91DDVAE4KA303ABH":92},{"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":65,"commitSha":66,"skillDirectory":67,"forksCount":14,"repositoryHtmlUrl":68,"repositoryHomepageUrl":69,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":71,"install":72,"resources":85},"01M6X29HZR91DDVAE4KA303ABH","session-handover",null,"Write an end-of-session handover LogEntry capturing current state, open threads, next action, and git context for session continuity.","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\u002Fsession-handover\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"session handover","handover","session","query","session continuity","for","v1","with","event","end","project","continuity","current state","document","log","schema","work","wrapup","open","state","2026-11-10 10:12:30",false,"---\nname: session-handover\ndescription: >\n  Write an end-of-session handover LogEntry capturing current state,\n  open threads, next action, and git context for session continuity.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-20260408_0000-SessionHandover\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: processkit\n    layer: 2\n    uses:\n      - skill: event-log\n        purpose: Write the session.handover LogEntry with the structured details schema.\n      - skill: workitem-management\n        purpose: Query in-progress and blocked WorkItems to populate open_threads accurately.\n    commands:\n      - name: pk-wrapup\n        args: \"\"\n        description: \"Generate a session handover document from current project state\"\n---\n\n# Session Handover\n\n## Intro\n\nA session handover is a structured snapshot written at the end of a work\nsession — before a container restarts, a laptop closes, or a context window\nends. It is the primary mechanism for continuity across sessions. The\nhandover is a `session.handover` LogEntry, not a flat Markdown file: it\nlives in `context\u002Flogs\u002F` and is queryable by any downstream skill.\n\n## Overview\n\n### When to write a handover\n\nTwo trigger patterns exist — both are valid:\n\n**Pattern A — container restart \u002F shutdown handover**\nThe user is about to stop the container or close the session and wants the\nnext session to pick up exactly where this one left off. This is the primary\nuse case. The handover may be read days or weeks later.\n\n**Pattern B — regular evening cadence**\nThe user writes a handover at the end of every work session as a habit.\n`status-briefing` reads the most recent handover and weights it by age:\na same-day handover is the primary \"what happened\" source; an old handover\nis context only.\n\nBoth patterns use identical handover content. The difference is only in how\nfrequently the skill is invoked.\n\n### What to capture\n\nWork through these sections before writing the entry:\n\n**1. Current state (2–4 sentences)**\nWhat is the overall state of the project right now? What was the last\nsignificant thing completed? Is the codebase in a clean, broken, or\nin-flight state?\n\n**2. Open threads**\nEvery item that is in-progress, blocked, or needs a decision. Query\n`workitem-management` for `state: in_progress` and `state: blocked` items.\nInclude informal threads that are not yet WorkItems — anything the next\nsession needs to know about.\n\n**3. Next recommended action**\nThe single most important thing the next session should do first. Be\nspecific: not \"continue working\" but \"review the auth PR in BACK-042 —\nit's approved and ready to merge.\"\n\n**4. Git context**\nCurrent branch and commit SHA. If there are uncommitted changes, note them.\nIf there is a stash, note what is in it.\n\n**5. Behavioral retrospective (brief)**\nBefore writing the entry, scan the session for execution gaps:\n\n- What did I commit to (\"I'll track that\", \"I'll file a workitem\")\n  but not execute in the same turn?\n- What did I skip, defer, or forget that should not have been\n  deferred?\n- What surprised me, or what did the user have to correct?\n\nFor each item: either edit the relevant skill or AGENTS.md directly\n(if it is a clear, reusable rule), or create a WorkItem. Do not\nleave it as a mental note — the next session starts with the lessons\nalready encoded only if they are written down before this session\ncloses.\n\n### Writing the LogEntry\n\n**Step 1 — generate the ID:**\n\nUse `generate_id(\"LogEntry\", slug_text=\"session-handover\")` to get\na collision-free ID following the project's configured format, e.g.:\n`LOG-20260410_0020-SnowyEmber-session-handover`\n\n**Step 2 — determine the file path:**\n\nApply date-based sharding (configured in index-management):\n`context\u002Flogs\u002FYYYY\u002FMM\u002F{id}.md`\n\nExample: `context\u002Flogs\u002F2026\u002F04\u002FLOG-20260410_0020-SnowyEmber-session-handover.md`\n\n**Step 3 — write the file:**\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: LogEntry\nmetadata:\n  id: LOG-{{YYYYMMDD_HHMM}}-{{WordPair}}-session-handover\n  created: \u003CISO 8601 UTC>\nspec:\n  event_type: session.handover\n  timestamp: \u003CISO 8601 UTC>\n  actor: \u003CACTOR-id or agent name>\n  summary: \"Session handover — \u003Cone-line summary of session>\"\n  details:\n    session_date: \"\u003CYYYY-MM-DD>\"\n    current_state: |\n      \u003C2-4 sentences on where things stand>\n    open_threads:\n      - \"\u003Citem 1>\"\n      - \"\u003Citem 2>\"\n    next_recommended_action: |\n      \u003Cspecific next step for the next session>\n    branch: \"\u003Ccurrent branch>\"\n    commit: \"\u003Cshort SHA>\"\n    behavioral_retrospective:  # optional; omit if no gaps observed\n      - \"\u003Cobservation + what was encoded or filed>\"\n---\n```\n\n### Trigger phrases\n\nThe agent should write a handover when it hears:\n- \"write a handover\"\n- \"prepare for shutdown\" \u002F \"shutting down\"\n- \"save context\" \u002F \"save state\"\n- \"closing the container\" \u002F \"restarting\"\n- \"end of session\"\n- \"write a session summary\"\n\nThis skill also provides the `\u002Fsession-handover-write` slash command for direct invocation — see `commands\u002Fsession-handover-write.md`.\n\n## Gotchas\n\n- **Writing the handover before work is complete.** The handover should\n  reflect the actual state at the moment of writing — not the intended\n  state. If a task is half-done, say so. The next session needs the truth,\n  not the plan.\n- **Vague current_state.** \"Working on things\" is not a current state.\n  \"BACK-042 auth refactor is merged; BACK-045 is in review and waiting\n  for CI; nothing is broken on main\" is a current state. Be specific\n  enough that someone who wasn't in the session can orient immediately.\n- **Using a flat path or wrong ID format.** The handover file must go\n  in `context\u002Flogs\u002FYYYY\u002FMM\u002F{id}.md` (date-sharded), not flat at\n  `context\u002Flogs\u002F`. The ID must come from `generate_id(\"LogEntry\",\n  slug_text=\"session-handover\")` — not a hand-written slug.\n- **Omitting git context.** The branch and commit are the most mechanical\n  part of the handover and the easiest to forget. Always include them.\n  If there are uncommitted changes, list the files — the next session\n  may be working with a different HEAD.\n- **Forgetting stashes.** A `git stash` is invisible to the next session\n  unless it is noted in the handover. Check `git stash list` before\n  writing the handover.\n- **Listing only completed work instead of open threads.** A handover that\n  only says what was done is a changelog, not a handover. The open threads\n  — what is blocked, in-flight, or undecided — are the most important\n  content for the next session.\n- **next_recommended_action being a list instead of a single action.**\n  The next session needs a clear starting point, not a prioritization\n  problem to solve before any work can begin. Force yourself to pick one.\n  Other items belong in open_threads.\n- **Not querying WorkItem state before writing.** Open threads written from\n  memory miss things. Always query `workitem-management` for in-progress\n  and blocked items before finalizing the open_threads list.\n- **Skipping the behavioral retrospective.** The retrospective is\n  the mechanism that converts session failures into durable\n  improvements. If the session had no corrections, note that\n  explicitly in `behavioral_retrospective`. If corrections happened\n  and are not encoded, the next session agent starts with the same\n  failure modes.\n\n## Full reference\n\n### Relationship to status-briefing\n\n`status-briefing` reads the most recent `session.handover` LogEntry and\nweights it by age:\n\n| Handover age | Weight in status briefing |\n|---|---|\n| \u003C 24 hours | Primary source for \"what happened last session\" |\n| 1–7 days | Secondary source — flagged as stale; git log + WorkItem state carry more weight |\n| > 7 days | Skipped — briefing relies on git log and current WorkItem state only |\n\nThe handover is a best-effort enrichment, not a required source. If no\nhandover exists, `status-briefing` reconstructs context from git log and\nWorkItem state.\n\n### Handover vs. standup\n\n| | session-handover | standup-context |\n|---|---|---|\n| **When** | Before shutdown \u002F container restart | Any time; regular cadence |\n| **Audience** | The next session (same person or agent) | The team \u002F project record |\n| **Focus** | Continuity — what to pick up next | Accountability — what was done |\n| **LogEntry type** | `session.handover` | `session.standup` |\n\n### Reading a prior handover\n\nAt session start, to find the most recent handover:\n\n```\nquery_events(event_type=\"session.handover\", limit=1, order=\"desc\")\n```\n\nCheck `details.session_date` to assess staleness before weighting the\ncontent.\n\n**Before starting any new workstream** identified in the handover,\nquery the skill index for a relevant skill:\n\n```\nsearch_entities(kind=skill, text=\u003Cworkstream-keyword>)\n```\n\nor call `find_skill(\u003Cworkstream-keyword>)`. Do this before acting on\nany item in `open_threads` or `next_recommended_action` — a matching\nskill may exist with processkit-specific conventions that general\nknowledge does not carry.\n","# Session Handover\n\n## Intro\n\nA session handover is a structured snapshot written at the end of a work\nsession — before a container restarts, a laptop closes, or a context window\nends. It is the primary mechanism for continuity across sessions. The\nhandover is a `session.handover` LogEntry, not a flat Markdown file: it\nlives in `context\u002Flogs\u002F` and is queryable by any downstream skill.\n\n## Overview\n\n### When to write a handover\n\nTwo trigger patterns exist — both are valid:\n\n**Pattern A — container restart \u002F shutdown handover**\nThe user is about to stop the container or close the session and wants the\nnext session to pick up exactly where this one left off. This is the primary\nuse case. The handover may be read days or weeks later.\n\n**Pattern B — regular evening cadence**\nThe user writes a handover at the end of every work session as a habit.\n`status-briefing` reads the most recent handover and weights it by age:\na same-day handover is the primary \"what happened\" source; an old handover\nis context only.\n\nBoth patterns use identical handover content. The difference is only in how\nfrequently the skill is invoked.\n\n### What to capture\n\nWork through these sections before writing the entry:\n\n**1. Current state (2–4 sentences)**\nWhat is the overall state of the project right now? What was the last\nsignificant thing completed? Is the codebase in a clean, broken, or\nin-flight state?\n\n**2. Open threads**\nEvery item that is in-progress, blocked, or needs a decision. Query\n`workitem-management` for `state: in_progress` and `state: blocked` items.\nInclude informal threads that are not yet WorkItems — anything the next\nsession needs to know about.\n\n**3. Next recommended action**\nThe single most important thing the next session should do first. Be\nspecific: not \"continue working\" but \"review the auth PR in BACK-042 —\nit's approved and ready to merge.\"\n\n**4. Git context**\nCurrent branch and commit SHA. If there are uncommitted changes, note them.\nIf there is a stash, note what is in it.\n\n**5. Behavioral retrospective (brief)**\nBefore writing the entry, scan the session for execution gaps:\n\n- What did I commit to (\"I'll track that\", \"I'll file a workitem\")\n  but not execute in the same turn?\n- What did I skip, defer, or forget that should not have been\n  deferred?\n- What surprised me, or what did the user have to correct?\n\nFor each item: either edit the relevant skill or AGENTS.md directly\n(if it is a clear, reusable rule), or create a WorkItem. Do not\nleave it as a mental note — the next session starts with the lessons\nalready encoded only if they are written down before this session\ncloses.\n\n### Writing the LogEntry\n\n**Step 1 — generate the ID:**\n\nUse `generate_id(\"LogEntry\", slug_text=\"session-handover\")` to get\na collision-free ID following the project's configured format, e.g.:\n`LOG-20260410_0020-SnowyEmber-session-handover`\n\n**Step 2 — determine the file path:**\n\nApply date-based sharding (configured in index-management):\n`context\u002Flogs\u002FYYYY\u002FMM\u002F{id}.md`\n\nExample: `context\u002Flogs\u002F2026\u002F04\u002FLOG-20260410_0020-SnowyEmber-session-handover.md`\n\n**Step 3 — write the file:**\n\n```yaml\n---\napiVersion: processkit.projectious.work\u002Fv1\nkind: LogEntry\nmetadata:\n  id: LOG-{{YYYYMMDD_HHMM}}-{{WordPair}}-session-handover\n  created: \u003CISO 8601 UTC>\nspec:\n  event_type: session.handover\n  timestamp: \u003CISO 8601 UTC>\n  actor: \u003CACTOR-id or agent name>\n  summary: \"Session handover — \u003Cone-line summary of session>\"\n  details:\n    session_date: \"\u003CYYYY-MM-DD>\"\n    current_state: |\n      \u003C2-4 sentences on where things stand>\n    open_threads:\n      - \"\u003Citem 1>\"\n      - \"\u003Citem 2>\"\n    next_recommended_action: |\n      \u003Cspecific next step for the next session>\n    branch: \"\u003Ccurrent branch>\"\n    commit: \"\u003Cshort SHA>\"\n    behavioral_retrospective:  # optional; omit if no gaps observed\n      - \"\u003Cobservation + what was encoded or filed>\"\n---\n```\n\n### Trigger phrases\n\nThe agent should write a handover when it hears:\n- \"write a handover\"\n- \"prepare for shutdown\" \u002F \"shutting down\"\n- \"save context\" \u002F \"save state\"\n- \"closing the container\" \u002F \"restarting\"\n- \"end of session\"\n- \"write a session summary\"\n\nThis skill also provides the `\u002Fsession-handover-write` slash command for direct invocation — see `commands\u002Fsession-handover-write.md`.\n\n## Gotchas\n\n- **Writing the handover before work is complete.** The handover should\n  reflect the actual state at the moment of writing — not the intended\n  state. If a task is half-done, say so. The next session needs the truth,\n  not the plan.\n- **Vague current_state.** \"Working on things\" is not a current state.\n  \"BACK-042 auth refactor is merged; BACK-045 is in review and waiting\n  for CI; nothing is broken on main\" is a current state. Be specific\n  enough that someone who wasn't in the session can orient immediately.\n- **Using a flat path or wrong ID format.** The handover file must go\n  in `context\u002Flogs\u002FYYYY\u002FMM\u002F{id}.md` (date-sharded), not flat at\n  `context\u002Flogs\u002F`. The ID must come from `generate_id(\"LogEntry\",\n  slug_text=\"session-handover\")` — not a hand-written slug.\n- **Omitting git context.** The branch and commit are the most mechanical\n  part of the handover and the easiest to forget. Always include them.\n  If there are uncommitted changes, list the files — the next session\n  may be working with a different HEAD.\n- **Forgetting stashes.** A `git stash` is invisible to the next session\n  unless it is noted in the handover. Check `git stash list` before\n  writing the handover.\n- **Listing only completed work instead of open threads.** A handover that\n  only says what was done is a changelog, not a handover. The open threads\n  — what is blocked, in-flight, or undecided — are the most important\n  content for the next session.\n- **next_recommended_action being a list instead of a single action.**\n  The next session needs a clear starting point, not a prioritization\n  problem to solve before any work can begin. Force yourself to pick one.\n  Other items belong in open_threads.\n- **Not querying WorkItem state before writing.** Open threads written from\n  memory miss things. Always query `workitem-management` for in-progress\n  and blocked items before finalizing the open_threads list.\n- **Skipping the behavioral retrospective.** The retrospective is\n  the mechanism that converts session failures into durable\n  improvements. If the session had no corrections, note that\n  explicitly in `behavioral_retrospective`. If corrections happened\n  and are not encoded, the next session agent starts with the same\n  failure modes.\n\n## Full reference\n\n### Relationship to status-briefing\n\n`status-briefing` reads the most recent `session.handover` LogEntry and\nweights it by age:\n\n| Handover age | Weight in status briefing |\n|---|---|\n| \u003C 24 hours | Primary source for \"what happened last session\" |\n| 1–7 days | Secondary source — flagged as stale; git log + WorkItem state carry more weight |\n| > 7 days | Skipped — briefing relies on git log and current WorkItem state only |\n\nThe handover is a best-effort enrichment, not a required source. If no\nhandover exists, `status-briefing` reconstructs context from git log and\nWorkItem state.\n\n### Handover vs. standup\n\n| | session-handover | standup-context |\n|---|---|---|\n| **When** | Before shutdown \u002F container restart | Any time; regular cadence |\n| **Audience** | The next session (same person or agent) | The team \u002F project record |\n| **Focus** | Continuity — what to pick up next | Accountability — what was done |\n| **LogEntry type** | `session.handover` | `session.standup` |\n\n### Reading a prior handover\n\nAt session start, to find the most recent handover:\n\n```\nquery_events(event_type=\"session.handover\", limit=1, order=\"desc\")\n```\n\nCheck `details.session_date` to assess staleness before weighting the\ncontent.\n\n**Before starting any new workstream** identified in the handover,\nquery the skill index for a relevant skill:\n\n```\nsearch_entities(kind=skill, text=\u003Cworkstream-keyword>)\n```\n\nor call `find_skill(\u003Cworkstream-keyword>)`. Do this before acting on\nany item in `open_threads` or `next_recommended_action` — a matching\nskill may exist with processkit-specific conventions that general\nknowledge does not carry.\n",{"name":5,"metadata":44,"description":64},{"processkit":45},{"id":46,"uses":47,"layer":54,"created":55,"version":56,"category":57,"commands":58,"apiVersion":63},"SKILL-20260408_0000-SessionHandover",[48,51],{"skill":49,"purpose":50},"event-log","Write the session.handover LogEntry with the structured details schema.",{"skill":52,"purpose":53},"workitem-management","Query in-progress and blocked WorkItems to populate open_threads accurately.",2,1775606400000,"1.0.0","processkit",[59],{"args":60,"name":61,"description":62},"","pk-wrapup","Generate a session handover document from current project state","processkit.projectious.work\u002Fv1","Write an end-of-session handover LogEntry capturing current state, open threads, next action, and git context for session continuity.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fsession-handover","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":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add projectious-work\u002Fprocesskit --skill session-handover",{"tool":78,"command":79},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill session-handover",{"tool":81,"command":82},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill session-handover","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fsession-handover\u002FSKILL.md",true,[86],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"commands\u002Fpk-wrapup.md","REFERENCE","参考文档",125,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fsession-handover\u002Fcommands\u002Fpk-wrapup.md",[93,119,138,156,173,190],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":104,"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",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[105,106,107,108,109,110,35,111,112,113,95,114,115,116,25,117,118],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"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",[125],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},[105,34,127,128,129,130,110,35,131,132,112,133,134,135,114,136,137],"schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"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",[],[105,145,146,107,108,147,110,35,33,148,149,22,114,150,27,151,152,153,154,155],"proposition","proposition management","index","world","record","creation","interface","updates","facts","claims","WSJF",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"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",[],[105,113,163,107,110,164,165,131,166,33,112,167,168,114,169,170,27,171,25,172],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"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",[],[180,181,182,183,110,37,184,185,35,186,187,188,189],"okf","compatibility","okf compatibility","validate","knowledge","format","export","bundles","bundle","import",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"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",[],[105,197,198,107,108,147,110,164,35,111,33,199,112,149,114,170,27,151,200,118],"capability","capability management","queries","changes"]