[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71P49D1AG2MR6AYNPMMT34Z":3,"skill-same:01M71P49D1AG2MR6AYNPMMT34Z":75},{"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":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M71P49D1AG2MR6AYNPMMT34Z","writing-good-commits",null,"Write or reword a git commit message and size the commit it describes. Use when committing, or when reshaping commits during a rebase.","drsh4dow\u002Fpi-setup","drsh4dow","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F45247070?v=4","01M71P068NASGHSWS11VWW416N","Daniel Moretti","01M71P0698BH81N65NP04X9NVN",10,"MIT","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-commits\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"good","writing","writing good commits","commits","it","commit","committing","when","commit message","rebase","false","use","git commit","git","git commit message","write","size","message","2026-11-10 10:56:23",false,"---\nname: writing-good-commits\ndescription: Write or reword a git commit message and size the commit it describes. Use when committing, or when reshaping commits during a rebase.\ndisable-model-invocation: false\nuser-invokable: false\n---\n\n# Writing good commits\n\nA commit message is what a maintainer reads in `git log`, `git blame`, and `git bisect` months later, with no PR or chat beside it. The subject names the change. The body says why the change was needed.\n\nEdit the prose with the **unslop** skill.\n\n## Size\n\n- Put one logical change in each commit. A change across many files is still one commit, and two changes in one file are two commits.\n- Make every commit build and pass the checks, so `git bisect` can stop on any of them. Check a series with `git rebase -x '\u003Ccheck>' \u003Cbase>`. In a linked worktree, git exports `GIT_DIR` to that command, so a test that builds scratch repos without unsetting it runs its git commands against the real repository; run such checks as `env -u GIT_DIR -u GIT_WORK_TREE -u GIT_INDEX_FILE \u003Ccheck>`.\n- Move or rename code in its own commit, with no edits mixed in.\n- Split a commit whose message you cannot summarize in one subject.\n\n## Subject\n\nUse Conventional Commits, `type(scope): subject`.\n\n- The type is one of `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `revert`, or `style`. A commit that fits two types is two commits.\n- The scope is a noun for the area, such as `subagents` or `web`. Reuse the scopes in `git log --no-merges --format=%s -- \u003Cfiles>`.\n- Write the subject in the imperative, so it completes \"If applied, this commit will …\". Start it lowercase unless it starts with an identifier or a proper noun, and end it without a period.\n- Aim for 50 characters, and keep the whole header within 72.\n- Say what changes, uniquely within the series. A bare file name or \"address feedback\" says nothing in `git log --oneline`.\n- Mark a breaking change with `!` before the colon, such as `feat(api)!: drop the v1 routes`.\n\n## Body\n\nLeave the body out when the subject says it all. Otherwise, after one blank line, wrap at 72 columns and cover:\n\n- The problem, in the present tense: what the code does without this change.\n- Why this approach, and the rejected alternatives a reader would ask about.\n- The impact a user sees. Back a performance claim with a `before → after` number.\n\nLeave the how to the diff. Make the message self-contained: summarize a discussion rather than only linking it, and cite another commit as `abc1234 (\"subject\")`. Keep the process out: the commands you ran, review rounds, and \"v2\" notes belong in the PR.\n\n## Trailers\n\nEnd with one trailer block after a blank line, one `Token: value` per line. Use only these:\n\n- `BREAKING CHANGE: \u003Cwhat breaks and how to migrate>`, alongside the `!` in the header.\n- `Closes #N` for an issue the commit resolves.\n- `Refs: #N` for a related issue or commit it does not resolve.\n\n## Example\n\n```text\nfix(subagents): kill the child tree when the launcher exits\n\nA SIGKILL to the launcher leaves grandchildren running, because\ncleanup runs only on SIGTERM. Put each run in its own process group\nand kill the group from the parent's exit hook. A pidfile sweep was\nrejected because it races with PID reuse.\n\nCloses #142\n```\n\nThe same change written badly:\n\n```text\nFixed stuff in subagents and also updated docs.\n\nChanged launcher.ts to call process.kill. Updated README. Ran tests.\n```\n\nIt has no type or scope, uses the past tense, ends in a period, mixes two changes, restates the diff and the process, and never says why.\n","# Writing good commits\n\nA commit message is what a maintainer reads in `git log`, `git blame`, and `git bisect` months later, with no PR or chat beside it. The subject names the change. The body says why the change was needed.\n\nEdit the prose with the **unslop** skill.\n\n## Size\n\n- Put one logical change in each commit. A change across many files is still one commit, and two changes in one file are two commits.\n- Make every commit build and pass the checks, so `git bisect` can stop on any of them. Check a series with `git rebase -x '\u003Ccheck>' \u003Cbase>`. In a linked worktree, git exports `GIT_DIR` to that command, so a test that builds scratch repos without unsetting it runs its git commands against the real repository; run such checks as `env -u GIT_DIR -u GIT_WORK_TREE -u GIT_INDEX_FILE \u003Ccheck>`.\n- Move or rename code in its own commit, with no edits mixed in.\n- Split a commit whose message you cannot summarize in one subject.\n\n## Subject\n\nUse Conventional Commits, `type(scope): subject`.\n\n- The type is one of `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `revert`, or `style`. A commit that fits two types is two commits.\n- The scope is a noun for the area, such as `subagents` or `web`. Reuse the scopes in `git log --no-merges --format=%s -- \u003Cfiles>`.\n- Write the subject in the imperative, so it completes \"If applied, this commit will …\". Start it lowercase unless it starts with an identifier or a proper noun, and end it without a period.\n- Aim for 50 characters, and keep the whole header within 72.\n- Say what changes, uniquely within the series. A bare file name or \"address feedback\" says nothing in `git log --oneline`.\n- Mark a breaking change with `!` before the colon, such as `feat(api)!: drop the v1 routes`.\n\n## Body\n\nLeave the body out when the subject says it all. Otherwise, after one blank line, wrap at 72 columns and cover:\n\n- The problem, in the present tense: what the code does without this change.\n- Why this approach, and the rejected alternatives a reader would ask about.\n- The impact a user sees. Back a performance claim with a `before → after` number.\n\nLeave the how to the diff. Make the message self-contained: summarize a discussion rather than only linking it, and cite another commit as `abc1234 (\"subject\")`. Keep the process out: the commands you ran, review rounds, and \"v2\" notes belong in the PR.\n\n## Trailers\n\nEnd with one trailer block after a blank line, one `Token: value` per line. Use only these:\n\n- `BREAKING CHANGE: \u003Cwhat breaks and how to migrate>`, alongside the `!` in the header.\n- `Closes #N` for an issue the commit resolves.\n- `Refs: #N` for a related issue or commit it does not resolve.\n\n## Example\n\n```text\nfix(subagents): kill the child tree when the launcher exits\n\nA SIGKILL to the launcher leaves grandchildren running, because\ncleanup runs only on SIGTERM. Put each run in its own process group\nand kill the group from the parent's exit hook. A pidfile sweep was\nrejected because it races with PID reuse.\n\nCloses #142\n```\n\nThe same change written badly:\n\n```text\nFixed stuff in subagents and also updated docs.\n\nChanged launcher.ts to call process.kill. Updated README. Ran tests.\n```\n\nIt has no type or scope, uses the past tense, ends in a period, mixes two changes, restates the diff and the process, and never says why.\n",{"name":5,"description":7,"user-invokable":48,"disable-model-invocation":48},"main","f7936596c1ba2e1472dadccc3f111b9d517fa96c","agent\u002Fskills\u002Fwriting-good-commits",2,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup","https:\u002F\u002Fgithub.com\u002Fdrsh4dow","https:\u002F\u002Fdanielmoretti.com\u002F","Toss A Coin To Your Witcher :pirate_flag: ","2026-11-03 22:13:53",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add drsh4dow\u002Fpi-setup --skill writing-good-commits",{"tool":67,"command":68},"bunx","bunx skills add drsh4dow\u002Fpi-setup --skill writing-good-commits",{"tool":70,"command":71},"pnpm","pnpm dlx skills add drsh4dow\u002Fpi-setup --skill writing-good-commits","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-commits\u002FSKILL.md",true,[],[76,96,117,134,145,165],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":47},"01M71P4GPJMBK21BTZBKY9T8EE","changelog","Write the changelog entry for a pull request. Use when a PR changes behavior that users, operators, or integrators can notice.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fevals\u002Fharness-lessons\u002Ffixtures\u002Fchangelog-skill\u002FSKILL.md",[],[78,83,84,85,36,40,44,86,87,88,89,90,91,92,93,94,95],"changes","changelog entry","can","entry","behavior","request","for","pull request","pr","operators","notice","pull","users",{"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":104,"publishedAt":47},"01M71P4E9AZM56JBY227P2G1SC","writing-good-tickets","Write, file, or update an issue or ticket that an agent or a developer can take to one PR. Use when filing a bug or feature, updating an issue, or breaking a plan into tickets.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002FSKILL.md",[102,103],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[105,29,30,106,107,36,108,40,39,109,110,91,111,112,113,114,44,115,116,85],"writing good tickets","tickets","filing","ticket","one","feature","file","issue","take","bug","update","plan",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":125,"publishedAt":47},"01M71P4C0B0DXTRRSG9RA6Y687","writing-good-prs","Write or update a pull request title and body that a reviewer can trust and own. Use when opening a PR or editing its description.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-prs\u002FSKILL.md",[123,124],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[126,30,127,29,128,129,44,115,88,90,40,130,85,36,39,131,91,132,94,133],"writing good prs","prs","body","opening a pr","reviewer","editing","trust","title",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":142,"publishedAt":47},"01M71P480BDE55JMPVVEBCFS7P","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[140,141],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[30,143,89,39,36,144,40,131],"writing for agents","documents",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":47},"01M71P45SNCD7DDSA6FRVCPA17","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwizard\u002FSKILL.md",[],[147,39,152,40,153,154,155,156,89,157,158,36,159,160,161,162,85,163,109,164],"invoke","only","provisioning infrastructure","ci","up","setting","running","human","generate","dashboard","credentials","interactive","Bash",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":47},"01M71P43DNNPQ67NY6G4XQQM50","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwhy\u002FSKILL.md",[],[167,172,173,87,174,175,39,40,176,177,89,178],"rationale","data","how","work","design","runtime","thresholds"]