[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZQ17QAX7MSYNMAWMED901":3,"skill-same:01M6WZQ17QAX7MSYNMAWMED901":95},{"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":68,"commitSha":69,"skillDirectory":70,"forksCount":14,"repositoryHtmlUrl":71,"repositoryHomepageUrl":72,"ownerHtmlUrl":73,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":74,"install":75,"resources":88},"01M6WZQ17QAX7MSYNMAWMED901","morning-briefing",null,"Generates a concise daily briefing from project context — synthesizing current state, open decisions, key risks, and today's priority actions into a focused session-start orientation. Use at the start of a session when asked for a briefing, \"what's the state of things\", \"catch me up\", or \"what should I focus on today.\"","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.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmorning-briefing\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"briefing","morning","morning briefing","query","when","catch","session start","progress","project","focus","next","me","workitem","writer","files","up","work","open","actions","generate","2026-11-10 10:12:30",false,"---\nname: morning-briefing\ndescription: |\n  Generates a concise daily briefing from project context — synthesizing current state, open decisions, key risks, and today's priority actions into a focused session-start orientation. Use at the start of a session when asked for a briefing, \"what's the state of things\", \"catch me up\", or \"what should I focus on today.\"\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-morning-briefing\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: processkit\n    layer: 2\n    uses:\n      - skill: agent-management\n        purpose: Understand what context files to read at session start (HANDOVER, BACKLOG, INDEX).\n      - skill: status-update-writer\n        purpose: Pull current project state when generating the today's priorities section.\n      - skill: workitem-management\n        purpose: Query in-progress and next-up WorkItems for the today's priorities section.\n    commands:\n      - name: morning-briefing-generate\n        args: \"\"\n        description: \"Generate a session-start orientation from current project state\"\n---\n\n# Morning Briefing\n\n## Intro\n\nA morning briefing is a single-screen orientation that a person or\nagent reads at the start of a session to immediately know what\nmatters today. It distills project context, backlog state, open\ndecisions, and upcoming deadlines into a focused, actionable\nsummary. The reader should be ready to start working within three\nminutes of reading it.\n\n## Overview\n\n### Sources to read before generating\n\nPull from these sources in order, weighting by freshness:\n\n```\n1. session.handover LogEntry  — most recent; weight by age (see below)\n2. WorkItems (in_progress + blocked)  — current state via workitem-management\n3. session.standup LogEntries — last 1-3 entries since last handover\n4. git log --oneline -5       — recent commits\n5. DecisionRecords (proposed) — open decisions needing attention\n6. Any time-sensitive flags   — deadlines, blockers, scheduled events\n```\n\n**Handover staleness rule** — before using the most recent `session.handover`\nentry, check `details.session_date` and weight accordingly:\n\n| Handover age | How to use it |\n|---|---|\n| \u003C 24 hours | Primary source for \"what happened last session\" and \"open threads\" |\n| 1–7 days | Secondary source — include content but flag as stale in the briefing |\n| > 7 days | Skip — reconstruct from git log and WorkItem state only; note absence |\n\nThe two-pattern reality: some users write handovers every session (the\nhandover will usually be \u003C 24h old); others write handovers only on\ncontainer restart (may be days old). The staleness rule handles both without\nthe user configuring anything.\n\n### The briefing format\n\n```markdown\n# Morning Briefing — [Date]\n\n## State of play\n\n[1-3 sentences on overall project health and phase. Honest —\n\"on track\", \"at risk on [milestone]\", or \"blocked on [dependency]\".]\n\n## What happened since last session\n\n- [Completed item or change]\n- [Completed item or change]\n(If nothing happened: \"No sessions since [date]. Project state unchanged.\")\n\n## Today's priorities\n\n1. **[Top priority item]** — [why it's first, what done looks like]\n2. **[Second priority]** — [brief context]\n3. **[Third priority]** — [brief context]\n\n## Open decisions\n\n- [Decision X] — owner: [name], due by: [date or \"unscheduled\"]\n- [Decision Y] — [brief description]\n\n## Blockers and risks\n\n- [Blocker] — waiting on: [person\u002Fthing], impact: [what it blocks]\n- [Risk] — likelihood: [H\u002FM\u002FL], mitigation: [action]\n\n## Upcoming deadlines\n\n- [Deadline] — [date, days from now]\n\n## One-liner to carry\n\n> [A single sentence that captures the most important thing to keep\n> in mind today — the guiding constraint or the single metric to move]\n```\n\nOmit sections that have nothing to report. A briefing with three\nwell-chosen items is better than a padded briefing with eight items\nof equal apparent importance.\n\n### Calibrating for session type\n\n**First session of the day (human):** full format including upcoming\ndeadlines and open decisions.\n\n**Agent session start:** focus on state of play + today's priorities.\nSkip open decisions unless the agent needs to make them.\n\n**After a long break (>1 week):** add a \"Context refresh\" section\nsummarizing anything structural that changed (architecture, team,\nconstraints) and note the date of the last active session.\n\n**Sprint start \u002F milestone start:** add a \"Sprint goal\" or \"Milestone\ntarget\" section above priorities, so the briefing orients to the\nbigger shape of the period.\n\n### The \"one-liner to carry\"\n\nThe most important output of a good morning briefing is the single\nsentence the reader holds in their head all day. It captures the\ndominant constraint or priority for the session:\n\nGood examples:\n- \"Get the data pipeline unblocked before anything else — it's the\n  critical path for the Friday demo.\"\n- \"The authentication refactor is the only thing on the critical path;\n  don't start anything new.\"\n- \"Scope is the binding constraint today — question every addition.\"\n- \"The milestone is tomorrow: ship something working, perfect later.\"\n\nBad examples (too vague):\n- \"Keep up the good work.\" (not actionable)\n- \"Focus on quality.\" (not specific to today's situation)\n\nIf you cannot write a specific one-liner for today, the briefing\nitself is probably too generic.\n\nThis skill also provides the `\u002Fmorning-briefing-generate` slash command for direct invocation — see `commands\u002Fmorning-briefing-generate.md`.\n\n### Keeping it short\n\nA morning briefing that takes more than 3 minutes to read has failed.\nLength signals:\n- **Too long:** more than 2 items per section, or more than 5 sections\n- **Too short:** misses an active blocker or an imminent deadline\n- **Right length:** one readable screen, skimmable in 90 seconds\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Treating a stale handover as current.** A `session.handover` written 10 days ago reflects a state that may have completely changed. Always check `details.session_date` before using a handover as a source. If it is more than 7 days old, skip it and reconstruct from git log and WorkItem state instead. Presenting stale handover content as \"what happened last session\" when the last session was a week ago misleads the user.\n- **Reading only the handover note without checking WorkItem state.** The handover captures what was true at session end; WorkItem state shows what has been actively changed since. A briefing that contradicts current WorkItem state (e.g., listing an item as \"next up\" when it is now done) will erode trust immediately. Always cross-check both.\n- **Listing everything instead of prioritizing.** A briefing that reports all 12 open workitems is not a briefing — it's a dump. The value of a morning briefing is triage: surface the 3 things that matter today, not an inventory of everything that exists. If in doubt about what to prioritize, ask — do not pad.\n- **Making the \"state of play\" section too optimistic.** Briefings written by the agent often smooth over problems to avoid delivering bad news. If the project is blocked, at risk, or behind, the state of play must say so clearly — not \"making good progress with a few items to resolve.\" The user is about to spend their session on this; accurate state matters.\n- **Not including a one-liner.** The \"one-liner to carry\" section is the hardest to write and the most valuable. Skipping it produces a briefing that reports status without providing orientation. Every briefing must end with one sentence that captures the dominant constraint or priority for the session.\n- **Generating a briefing without reading the current context.** A briefing from memory or from context loaded in a prior session may be stale. Always read HANDOVER.md and BACKLOG.md (or query the live index) before generating. A briefing that reflects last week's state is misleading.\n- **Writing the briefing in a format that requires careful reading instead of scanning.** Morning briefings are consumed at session start, often under time pressure. Use short bullets, bold key terms, and scannable structure. A briefing written as flowing prose that requires careful reading defeats the purpose.\n- **Reporting blockers without their resolution path.** \"Blocked on API key from vendor\" is incomplete. \"Blocked on API key from vendor — Sarah requested it Tuesday, expected by Thursday\" is actionable. Every blocker must include: who owns it, what action is in progress, and when it's expected to resolve.\n\n## Full reference\n\n### When the project has no processkit context\n\nIf the project does not use processkit (no BACKLOG.md, no HANDOVER.md),\nask the user to provide:\n- What was worked on last session\n- What is in progress right now\n- What deadlines exist in the next 1-2 weeks\n- Any blockers\n\nThen generate the briefing from those answers using the same format.\n\n### Archiving briefings\n\nBriefings are ephemeral by design. Do not archive them unless the\nuser requests it. The handover note is the persistent record;\nthe morning briefing is a generated view of it.\n\n### Integration with event-log\n\nThe `event-log` skill records session activity as log entries.\n`morning-briefing` reads recent entries (plus HANDOVER and WorkItem\nstate) and synthesizes them into an actionable briefing. event-log\nis the write path; morning-briefing is the read path.\n\n### Briefing cadence\n\n- **Daily work:** generate at the start of each session\n- **After a weekend:** use the extended format (>1 week gap)\n- **Project kickoff:** generate a \"kickoff briefing\" from the\n  PRD \u002F scope docs instead of HANDOVER + BACKLOG\n- **Post-incident:** lead with incident status, then resume normal\n  briefing format once the incident is resolved\n","# Morning Briefing\n\n## Intro\n\nA morning briefing is a single-screen orientation that a person or\nagent reads at the start of a session to immediately know what\nmatters today. It distills project context, backlog state, open\ndecisions, and upcoming deadlines into a focused, actionable\nsummary. The reader should be ready to start working within three\nminutes of reading it.\n\n## Overview\n\n### Sources to read before generating\n\nPull from these sources in order, weighting by freshness:\n\n```\n1. session.handover LogEntry  — most recent; weight by age (see below)\n2. WorkItems (in_progress + blocked)  — current state via workitem-management\n3. session.standup LogEntries — last 1-3 entries since last handover\n4. git log --oneline -5       — recent commits\n5. DecisionRecords (proposed) — open decisions needing attention\n6. Any time-sensitive flags   — deadlines, blockers, scheduled events\n```\n\n**Handover staleness rule** — before using the most recent `session.handover`\nentry, check `details.session_date` and weight accordingly:\n\n| Handover age | How to use it |\n|---|---|\n| \u003C 24 hours | Primary source for \"what happened last session\" and \"open threads\" |\n| 1–7 days | Secondary source — include content but flag as stale in the briefing |\n| > 7 days | Skip — reconstruct from git log and WorkItem state only; note absence |\n\nThe two-pattern reality: some users write handovers every session (the\nhandover will usually be \u003C 24h old); others write handovers only on\ncontainer restart (may be days old). The staleness rule handles both without\nthe user configuring anything.\n\n### The briefing format\n\n```markdown\n# Morning Briefing — [Date]\n\n## State of play\n\n[1-3 sentences on overall project health and phase. Honest —\n\"on track\", \"at risk on [milestone]\", or \"blocked on [dependency]\".]\n\n## What happened since last session\n\n- [Completed item or change]\n- [Completed item or change]\n(If nothing happened: \"No sessions since [date]. Project state unchanged.\")\n\n## Today's priorities\n\n1. **[Top priority item]** — [why it's first, what done looks like]\n2. **[Second priority]** — [brief context]\n3. **[Third priority]** — [brief context]\n\n## Open decisions\n\n- [Decision X] — owner: [name], due by: [date or \"unscheduled\"]\n- [Decision Y] — [brief description]\n\n## Blockers and risks\n\n- [Blocker] — waiting on: [person\u002Fthing], impact: [what it blocks]\n- [Risk] — likelihood: [H\u002FM\u002FL], mitigation: [action]\n\n## Upcoming deadlines\n\n- [Deadline] — [date, days from now]\n\n## One-liner to carry\n\n> [A single sentence that captures the most important thing to keep\n> in mind today — the guiding constraint or the single metric to move]\n```\n\nOmit sections that have nothing to report. A briefing with three\nwell-chosen items is better than a padded briefing with eight items\nof equal apparent importance.\n\n### Calibrating for session type\n\n**First session of the day (human):** full format including upcoming\ndeadlines and open decisions.\n\n**Agent session start:** focus on state of play + today's priorities.\nSkip open decisions unless the agent needs to make them.\n\n**After a long break (>1 week):** add a \"Context refresh\" section\nsummarizing anything structural that changed (architecture, team,\nconstraints) and note the date of the last active session.\n\n**Sprint start \u002F milestone start:** add a \"Sprint goal\" or \"Milestone\ntarget\" section above priorities, so the briefing orients to the\nbigger shape of the period.\n\n### The \"one-liner to carry\"\n\nThe most important output of a good morning briefing is the single\nsentence the reader holds in their head all day. It captures the\ndominant constraint or priority for the session:\n\nGood examples:\n- \"Get the data pipeline unblocked before anything else — it's the\n  critical path for the Friday demo.\"\n- \"The authentication refactor is the only thing on the critical path;\n  don't start anything new.\"\n- \"Scope is the binding constraint today — question every addition.\"\n- \"The milestone is tomorrow: ship something working, perfect later.\"\n\nBad examples (too vague):\n- \"Keep up the good work.\" (not actionable)\n- \"Focus on quality.\" (not specific to today's situation)\n\nIf you cannot write a specific one-liner for today, the briefing\nitself is probably too generic.\n\nThis skill also provides the `\u002Fmorning-briefing-generate` slash command for direct invocation — see `commands\u002Fmorning-briefing-generate.md`.\n\n### Keeping it short\n\nA morning briefing that takes more than 3 minutes to read has failed.\nLength signals:\n- **Too long:** more than 2 items per section, or more than 5 sections\n- **Too short:** misses an active blocker or an imminent deadline\n- **Right length:** one readable screen, skimmable in 90 seconds\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Treating a stale handover as current.** A `session.handover` written 10 days ago reflects a state that may have completely changed. Always check `details.session_date` before using a handover as a source. If it is more than 7 days old, skip it and reconstruct from git log and WorkItem state instead. Presenting stale handover content as \"what happened last session\" when the last session was a week ago misleads the user.\n- **Reading only the handover note without checking WorkItem state.** The handover captures what was true at session end; WorkItem state shows what has been actively changed since. A briefing that contradicts current WorkItem state (e.g., listing an item as \"next up\" when it is now done) will erode trust immediately. Always cross-check both.\n- **Listing everything instead of prioritizing.** A briefing that reports all 12 open workitems is not a briefing — it's a dump. The value of a morning briefing is triage: surface the 3 things that matter today, not an inventory of everything that exists. If in doubt about what to prioritize, ask — do not pad.\n- **Making the \"state of play\" section too optimistic.** Briefings written by the agent often smooth over problems to avoid delivering bad news. If the project is blocked, at risk, or behind, the state of play must say so clearly — not \"making good progress with a few items to resolve.\" The user is about to spend their session on this; accurate state matters.\n- **Not including a one-liner.** The \"one-liner to carry\" section is the hardest to write and the most valuable. Skipping it produces a briefing that reports status without providing orientation. Every briefing must end with one sentence that captures the dominant constraint or priority for the session.\n- **Generating a briefing without reading the current context.** A briefing from memory or from context loaded in a prior session may be stale. Always read HANDOVER.md and BACKLOG.md (or query the live index) before generating. A briefing that reflects last week's state is misleading.\n- **Writing the briefing in a format that requires careful reading instead of scanning.** Morning briefings are consumed at session start, often under time pressure. Use short bullets, bold key terms, and scannable structure. A briefing written as flowing prose that requires careful reading defeats the purpose.\n- **Reporting blockers without their resolution path.** \"Blocked on API key from vendor\" is incomplete. \"Blocked on API key from vendor — Sarah requested it Tuesday, expected by Thursday\" is actionable. Every blocker must include: who owns it, what action is in progress, and when it's expected to resolve.\n\n## Full reference\n\n### When the project has no processkit context\n\nIf the project does not use processkit (no BACKLOG.md, no HANDOVER.md),\nask the user to provide:\n- What was worked on last session\n- What is in progress right now\n- What deadlines exist in the next 1-2 weeks\n- Any blockers\n\nThen generate the briefing from those answers using the same format.\n\n### Archiving briefings\n\nBriefings are ephemeral by design. Do not archive them unless the\nuser requests it. The handover note is the persistent record;\nthe morning briefing is a generated view of it.\n\n### Integration with event-log\n\nThe `event-log` skill records session activity as log entries.\n`morning-briefing` reads recent entries (plus HANDOVER and WorkItem\nstate) and synthesizes them into an actionable briefing. event-log\nis the write path; morning-briefing is the read path.\n\n### Briefing cadence\n\n- **Daily work:** generate at the start of each session\n- **After a weekend:** use the extended format (>1 week gap)\n- **Project kickoff:** generate a \"kickoff briefing\" from the\n  PRD \u002F scope docs instead of HANDOVER + BACKLOG\n- **Post-incident:** lead with incident status, then resume normal\n  briefing format once the incident is resolved\n",{"name":5,"metadata":44,"description":67},{"processkit":45},{"id":46,"uses":47,"layer":57,"created":58,"version":59,"category":60,"commands":61,"apiVersion":66},"SKILL-morning-briefing",[48,51,54],{"skill":49,"purpose":50},"agent-management","Understand what context files to read at session start (HANDOVER, BACKLOG, INDEX).",{"skill":52,"purpose":53},"status-update-writer","Pull current project state when generating the today's priorities section.",{"skill":55,"purpose":56},"workitem-management","Query in-progress and next-up WorkItems for the today's priorities section.",2,1775606400000,"1.0.0","processkit",[62],{"args":63,"name":64,"description":65},"","morning-briefing-generate","Generate a session-start orientation from current project state","processkit.projectious.work\u002Fv1","Generates a concise daily briefing from project context — synthesizing current state, open decisions, key risks, and today's priority actions into a focused session-start orientation. Use at the start of a session when asked for a briefing, \"what's the state of things\", \"catch me up\", or \"what should I focus on today.\"\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmorning-briefing","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add projectious-work\u002Fprocesskit --skill morning-briefing",{"tool":81,"command":82},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill morning-briefing",{"tool":84,"command":85},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill morning-briefing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmorning-briefing\u002FSKILL.md",true,[89],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"commands\u002Fpk-resume.md","REFERENCE","参考文档",138,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fmorning-briefing\u002Fcommands\u002Fpk-resume.md",[96,123,143,163,180,197],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":107,"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",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[108,109,110,111,112,113,35,114,115,116,98,117,118,119,120,121,122],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"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",[129],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},[108,131,132,133,134,135,113,35,136,137,115,138,139,140,117,141,142],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"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",[],[108,150,151,110,111,152,113,35,153,154,155,22,117,156,157,158,159,160,161,162],"proposition","proposition management","index","log","world","record","creation","event","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":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",[],[108,116,170,110,113,171,172,136,173,153,115,174,175,117,176,177,157,178,120,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":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",[],[187,188,189,190,113,36,191,192,35,193,194,195,196],"okf","compatibility","okf compatibility","validate","knowledge","format","export","bundles","bundle","import",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"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",[],[108,204,205,110,111,152,113,171,35,114,153,206,115,155,117,177,157,158,207,122],"capability","capability management","queries","changes"]