[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X1TY98ER2SY8AH87WADT8K":3,"skill-same:01M6X1TY98ER2SY8AH87WADT8K":79},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":14,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":64,"install":65,"resources":78},"01M6X1TY98ER2SY8AH87WADT8K","git-workflow",null,"Git workflow conventions — branch naming, conventional commits, PR descriptions, and merge strategy. Use when deciding on a branch name, writing a commit message or PR description, or choosing a merge strategy.","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\u002Fengineering\u002Fgit-workflow\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"workflow","git workflow","git","when","writing","v1","naming","name","message","conventional commits","use","strategy","branch","work","commits","commit message","pr description","pr","merge","commit","2026-11-10 10:12:30",false,"---\nname: git-workflow\ndescription: |\n  Git workflow conventions — branch naming, conventional commits, PR descriptions, and merge strategy. Use when deciding on a branch name, writing a commit message or PR description, or choosing a merge strategy.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-git-workflow\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n    layer: 3\n---\n\n# Git Workflow\n\n## Intro\n\nUse typed branch names, Conventional Commits, and PR descriptions\nthat explain the why. Squash-merge feature branches for a clean\nhistory. Keep commits atomic and never force-push to shared\nbranches.\n\n## Overview\n\n### Branch naming\n\nFormat: `\u003Ctype>\u002F\u003Cissue>-\u003Cshort-description>`\n\nTypes: `feat\u002F`, `fix\u002F`, `refactor\u002F`, `docs\u002F`, `chore\u002F`\n\nExamples:\n\n- `feat\u002F42-add-user-auth`\n- `fix\u002F17-null-pointer-crash`\n- `refactor\u002F89-extract-payment-service`\n\n### Commit messages\n\nFollow Conventional Commits:\n\n- **Format:** `\u003Ctype>: \u003Cdescription>` — lowercase, imperative\n  mood, no trailing period\n- **Types:** `feat`, `fix`, `refactor`, `docs`, `test`, `chore`,\n  `ci`\n- **Body:** explain WHY, not WHAT (the diff shows what)\n- **Footer:** `fixes #N` or `refs #N` for issue links\n\n### PR descriptions\n\n- **Title:** same format as commit messages, under 70 characters\n- **Body:** Summary (what and why), test plan, breaking changes\n- Link related issues\n\n### Merge strategy\n\n- **Squash merge** for feature branches — keeps mainline history\n  clean\n- **Merge commit** for long-lived branches — preserves context\n  across the merge\n- **Rebase** to keep a feature branch up to date before opening\n  the PR\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Mega-commits (\"various fixes\", 40 files changed).** A commit that mixes unrelated changes is impossible to review, impossible to revert selectively, and tells a lie in its message. Each commit should represent one logical change that can stand alone.\n- **Force-pushing to shared branches.** Force-pushing to `main` or any branch others have checked out rewrites history they depend on, causing diverged local states that are painful to recover. Never force-push to a shared branch.\n- **Branches that live for months.** Long-lived branches diverge from main, accumulate merge conflicts, and eventually require heroic merge efforts. Rebase weekly or split long-running work into shorter-lived feature branches.\n- **PRs with no description.** \"See commits\" is not a description. The PR description is for the reviewer — it explains what changed, why it changed, and how to verify it. Write it before requesting review.\n- **Conventional Commit type misuse.** Using `fix:` for features or `feat:` for refactors corrupts any automation that generates changelogs or determines version bumps from commit types. Match the type to the nature of the change.\n- **Squash-merging a long-lived integration branch.** Squash-merge is for feature branches with noisy \"wip\" commits. A long-lived branch with meaningful commit history should be merge-committed so the history is preserved for future investigation.\n- **Committing unrelated changes in the same PR to \"save time\".** Reviewers are slower on unrelated changes combined in one PR; rollback becomes more expensive if one change needs reverting. Split unrelated changes into separate PRs.\n\n## Full reference\n\n### General rules\n\n- Commit early and often on feature branches; squash at merge time.\n- Never force-push to shared branches (`main`, `develop`, release\n  branches).\n- Keep commits atomic — one logical change per commit. A commit\n  that touches three unrelated concerns is three commits.\n- A commit message body wraps at 72 columns; the subject line at\n  50 if you can.\n\n### Worked example\n\nUser: \"What should I name this branch for adding search?\"\n\nSuggest `feat\u002F30-add-search-functionality` if there's an issue\n#30; otherwise `feat\u002Fadd-search-functionality`. Match the\nexisting repo's convention if it differs.\n\n### Anti-patterns\n\n- **Mega-commits** — \"various fixes\" with 40 files changed.\n  Impossible to review or revert.\n- **Force-push to main** — destroys other contributors' work.\n- **Commit messages like \"wip\", \"fix\", \"stuff\"** — every commit\n  should be reviewable on its own.\n- **PRs with no description** — the PR description is for the\n  reviewer, not the author. \"See commits\" is not a description.\n- **Branches that live for months** — long-lived branches\n  diverge from main and become merge nightmares. Rebase weekly\n  or split the work.\n\n### When to break the rules\n\nSolo-on-a-private-branch force-pushes are fine. Trivial typo\nfixes don't need a long body. Use judgment, but the defaults\nabove are right for almost every team setting.\n","# Git Workflow\n\n## Intro\n\nUse typed branch names, Conventional Commits, and PR descriptions\nthat explain the why. Squash-merge feature branches for a clean\nhistory. Keep commits atomic and never force-push to shared\nbranches.\n\n## Overview\n\n### Branch naming\n\nFormat: `\u003Ctype>\u002F\u003Cissue>-\u003Cshort-description>`\n\nTypes: `feat\u002F`, `fix\u002F`, `refactor\u002F`, `docs\u002F`, `chore\u002F`\n\nExamples:\n\n- `feat\u002F42-add-user-auth`\n- `fix\u002F17-null-pointer-crash`\n- `refactor\u002F89-extract-payment-service`\n\n### Commit messages\n\nFollow Conventional Commits:\n\n- **Format:** `\u003Ctype>: \u003Cdescription>` — lowercase, imperative\n  mood, no trailing period\n- **Types:** `feat`, `fix`, `refactor`, `docs`, `test`, `chore`,\n  `ci`\n- **Body:** explain WHY, not WHAT (the diff shows what)\n- **Footer:** `fixes #N` or `refs #N` for issue links\n\n### PR descriptions\n\n- **Title:** same format as commit messages, under 70 characters\n- **Body:** Summary (what and why), test plan, breaking changes\n- Link related issues\n\n### Merge strategy\n\n- **Squash merge** for feature branches — keeps mainline history\n  clean\n- **Merge commit** for long-lived branches — preserves context\n  across the merge\n- **Rebase** to keep a feature branch up to date before opening\n  the PR\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Mega-commits (\"various fixes\", 40 files changed).** A commit that mixes unrelated changes is impossible to review, impossible to revert selectively, and tells a lie in its message. Each commit should represent one logical change that can stand alone.\n- **Force-pushing to shared branches.** Force-pushing to `main` or any branch others have checked out rewrites history they depend on, causing diverged local states that are painful to recover. Never force-push to a shared branch.\n- **Branches that live for months.** Long-lived branches diverge from main, accumulate merge conflicts, and eventually require heroic merge efforts. Rebase weekly or split long-running work into shorter-lived feature branches.\n- **PRs with no description.** \"See commits\" is not a description. The PR description is for the reviewer — it explains what changed, why it changed, and how to verify it. Write it before requesting review.\n- **Conventional Commit type misuse.** Using `fix:` for features or `feat:` for refactors corrupts any automation that generates changelogs or determines version bumps from commit types. Match the type to the nature of the change.\n- **Squash-merging a long-lived integration branch.** Squash-merge is for feature branches with noisy \"wip\" commits. A long-lived branch with meaningful commit history should be merge-committed so the history is preserved for future investigation.\n- **Committing unrelated changes in the same PR to \"save time\".** Reviewers are slower on unrelated changes combined in one PR; rollback becomes more expensive if one change needs reverting. Split unrelated changes into separate PRs.\n\n## Full reference\n\n### General rules\n\n- Commit early and often on feature branches; squash at merge time.\n- Never force-push to shared branches (`main`, `develop`, release\n  branches).\n- Keep commits atomic — one logical change per commit. A commit\n  that touches three unrelated concerns is three commits.\n- A commit message body wraps at 72 columns; the subject line at\n  50 if you can.\n\n### Worked example\n\nUser: \"What should I name this branch for adding search?\"\n\nSuggest `feat\u002F30-add-search-functionality` if there's an issue\n#30; otherwise `feat\u002Fadd-search-functionality`. Match the\nexisting repo's convention if it differs.\n\n### Anti-patterns\n\n- **Mega-commits** — \"various fixes\" with 40 files changed.\n  Impossible to review or revert.\n- **Force-push to main** — destroys other contributors' work.\n- **Commit messages like \"wip\", \"fix\", \"stuff\"** — every commit\n  should be reviewable on its own.\n- **PRs with no description** — the PR description is for the\n  reviewer, not the author. \"See commits\" is not a description.\n- **Branches that live for months** — long-lived branches\n  diverge from main and become merge nightmares. Rebase weekly\n  or split the work.\n\n### When to break the rules\n\nSolo-on-a-private-branch force-pushes are fine. Trivial typo\nfixes don't need a long body. Use judgment, but the defaults\nabove are right for almost every team setting.\n",{"name":5,"metadata":49,"description":57},{"processkit":50},{"id":51,"layer":52,"created":53,"version":54,"category":55,"apiVersion":56},"SKILL-git-workflow",3,1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Git workflow conventions — branch naming, conventional commits, PR descriptions, and merge strategy. Use when deciding on a branch name, writing a commit message or PR description, or choosing a merge strategy.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fgit-workflow","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":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add projectious-work\u002Fprocesskit --skill git-workflow",{"tool":71,"command":72},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill git-workflow",{"tool":74,"command":75},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill git-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fgit-workflow\u002FSKILL.md",true,[],[80,102,122,143,160,178],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":87,"publishedAt":44},"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",[86],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[88,89,90,91,92,93,37,94,95,96,82,97,98,99,29,100,101],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":44},"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",[108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[88,110,111,112,113,114,93,37,115,116,95,117,118,119,97,120,121],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":44},"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",[],[88,129,130,90,91,131,93,37,132,133,134,135,97,136,137,138,139,140,141,142],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"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":44},"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",[],[88,96,150,90,93,151,152,115,153,132,95,154,155,97,156,157,137,158,29,159],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":44},"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",[],[167,168,169,170,93,171,172,173,37,174,175,176,177],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":44},"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",[],[88,185,186,90,91,131,93,151,37,94,132,187,95,134,97,157,137,138,188,101],"capability","capability management","queries","changes"]