[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X3J9FSTTFJDBV2SSJRBMFT":3,"skill-same:01M6X3J9FSTTFJDBV2SSJRBMFT":89},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":14,"repositoryHtmlUrl":71,"repositoryHomepageUrl":72,"ownerHtmlUrl":73,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":74,"install":75,"resources":88},"01M6X3J9FSTTFJDBV2SSJRBMFT","onboarding-guide",null,"Generates a structured onboarding guide for a new agent or human joining a project — covering codebase orientation, process context, first tasks, and key contacts. Use when asked to onboard someone new, write a getting-started guide, or create a \"first week\" plan for a project.","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.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fonboarding-guide\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"onboarding guide","onboarding","guide","context","when","contacts","project","new agent","human","wed","files","tasks","write","work","plan","handover","Budget","SET","product","create","2026-11-10 10:12:30",false,"---\nname: onboarding-guide\ndescription: |\n  Generates a structured onboarding guide for a new agent or human joining a project — covering codebase orientation, process context, first tasks, and key contacts. Use when asked to onboard someone new, write a getting-started guide, or create a \"first week\" plan for a project.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-onboarding-guide\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: product\n    layer: 4\n    uses:\n      - skill: agent-management\n        purpose: Understand context budget principles and what files to include in the always-load set.\n      - skill: agent-management\n        purpose: Reference the most recent session context (HANDOVER.md) as the starting point for new joiners.\n---\n\n# Onboarding Guide\n\n## Intro\n\nA good onboarding guide answers the questions a newcomer will have\nin their first hour, day, and week — before they need to ask. For\nagent onboarding specifically, it establishes what to read first,\nwhat never to touch, and what the most common first tasks look like.\nWrite it once, update it at every major structural change.\n\n## Overview\n\n### Two modes: agent onboarding and human onboarding\n\n**Agent onboarding** is about making the first session effective:\nthe agent reads a compact document and immediately knows enough to\nstart working safely. It targets the AGENTS.md file and the context\nfiles a fresh agent loads at session start.\n\n**Human onboarding** is broader: it covers environment setup, team\nconventions, process workflows, key contacts, and first tasks. It\nresults in a longer document — a `docs\u002Fonboarding.md` or a\n`context\u002FONBOARDING.md` — that a developer reads over their first\nweek.\n\nUse the right mode for the audience. Ask if unclear.\n\n### Agent onboarding — what to include in AGENTS.md\n\nThe `AGENTS.md` file is the canonical entry point for any agent.\nIt should include:\n\n1. **Read-first trail** — the 3-4 files to read in order before\n   touching anything (README, HANDOVER, this file, BACKLOG)\n2. **Always-on rules** — hard constraints (never edit generated\n   files, always run tests before committing, etc.)\n3. **Project structure** — the key directories, what each contains,\n   and what's off-limits\n4. **First-session workflow** — \"Here's how a typical work session\n   goes\" with a concrete example\n5. **Gotchas** — the 3-5 things that trip up agents new to this\n   project (not general programming knowledge — project-specific)\n\n```markdown\n## Read these first\n\n1. `README.md` — what this project does and why\n2. `context\u002FHANDOVER.md` — current state and what was worked on last\n3. `AGENTS.md` — this file: always-on rules\n4. `context\u002FBACKLOG.md` — what's queued, what's in progress\n\n## Always-on rules\n\n- Run `npm test` before every commit — the CI gate is strict\n- Never edit files in `generated\u002F` — they're regenerated on build\n- Every PR needs a linked issue — use `Closes #NNN` in the PR body\n- context\u002F files are managed by processkit — use MCP tools, not raw edits\n\n## Project structure\n\nsrc\u002F          — application source code\ncontext\u002F      — project-management artifacts (backlog, decisions, logs)\ndocs\u002F         — user-facing documentation\ngenerated\u002F    — AUTO-GENERATED, do not edit directly\nscripts\u002F      — maintenance and deployment scripts\n\n## First-session workflow\n\n1. Read `context\u002FHANDOVER.md` (3 min)\n2. Read `context\u002FBACKLOG.md` (2 min) — pick the top item in \"Next Up\"\n3. Ask the user which item to start or confirm the top item\n4. Work the item to done: code → tests → PR\n5. Write a session handover before ending\n```\n\n### Human onboarding — full guide structure\n\nFor a human developer joining a project, produce a guide with these\nsections:\n\n```markdown\n# Onboarding Guide — [Project Name]\n\n## Welcome and context\n[2-3 sentences: what the project does, who the users are, why it matters]\n\n## Environment setup\n\n### Prerequisites\n- [Language \u002F runtime version]\n- [Required tools]\n\n### First-time setup\n\\`\\`\\`bash\ngit clone [repo]\ncd [project]\n[setup command]\n[run tests]\n\\`\\`\\`\n\n### Verify it works\n[What a successful setup looks like]\n\n## Codebase orientation\n\n### Key directories\n| Directory | Purpose |\n|---|---|\n| `src\u002F` | Application source |\n| `tests\u002F` | Test suite |\n| `docs\u002F` | Documentation |\n\n### Where to start reading\n1. `[entry point file]` — [why it's the right starting point]\n2. `[key module]` — [what it does]\n3. `[tests\u002F]` — [how the test suite is organized]\n\n## How we work\n\n### Branching\n[Branch naming convention, e.g., `feature\u002F`, `fix\u002F`, `chore\u002F`]\n\n### Pull requests\n[PR checklist: tests, description, linked issue, review requirement]\n\n### Code style\n[Linter, formatter, how to run them]\n\n### Deployments\n[Who deploys, when, how to know if something is broken]\n\n## Your first tasks\n\n### Day 1\n- [ ] Complete environment setup and run the tests locally\n- [ ] Read the last 5 git commits to understand what's been worked on\n- [ ] Introduce yourself in [Slack\u002Fteam channel]\n\n### Week 1\n- [ ] Pick up [specific starter ticket] and work it end-to-end\n- [ ] Schedule a 30-min call with [team member] to understand [domain area]\n- [ ] Read [key design doc or ADR]\n\n## Key contacts\n| Name | Role | What to ask them about |\n|---|---|---|\n| [Name] | Lead engineer | Architecture decisions |\n| [Name] | Product | Feature priorities |\n\n## Where to ask questions\n- Quick questions: [Slack channel]\n- Design\u002Farchitecture: open a GitHub Discussion\n- Bugs: file a GitHub Issue\n\n## Gotchas — things that trip people up\n- [Specific pitfall unique to this codebase, not generic programming advice]\n- [Another project-specific quirk]\n```\n\n### Generating from existing project context\n\nWhen the project uses processkit, pull from live context:\n\n1. Read `AGENTS.md` for the existing rules\n2. Read `context\u002FHANDOVER.md` for current state\n3. Read `context\u002FBACKLOG.md` for the in-progress items\n4. Scan `README.md` for setup instructions\n\nSynthesize into the guide format. Do not duplicate content that is\nalready authoritative in those files — link to them instead.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Writing a generic onboarding guide that is not specific to this project.** Generic guides (\"run `npm install`, then `npm test`\") provide no orientation to the actual codebase or process. Every item in the onboarding guide should be something the newcomer cannot get from a template — project-specific conventions, project-specific gotchas, the actual first tasks for this project.\n- **Making the guide so comprehensive it takes a day to read.** Onboarding guides that try to document everything upfront guarantee that nothing is remembered. Aim for \"enough to be dangerous in the first session\" — the rest is discovered through work. A good guide is read in 20-30 minutes, not 2 hours.\n- **Not including a verified \"first setup\" command sequence.** An onboarding guide that says \"install the dependencies and run the tests\" without a tested step-by-step leaves newcomers guessing. Walk through the exact commands, in order, and verify they work before publishing.\n- **Omitting the gotchas section.** The most valuable part of an onboarding guide is the project-specific things that will trip someone up — the generated directory that must not be edited, the test database that must be seeded, the environment variable with the non-obvious name. Generic guides omit these; effective ones lead with them.\n- **Targeting only humans when the project uses AI agents.** If the project uses AI agents (Claude Code, Cursor, etc.), the agent's onboarding path is different from a human's. The AGENTS.md file is the agent's read-first document; the onboarding guide for humans should reference it but not duplicate it.\n- **Not updating the guide when the project structure changes.** An onboarding guide that describes a directory that no longer exists is worse than no guide — it erodes trust. Treat the onboarding guide as a living document: update it at every major structural change, not just at the start.\n- **Writing the guide in isolation without checking it against a real newcomer's questions.** The best onboarding guides are written by someone who has just onboarded, or reviewed by someone who is about to. If neither is available, walk through the guide step-by-step in a fresh environment to catch missing steps and stale instructions.\n\n## Full reference\n\n### Agent first-session checklist (to embed in AGENTS.md)\n\n```markdown\n## First session checklist\n\n- [ ] Read `context\u002FHANDOVER.md` — understand current state\n- [ ] Read `context\u002FBACKLOG.md` — identify in-progress items\n- [ ] Confirm with user which item to work, or start the top \"Next Up\" item\n- [ ] Run the test suite to confirm a clean baseline\n- [ ] Work the item: implement, test, commit\n- [ ] Update `context\u002FBACKLOG.md` with any status changes\n- [ ] Write a session handover note to `context\u002Farchive\u002Fsessions\u002F`\n```\n\n### Updating AGENTS.md vs. creating a separate ONBOARDING.md\n\nUse **AGENTS.md** for agent-specific rules and the read-first trail.\nUse **ONBOARDING.md** (in `docs\u002F` or `context\u002F`) for human-specific\nsetup instructions and first-week tasks. Keep them separate: AGENTS.md\nis loaded at every session start (it's in the always-load set);\nONBOARDING.md is a one-time reference that grows longer without penalty.\n\n### Signs the onboarding guide needs updating\n\n- A new team member asks a question that the guide should have answered\n- A directory or tool referenced in the guide no longer exists\n- The setup commands produce errors that didn't exist before\n- A newcomer took >2 hours to complete environment setup\n\nTreat each of these as a guide update ticket, not just a one-time\nanswer to one person.\n","# Onboarding Guide\n\n## Intro\n\nA good onboarding guide answers the questions a newcomer will have\nin their first hour, day, and week — before they need to ask. For\nagent onboarding specifically, it establishes what to read first,\nwhat never to touch, and what the most common first tasks look like.\nWrite it once, update it at every major structural change.\n\n## Overview\n\n### Two modes: agent onboarding and human onboarding\n\n**Agent onboarding** is about making the first session effective:\nthe agent reads a compact document and immediately knows enough to\nstart working safely. It targets the AGENTS.md file and the context\nfiles a fresh agent loads at session start.\n\n**Human onboarding** is broader: it covers environment setup, team\nconventions, process workflows, key contacts, and first tasks. It\nresults in a longer document — a `docs\u002Fonboarding.md` or a\n`context\u002FONBOARDING.md` — that a developer reads over their first\nweek.\n\nUse the right mode for the audience. Ask if unclear.\n\n### Agent onboarding — what to include in AGENTS.md\n\nThe `AGENTS.md` file is the canonical entry point for any agent.\nIt should include:\n\n1. **Read-first trail** — the 3-4 files to read in order before\n   touching anything (README, HANDOVER, this file, BACKLOG)\n2. **Always-on rules** — hard constraints (never edit generated\n   files, always run tests before committing, etc.)\n3. **Project structure** — the key directories, what each contains,\n   and what's off-limits\n4. **First-session workflow** — \"Here's how a typical work session\n   goes\" with a concrete example\n5. **Gotchas** — the 3-5 things that trip up agents new to this\n   project (not general programming knowledge — project-specific)\n\n```markdown\n## Read these first\n\n1. `README.md` — what this project does and why\n2. `context\u002FHANDOVER.md` — current state and what was worked on last\n3. `AGENTS.md` — this file: always-on rules\n4. `context\u002FBACKLOG.md` — what's queued, what's in progress\n\n## Always-on rules\n\n- Run `npm test` before every commit — the CI gate is strict\n- Never edit files in `generated\u002F` — they're regenerated on build\n- Every PR needs a linked issue — use `Closes #NNN` in the PR body\n- context\u002F files are managed by processkit — use MCP tools, not raw edits\n\n## Project structure\n\nsrc\u002F          — application source code\ncontext\u002F      — project-management artifacts (backlog, decisions, logs)\ndocs\u002F         — user-facing documentation\ngenerated\u002F    — AUTO-GENERATED, do not edit directly\nscripts\u002F      — maintenance and deployment scripts\n\n## First-session workflow\n\n1. Read `context\u002FHANDOVER.md` (3 min)\n2. Read `context\u002FBACKLOG.md` (2 min) — pick the top item in \"Next Up\"\n3. Ask the user which item to start or confirm the top item\n4. Work the item to done: code → tests → PR\n5. Write a session handover before ending\n```\n\n### Human onboarding — full guide structure\n\nFor a human developer joining a project, produce a guide with these\nsections:\n\n```markdown\n# Onboarding Guide — [Project Name]\n\n## Welcome and context\n[2-3 sentences: what the project does, who the users are, why it matters]\n\n## Environment setup\n\n### Prerequisites\n- [Language \u002F runtime version]\n- [Required tools]\n\n### First-time setup\n\\`\\`\\`bash\ngit clone [repo]\ncd [project]\n[setup command]\n[run tests]\n\\`\\`\\`\n\n### Verify it works\n[What a successful setup looks like]\n\n## Codebase orientation\n\n### Key directories\n| Directory | Purpose |\n|---|---|\n| `src\u002F` | Application source |\n| `tests\u002F` | Test suite |\n| `docs\u002F` | Documentation |\n\n### Where to start reading\n1. `[entry point file]` — [why it's the right starting point]\n2. `[key module]` — [what it does]\n3. `[tests\u002F]` — [how the test suite is organized]\n\n## How we work\n\n### Branching\n[Branch naming convention, e.g., `feature\u002F`, `fix\u002F`, `chore\u002F`]\n\n### Pull requests\n[PR checklist: tests, description, linked issue, review requirement]\n\n### Code style\n[Linter, formatter, how to run them]\n\n### Deployments\n[Who deploys, when, how to know if something is broken]\n\n## Your first tasks\n\n### Day 1\n- [ ] Complete environment setup and run the tests locally\n- [ ] Read the last 5 git commits to understand what's been worked on\n- [ ] Introduce yourself in [Slack\u002Fteam channel]\n\n### Week 1\n- [ ] Pick up [specific starter ticket] and work it end-to-end\n- [ ] Schedule a 30-min call with [team member] to understand [domain area]\n- [ ] Read [key design doc or ADR]\n\n## Key contacts\n| Name | Role | What to ask them about |\n|---|---|---|\n| [Name] | Lead engineer | Architecture decisions |\n| [Name] | Product | Feature priorities |\n\n## Where to ask questions\n- Quick questions: [Slack channel]\n- Design\u002Farchitecture: open a GitHub Discussion\n- Bugs: file a GitHub Issue\n\n## Gotchas — things that trip people up\n- [Specific pitfall unique to this codebase, not generic programming advice]\n- [Another project-specific quirk]\n```\n\n### Generating from existing project context\n\nWhen the project uses processkit, pull from live context:\n\n1. Read `AGENTS.md` for the existing rules\n2. Read `context\u002FHANDOVER.md` for current state\n3. Read `context\u002FBACKLOG.md` for the in-progress items\n4. Scan `README.md` for setup instructions\n\nSynthesize into the guide format. Do not duplicate content that is\nalready authoritative in those files — link to them instead.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Writing a generic onboarding guide that is not specific to this project.** Generic guides (\"run `npm install`, then `npm test`\") provide no orientation to the actual codebase or process. Every item in the onboarding guide should be something the newcomer cannot get from a template — project-specific conventions, project-specific gotchas, the actual first tasks for this project.\n- **Making the guide so comprehensive it takes a day to read.** Onboarding guides that try to document everything upfront guarantee that nothing is remembered. Aim for \"enough to be dangerous in the first session\" — the rest is discovered through work. A good guide is read in 20-30 minutes, not 2 hours.\n- **Not including a verified \"first setup\" command sequence.** An onboarding guide that says \"install the dependencies and run the tests\" without a tested step-by-step leaves newcomers guessing. Walk through the exact commands, in order, and verify they work before publishing.\n- **Omitting the gotchas section.** The most valuable part of an onboarding guide is the project-specific things that will trip someone up — the generated directory that must not be edited, the test database that must be seeded, the environment variable with the non-obvious name. Generic guides omit these; effective ones lead with them.\n- **Targeting only humans when the project uses AI agents.** If the project uses AI agents (Claude Code, Cursor, etc.), the agent's onboarding path is different from a human's. The AGENTS.md file is the agent's read-first document; the onboarding guide for humans should reference it but not duplicate it.\n- **Not updating the guide when the project structure changes.** An onboarding guide that describes a directory that no longer exists is worse than no guide — it erodes trust. Treat the onboarding guide as a living document: update it at every major structural change, not just at the start.\n- **Writing the guide in isolation without checking it against a real newcomer's questions.** The best onboarding guides are written by someone who has just onboarded, or reviewed by someone who is about to. If neither is available, walk through the guide step-by-step in a fresh environment to catch missing steps and stale instructions.\n\n## Full reference\n\n### Agent first-session checklist (to embed in AGENTS.md)\n\n```markdown\n## First session checklist\n\n- [ ] Read `context\u002FHANDOVER.md` — understand current state\n- [ ] Read `context\u002FBACKLOG.md` — identify in-progress items\n- [ ] Confirm with user which item to work, or start the top \"Next Up\" item\n- [ ] Run the test suite to confirm a clean baseline\n- [ ] Work the item: implement, test, commit\n- [ ] Update `context\u002FBACKLOG.md` with any status changes\n- [ ] Write a session handover note to `context\u002Farchive\u002Fsessions\u002F`\n```\n\n### Updating AGENTS.md vs. creating a separate ONBOARDING.md\n\nUse **AGENTS.md** for agent-specific rules and the read-first trail.\nUse **ONBOARDING.md** (in `docs\u002F` or `context\u002F`) for human-specific\nsetup instructions and first-week tasks. Keep them separate: AGENTS.md\nis loaded at every session start (it's in the always-load set);\nONBOARDING.md is a one-time reference that grows longer without penalty.\n\n### Signs the onboarding guide needs updating\n\n- A new team member asks a question that the guide should have answered\n- A directory or tool referenced in the guide no longer exists\n- The setup commands produce errors that didn't exist before\n- A newcomer took >2 hours to complete environment setup\n\nTreat each of these as a guide update ticket, not just a one-time\nanswer to one person.\n",{"name":5,"metadata":54,"description":67},{"processkit":55},{"id":56,"uses":57,"layer":63,"created":64,"version":65,"category":47,"apiVersion":66},"SKILL-onboarding-guide",[58,61],{"skill":59,"purpose":60},"agent-management","Understand context budget principles and what files to include in the always-load set.",{"skill":59,"purpose":62},"Reference the most recent session context (HANDOVER.md) as the starting point for new joiners.",4,1775606400000,"1.0.0","processkit.projectious.work\u002Fv1","Generates a structured onboarding guide for a new agent or human joining a project — covering codebase orientation, process context, first tasks, and key contacts. Use when asked to onboard someone new, write a getting-started guide, or create a \"first week\" plan for a project.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fonboarding-guide","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 onboarding-guide",{"tool":81,"command":82},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill onboarding-guide",{"tool":84,"command":85},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill onboarding-guide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.1\u002Fcontext\u002Fskills\u002Fproduct\u002Fonboarding-guide\u002FSKILL.md",true,[],[90,112,131,152,169,187],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":97,"publishedAt":49},"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",[96],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[98,99,48,100,101,102,42,103,104,105,92,106,107,108,109,110,111],"management","skill management","update","package","alpha","list","manage","ontology","get","as","manifests","v1","skill package","transition",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":49},"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",[118],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[98,120,121,122,123,124,102,42,125,126,104,127,38,128,106,129,130],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","deterministic","contract","mode",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":49},"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",[],[98,138,139,48,100,140,102,42,141,142,143,144,106,145,146,147,148,149,150,151],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":49},"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",[],[98,105,159,48,102,160,161,125,162,141,104,163,164,106,165,166,146,167,109,168],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":49},"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",[],[176,177,178,179,102,180,181,182,42,183,184,185,186],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":49},"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",[],[98,194,195,48,100,140,102,160,42,103,141,196,104,143,106,166,146,147,197,111],"capability","capability management","queries","changes"]